docs(labs): уточнены формулировки и шаги работы со связями

Зачем: сделать действия в двух лабораторных понятными студенту без
дополнительной расшифровки названий и временных обозначений.

Что: переименована первая работа, абстрактные заголовки заменены
конкретными действиями. Уточнены выбор копии списка связей и обновление
даты из журнала перед повтором загрузки. Выводы требуют сравнения данных.

Проверка: последовательное чтение глазами студента и независимая проверка
по исходникам; 81 локальная ссылка, неизменность SQL-блоков, diff --check.

docs/labs/optional/incremental-daily-traffic.md

@@ -4,20 +4,21 @@
 и повторять незавершенную загрузку.
 
 Факультатив повышенной сложности продолжает работу
-[«Когда хранилище узнало пользователя»](identity-over-time.md).
-Понадобятся ее запрос сохранения связей и таблица `default.lab_identity_history`.
+[«Как новые заказы меняют отчет о посетителях»](identity-over-time.md).
+Понадобятся ее запрос сохранения списка связей и таблица `default.lab_identity_history`.
 Работайте под `student` через то же подключение DBeaver.
 
 Стенд пересчитывает `dm.daily_traffic_v` целиком: новая связь может изменить
 число известных пользователей в старом дне. Вы построите рядом свою витрину,
 которая пересчитывает только затронутые дни и дает тот же результат.
 
-В опыте появляются новые дни сессий и новые связи. Мир стенда не отзывает
-связи и не исправляет старые сессии при обычном продвижении времени.
+При обычном продвижении модельного времени появляются новые дни сессий
+и новые связи. Уже найденные пары сохраняются, а сессии прежних дней
+не меняются.
 Удаление данных, исправления старых сессий и пересоздание мира потребовали бы
 другого способа обнаружения изменений.
 
-## Подготовьте витрину и журнал загрузок
+## Создайте витрину и журнал успешных загрузок
 
 Создайте две локальные таблицы. Если имена заняты, выберите свои.
 
