Инвентаризация сюжетов лаб по слоям стенда #201
Assignees
ddmitry (Dmitry Dementiev)
Clear assignees
ddmitry (Dmitry Dementiev)
No Assignees
ddmitry
ddmitry
Notifications
Due Date
No due date set.
Blocks
#202 Спека программы лаб
ddmitry/clickstream-data-platform
Reference: ddmitry/clickstream-data-platform#201
Reference in new issue
Block a user
Part of #182
Вопрос
Полный веер сюжетов для лаб — вместо семи случайно накопленных идей. Пройти стенд по слоям (STG, ODS, DDS, DM, BI) и поперёк слоёв (Airflow-переобработка по партициям, сверка purchase vs orders, опоздания и закрытие дня, мониторинг и runbook) и выписать: чему на каждом участке можно научить, на каком материале стенда и в какой форме — построить своё, переписать удалённое, расследовать расхождение.
Отдельно проверить гипотезу формы нижних слоёв «вычитание + DQ»: менти удаляет SQL трансформаций потока (даги не трогаются) и пишет заново, DQ-инварианты подсказывают, сошлось ли. Где на STG/ODS граница между кодом, который можно отдать на переписывание, и несущей стеной (приём из Kafka, таблицы *_errors)? Чем проверяется пересобранный слой там, куда homework_check и dq_check не смотрят, и где кончается эталон?
Сырьё: шесть заданий docs/labs/ и идеи #143, #145, #148 (с уточнением в комментарии), #149, #186, #187, #188.
Итог — research-заметка в docs/research/: веер без отбора, отбирать будет спека программы.
Инвентаризация готова: docs/research/2026-08-31-labs-inventory.md (в рабочем дереве, не закоммичен).
32 сюжета по участкам: STG — 5, ODS — 4, DDS — 6, DM — 4 (плюс готовое ядро шести заданий docs/labs/), BI — 1, поперек слоев — 12 (переобработка по партициям, классы A–D сверки, опоздания и закрытие дня, мониторинг и runbook). Каждый — фразой-уроком, материалом с путями, формой и проверкой; идеи #143, #145, #148, #149, #186–#188 разложены по своим участкам.
Главный вывод по гипотезе «вычитание + DQ»: она верна не как правило нижних слоев, а как описание одного потока — сессий DDS (внешний эталон VisitID, проверка не содержит ответа). Заказы DDS и разбор заказов ODS проходят по схеме «сначала построй сторожа, потом ломай»: недостающие инварианты — сами учебный материал. STG и прием событий на «удали и перепиши» не отдаются (код и есть стена, у событий логика живет в DDL); их форма — расследования и «собери рядом». Общая дыра всех счетных сверок — раскладка по шардам: пересчет ключа по hostName() должен входить в ТЗ каждого вычитания.