feat(labs): добавлено сохранение наблюдений под учебной учеткой

Зачем: студенту нужен понятный путь от сохраненного состояния к SQL-сравнению без доступа технической учетной записи к изменению хранилища.

Что: добавлен student с чтением источников и записью только в default; лабораторная сохраняет заказы и итоги в две локальные таблицы. Обновлены настройка доступа и программа, уточнено округление productPrice.

Проверка: DDL и INSERT SELECT под student, пустое наблюдение, восемь переходов сохраненной истории и запрет вставки в пять прикладных баз на обеих нодах. config-test, lint стенда и генератора, 54 ссылки, независимое ревью.

docs/labs/optional/revenue-over-time.md

@@ -4,7 +4,8 @@
 заказов по наблюдаемым опозданиям и изменениям статусов.
 
 Факультатив доступен после ступени 1. Понадобятся Airflow и DBeaver с
-подключением `analyst` по [инструкции](../../../README.md#подключиться-из-dbeaver).
+подключением `student` по [инструкции](../../../README.md#подключиться-из-dbeaver).
+Он читает данные стенда и записывает ваши наблюдения в базу `default`.
 Вы будете наблюдать один день оформления заказов, продвигая мир по одному
 модельному дню. Проверьте, можно ли при загрузке выручки каждый раз считать
 только новый день. Новые данные останутся в стенде.
@@ -32,28 +33,65 @@ SELECT
 хранилище еще нет. Проверьте это для D в `dds.order_v` и
 `dm.purchase_vs_orders_v`.
 
-## Подготовьте запросы и сохраняйте результаты
-
-Напишите запросы для следующих наблюдений:
-
-| Что сохранить | Откуда взять |
-|---|---|
-| Дату полученного слепка S | `max(snapshot_date)` из `ods.order_v` |
-| Номер, статус и `items_total` каждого заказа дня D | `dds.order_v`, отбор по `order_date` |
-| Число заказов в каждом статусе и сумму `items_total` только у `paid` | те же заказы дня D |
-| Выручку дня D | сумма `revenue` из `dm.revenue_daily_v`, отбор по `report_date` |
-| Номера покупок, еще ожидающих заказ | строки `awaiting_order` из `dm.purchase_vs_orders_v`, отбор по `order_day` |
-
-Выручку складывайте по всем категориям. В этой витрине она означает стоимость
-позиций оплаченных заказов, без скидки и доставки, поэтому должна сходиться
-с суммой `items_total` у заказов в статусе `paid`.
-
-Сохраняйте результаты запросов отдельными файлами, например выгрузками CSV
-из DBeaver. Подписывайте D и S. До поступления первого слепка список заказов
-пуст, а выручка равна нулю; сохраните и это наблюдение.
+## Подготовьте место для наблюдений
 
 Публичное представление заказа показывает текущее состояние, а сырые слепки
-хранятся ограниченное время. Сохраненные выгрузки — история для расследования.
+хранятся ограниченное время. Сохраните историю в двух своих таблицах: потом
+вы сможете сравнивать наблюдения обычными SQL-запросами в том же DBeaver.
+
+Выполните DDL ниже. Это локальные таблицы на узле вашего подключения;
+всю работу выполняйте через одно подключение. Если имена уже заняты вашей
+прошлой работой, выберите другие и используйте их в дальнейших запросах.
+
+```sql
+CREATE TABLE default.lab_order_history
+(
+    order_date Date,
+    snapshot_date Date,
+    order_id String,
+    status String,
+    items_total Decimal(18, 2)
+)
+ENGINE = MergeTree
+ORDER BY (order_date, snapshot_date, order_id);
+
+CREATE TABLE default.lab_revenue_history
+(
+    order_date Date,
+    snapshot_date Date,
+    revenue Decimal(18, 2),
+    awaiting_order_ids Array(String)
+)
+ENGINE = MergeTree
+ORDER BY (order_date, snapshot_date);
+```
+
+## Сохраните первое наблюдение
+
+Напишите два `INSERT INTO ... SELECT` с явным списком колонок назначения:
+
+| Куда записать | Что взять из стенда |
+|---|---|
+| `default.lab_order_history` | По строке на заказ дня D из `dds.order_v`: `order_date`, `order_id`, `status`, `items_total`; добавьте дату наблюдения S |
+| `default.lab_revenue_history` | Одну строку с D, S, суммой `revenue` за `report_date = D` из `dm.revenue_daily_v` и массивом номеров `awaiting_order` за `order_day = D` из `dm.purchase_vs_orders_v` |
+
+Во втором запросе сумму и массив получите отдельными агрегатами, чтобы
+заказы не умножили строки выручки при соединении. Для массива пригодится
+`groupArray(order_id)`. Дату S берите из `max(snapshot_date)` в `ods.order_v`.
+
+Сначала выполните части `SELECT` отдельно и проверьте результаты, затем
+сохраните их. До первого слепка заказов дня D еще нет: в таблицу заказов
+строки не добавятся, но в таблице итогов должна появиться строка с нулевой
+выручкой. Она зафиксирует, что наблюдение сделано.
+
+Каждую пару D и S сохраняйте один раз: повторный `INSERT` добавит копии строк.
+После записи проверьте, что на эту пару приходится одна строка итогов,
+а число заказов и число разных `order_id` совпадают с `dds.order_v` за D.
+
+Выручка этой витрины — стоимость позиций оплаченных заказов без скидки и
+доставки. Для каждого сохраненного наблюдения посчитайте число заказов по
+статусам и сумму `items_total` только у `paid`. Эта сумма должна сходиться
+с сохраненной выручкой, сложенной по всем категориям.
 
 ## Продвигайте мир по одному дню
 
@@ -62,7 +100,7 @@ SELECT
 1. Запустите `world_next_day` с `days = 1` и дождитесь успеха.
 2. Запустите `etl_pipeline` и дождитесь успеха: `world_next_day` сам витрины
    не обновляет.
-3. Повторите свои запросы и сохраните новый комплект результатов с датой S.
+3. Повторите два запроса сохранения с новой датой S и проверьте записанные строки.
 
 Во всех запросах остается прежний день D. За один запуск проигрывайте один
 день, чтобы сохранить промежуточные состояния. Пакетный `world_next_day`
@@ -75,8 +113,10 @@ SELECT
 
 ## Найдите изменения в уже загруженном дне
 
-После каждого шага сравнивайте заказы по `order_id`, а не по положению строк
-в выгрузке. Найдите:
+Для сравнения прочитайте `default.lab_order_history` дважды: в одном
+подзапросе отберите прежнюю S, в другом — новую; день D остается общим.
+Соедините состояния по `order_id`, сохранив и заказы без пары. Итоги для этих
+же D и S возьмите из `default.lab_revenue_history`. Найдите:
 
 - заказы, отсутствовавшие в первом слепке D, но появившиеся в следующем;
 - переходы из `created` в `paid`;
@@ -103,7 +143,7 @@ SELECT
 Возьмите отмененный заказ, у которого в вашей истории был статус `paid`.
 Укажите два наблюдения, доказывающих, что он был оплачен, а затем отменен.
 
-Теперь возьмите отмененный заказ, для которого ни в одной вашей выгрузке
+Теперь возьмите отмененный заказ, для которого ни в одном вашем наблюдении
 нет `paid`. Проверьте утверждение «этот заказ никогда не был оплачен»:
 что известно о его состоянии между двумя слепками? Достаточно ли сохраненных
 наблюдений для такого вывода?
@@ -111,7 +151,7 @@ SELECT
 Сформулируйте требования к данным для двух задач: восстановить состояние
 витрины на момент прошлого расчета и узнать, был ли заказ когда-либо оплачен.
 Какие сведения для каждой задачи должен передавать источник и сохранять
-хранилище? Проверьте предложение на своих выгрузках и на промежутке между ними.
+хранилище? Проверьте, каких нужных сведений нет в ваших таблицах наблюдений.
 
 ## Задайте правило пересчета
 
@@ -143,4 +183,6 @@ SELECT
       и правилом доставки слепков.
 
 После работы оставьте `world_live` на паузе либо верните автоматическое
-продвижение, если пользовались им до наблюдения.
+продвижение, если пользовались им до наблюдения. Таблицы истории останутся
+для повторной проверки выводов. Когда они больше не нужны, удалите только
+свои `default.lab_order_history` и `default.lab_revenue_history`.