@@ -41,93 +42,96 @@ ORDER BY observation_day;
 ```
 
 В витрине одна актуальная строка на день. Для обновления вставляйте полный
-новый результат дня с новой `observation_day`; читайте его с `FINAL`.
-Движок выбирает максимальную `observation_day` для каждого `report_date`.
-Старая версия может исчезнуть при слиянии: эта таблица хранит текущий расчет,
-а не историю наблюдений.
+новый результат дня с новой `observation_day`. Читайте витрину с `FINAL`:
+для каждого `report_date` останется строка с максимальной `observation_day`.
+Старые версии могут исчезнуть при слиянии,
+поэтому для воспроизведения прежнего расчета нужна сохраненная история связей.
 
-Журнал хранит даты успешно завершенных загрузок. Добавляйте дату только
-после записи всех выбранных дней и успешной сверки. Последняя строка журнала
-будет границей, от которой вы ищете новые связи в следующем прогоне.
+В журнал записывайте `observation_day` списка связей, использованного
+для расчета. Добавляйте дату только после записи всех выбранных дней
+и успешной сверки. Максимальная дата в журнале укажет, какой список
+использовался в последней завершенной загрузке.
 
 ## Выполните первую загрузку целиком
 
 Убедитесь, что `world_live` стоит на паузе и нет активных прогонов генерации
 и обработки. Запустите `etl_pipeline` и дождитесь успеха. Получите текущую
-`observation_day` способом из первой работы. Если такого наблюдения еще нет
-в вашей истории, сохраните его; уже сохраненную дату повторно не вставляйте.
+`observation_day` способом из первой работы. Если списка за эту дату еще нет
+в вашей истории, сохраните его. Повторно вставлять уже сохраненный список
+не требуется.
 
 Напишите `INSERT INTO ... SELECT`, который рассчитывает все даты сессий из
-`dds.session_v` со связями текущего наблюдения. Правила результата:
+`dds.session_v` со списком связей на текущую дату. Правила результата:
 
 | Колонка | Что считать |
 |---|---|
 | `report_date` | `session_date` |
 | `visitors` | число разных `client_id` |
 | `known_users` | число разных известных `user_id` |
-| `observation_day` | дата текущего наблюдения |
+| `observation_day` | дата выбранной копии списка связей |
 
-Сессии без известного пользователя сохраняйте. Несколько кук одного
-пользователя не должны увеличивать `known_users`. Для соединения с локальной
-историей связей используйте `GLOBAL LEFT JOIN`.
+Сессии без известного пользователя сохраняйте в расчете. Несколько кук одного
+пользователя не должны увеличивать `known_users`. Для соединения с вашей
+таблицей связей используйте `GLOBAL LEFT JOIN`, отобрав одну `observation_day`.
 
 Построчно сверьте свои `report_date`, `visitors`, `known_users` с
 `dm.daily_traffic_v`. Сверка должна находить лишние и отсутствующие даты
 и различия обоих показателей. Учебную витрину читайте с `FINAL`.
 После совпадения запишите дату наблюдения в журнал один раз.
 
-## Выберите дни следующего пересчета
+## Найдите дни, которые нужно пересчитать
 
 Продвиньте мир на один день: `world_next_day` с `days = 1`, затем
-`etl_pipeline`; после каждого запуска дождитесь успеха. Сохраните новое
-наблюдение связей запросом из первой работы.
+`etl_pipeline`; после каждого запуска дождитесь успеха. Сохраните новый
+список связей запросом из первой работы.
 
-Обозначим дату последней успешной загрузки из журнала **P**, текущую дату
-наблюдения — **H**. До записи результата составьте запрос, возвращающий
-разные даты для пересчета. Он должен учесть два изменения:
+Обозначим максимальную `observation_day` в журнале **P**, а дату нового
+списка связей — **H**. До записи результата составьте запрос, возвращающий
+даты для пересчета без повторов. Он должен учесть два изменения:
 
 - в сессиях появились дни, которых еще нет в вашей витрине;
-- в карте появились пары, которых не было при P; у этих кук есть сессии,
-  в том числе за прежние дни.
+- в списке на H появились пары, которых не было в списке на P; у этих кук
+  есть сессии, в том числе за прежние дни.
 
-Сначала выведите даты и разберите одну старую дату: какая новая пара привела
-к ее выбору и какие сессии с ней связаны? Рядом посчитайте, сколько дат
-пересчитала бы полная загрузка. Зафиксируйте оба числа; равенство тоже
-возможно, если новые связи затронули всю историю.
+Сначала выведите даты и выберите один прежний день: какая новая пара
+потребовала его пересчета и какие сессии с ней связаны? Рядом посчитайте,
+сколько дат пересчитала бы полная загрузка. Зафиксируйте оба числа;
+равенство тоже возможно, если новые связи затронули всю историю.
 
-Проверьте альтернативу: искать изменения по `first_purchase_at`, взяв покупки
-только после конца P. Сравните полученный набор пар с разностью наблюдений.
-Покажите пару, которую такое ограничение пропускает.
+Для сравнения выберите из списка на H пары, у которых день покупки
+по `first_purchase_at` позже P. Совпадет ли результат с новыми парами,
+найденными сравнением списков? Покажите пару, которую ограничение по дате
+покупки пропускает.
 
 ## Обновите выбранные дни
 
 Напишите второй `INSERT INTO ... SELECT`. Для выбранных дат он должен
-рассчитать все сессии с полной картой связей на H. Прибавление числа новых
+рассчитать все сессии с полным списком связей на H. Прибавление числа новых
 связей к прежнему `known_users` не заменяет пересчет разных пользователей.
 
 Вставьте результаты с версией H. Полностью сверьте актуальную учебную витрину
 со стендовой, включая дни, которые не пересчитывали. Только после совпадения
 добавьте H в журнал.
 
-Без продвижения мира повторите выбор дат. После успешной загрузки новых дат
-и пар быть не должно, а результат витрины должен остаться прежним.
+Без продвижения мира снова определите P по журналу и повторите выбор дат.
+Запрос должен вернуть пустой результат, а витрина — остаться прежней.
 Повторно записывать H в журнал не требуется.
 
-## Повторите незавершенную загрузку
+## Проверьте повторный запуск после частичной загрузки
 
 Снова запустите `world_next_day` с `days = 1`, затем `etl_pipeline`,
-дожидаясь успеха каждого. Сохраните новое наблюдение связей.
+дожидаясь успеха каждого. Сохраните новый список связей с его датой H.
 Получите даты для пересчета, но запишите результат только за одну из
 них. Остальные пока не загружайте и дату в журнал не добавляйте.
 Так вы воспроизведете остановку между записями дней, не ломая стенд.
 
-Запустите свой обычный расчет еще раз, определив P по журналу. Он должен
-довести загрузку до совпадения со стендовой витриной без очистки уже
-записанных строк. После сверки запишите H в журнал.
+Снова определите P по журналу, выполните запрос выбора дат и пересчет
+этих дней. Проверьте, что результат совпал со стендовой витриной без очистки
+уже записанных строк. После сверки запишите H в журнал.
 
-Объясните на этом опыте, почему последнее сохраненное наблюдение нельзя
-автоматически считать загруженным в витрину. Что изменится, если записать H
-в журнал до обновления витрины?
+Объясните на этом опыте, почему сохранение нового списка связей еще
+не означает, что витрина обновлена. Что изменится, если записать H в журнал
+до обновления витрины?
 
 ## Что должно получиться
 
@@ -136,9 +140,9 @@ ORDER BY observation_day;
 повтор без новых данных сохраняет результат, а незавершенную загрузку
 можно продолжить без полной пересборки.
 
-Сравните цену двух вариантов: сколько дней вы пересчитывали и какие
-дополнительные данные хранили. По этому опыту можно судить об объеме работы,
-но не об ускорении: на небольшом стенде полный пересчет может быть дешевле.
+Сравните число пересчитанных дней с полной загрузкой и перечислите,
+какие дополнительные данные пришлось хранить. Так можно оценить объем работы.
+На небольшом стенде полный пересчет может быть дешевле.
 В вашей реализации поиск связей пока читает всю историю покупок —
 инкрементальным стал именно пересчет дневной витрины.