Этап 4: трансформации и витрины, сверка A+C #6
Notifications
Due Date
No due date set.
Blocks
Depends on
#7 Этап 5: Airflow — etl_pipeline
ddmitry/clickstream-data-platform
#5 Этап 3: заказы и каталог
ddmitry/clickstream-data-platform
#65 Цели make смешивают два уровня: корень репозитория и генератор
ddmitry/clickstream-data-platform
Reference: ddmitry/clickstream-data-platform#6
Reference in new issue
Block a user
Part of #1
Цель этапа: собрать трансформации и витрины — сессии, карта идентичностей, выручка по заказам и сверка события
purchaseпротив заказов на расхождениях A и C.Спека: docs/specs/2026-07-30-stand-v2-realism.md, разделы 4 и 7.
Дочерние тикеты
Этап начат с проектирования: маршрут прокладывает карта #127 —
развилки модели DDS, запуска трансформаций и витрин; нарезка тикетов
исполнения — её финальный тикет #136.
Нарезка исполнения — резолюция #136; порядок — цепочка нативных блокировок,
с порога открыты #150 и #157 (#151 следует за контрактом события из #150):
Наблюдаемые критерии приёмки этапа
Стандартные цели зелены (make lint, make config-test и все три
стендовые: make smoke, make check-clickhouse, make check-services —
правило приёмки этапа из testing.md) — и сверх них этап наблюдаем так:
DDS наполнен за все дни стартового мира, витрины стенда свежие, звено
DQ зелёное — без единого ручного шага.
окно заказов пересобрано, витрины и dq_summary догнали.
делового содержимого публичных
_v.awaiting_order; в днях закрытого окна счётчики классов сходятся с
описью мира.
всем собранным дням.
куку известной во всех её прошлых днях.
_v; рольbiчитаетODS, DDS и DM, но получает отказ при чтении STG.
Хвост с приёмки #36 — вопрос к нарезке этого этапа, не решение.
Владелец, разбирая контракт схемы события, заметил странность в карте слоёв
(мастер-спека, раздел 7):
Странность в источнике: DDS — слой, где складывается модель данных, а здесь
он выходит переименовывающим представлением над типизированным сырьём.
Теоретически так бывает, но выглядит скорее опиской, чем замыслом: соседние
объекты того же слоя (
dds.session,dds.identity_map,dds.order) —именно модель, а не вид на ODS.
Проверить при нарезке этапа: либо строка правится и событие приходит в DDS
смоделированным объектом, либо решение осознанное — и тогда в спеке ему
нужен довод одной фразой, чтобы следующий читатель не спотыкался.
Связь с #36: контракт генератора несёт нормализованное имя колонки — имя
источника в нашем стиле. Имена атрибутов модели он намеренно не диктует
(уточнено в спеке генератора, раздел 3), так что этот вопрос открыт по
замыслу и ничего не блокирует.
ddmitry referenced this issue2026-08-22 10:40:53 +03:00
Приёмка этапа пройдена 2026-08-28, прогон на чистом прикладном мире.
Стандартные цели: lint и config-test зелёные; smoke — пройдено 21, ошибок 0, время 19 с; check-clickhouse — все 10 проверок; check-services — пройдено 7, ошибок 0, время 106 с (флейк #172 не проявился).
Наблюдаемые критерии — все семь подтверждены:
make rebuild-storageза 7 м 03 с довёл стенд до собранного без единого ручного шага: DDS за все 8 дней стартового мира, витрины свежие, пять проверок DQ без падений;etl_pipeline(2 м 18 с) не изменил делового содержимого публичных_v: пары (count, hash) совпали по всем десяти представлениям;dm.purchase_vs_orders_v: match=1573, cancelled=67, amount_delta=22, awaiting_order=255; классов этапа 6 нет; закрытый день 2026-06-01 сходится с описью мира (197/20/6), awaiting_order в нём отсутствует;Оговорка к прочтению критериев: заказы и revenue_daily по замыслу отстают на день от прожитого (правило снапшота D−1, etl.md) — после дня 2026-06-09 заказные данные заканчиваются 2026-06-08.
Прогон вёл Codex по протоколу приёмки, ключевые цифры перепроверены оркестратором по живому стенду.