Этап 4: трансформации и витрины, сверка A+C #6

Closed
opened 2026-07-30 16:41:39 +03:00 by ddmitry · 2 comments
Owner

Part of #1

Цель этапа: собрать трансформации и витрины — сессии, карта идентичностей, выручка по заказам и сверка события purchase против заказов на расхождениях A и C.

Спека: docs/specs/2026-07-30-stand-v2-realism.md, разделы 4 и 7.

Дочерние тикеты

Этап начат с проектирования: маршрут прокладывает карта #127 —
развилки модели DDS, запуска трансформаций и витрин; нарезка тикетов
исполнения — её финальный тикет #136.

  • #127 — карта: проектирование трансформаций и витрин

Нарезка исполнения — резолюция #136; порядок — цепочка нативных блокировок,
с порога открыты #150 и #157 (#151 следует за контрактом события из #150):

  • #150 — контракт события: представление dds.event_v
  • #151 — модель заказа в DDS: dds.order и пересборка окна
  • #152 — сессии: dds.session и нарезка визитов
  • #153 — карта идентичностей: dds.identity_map и полный пересчёт
  • #154 — витрины стенда: даг dm_transform, revenue_daily и daily_traffic
  • #155 — сверка purchase против заказов: dm.purchase_vs_orders (A+C)
  • #156 — конвейер etl_pipeline: сцепка дагов и пути запуска
  • #157 — опись мира: счётчики классов A и C
  • #158 — звено DQ конвейера и dm.dq_summary
  • #159 — учебные задания витрин DM и даг самопроверки

Наблюдаемые критерии приёмки этапа

Стандартные цели зелены (make lint, make config-test и все три
стендовые: make smoke, make check-clickhouse, make check-services —
правило приёмки этапа из testing.md) — и сверх них этап наблюдаем так:

  • На чистом прикладном мире подъём заканчивается собранным стендом:
    DDS наполнен за все дни стартового мира, витрины стенда свежие, звено
    DQ зелёное — без единого ручного шага.
  • Живой день (world_live_day) зелёный: сессии получили новый день,
    окно заказов пересобрано, витрины и dq_summary догнали.
  • Повторный ручной запуск etl_pipeline без нового дня не меняет
    делового содержимого публичных _v.
  • dm.purchase_vs_orders_v показывает match, cancelled, amount_delta,
    awaiting_order; в днях закрытого окна счётчики классов сходятся с
    описью мира.
  • Счётная сверка сессий с эталоном VisitID — нулевое расхождение по
    всем собранным дням.
  • daily_traffic: «известные» ≤ «посетителей»; свежая покупка делает
    куку известной во всех её прошлых днях.
  • Потребительские запросы и витрины читают _v; роль bi читает
    ODS, DDS и DM, но получает отказ при чтении STG.
Part of #1 Цель этапа: собрать трансформации и витрины — сессии, карта идентичностей, выручка по заказам и сверка события `purchase` против заказов на расхождениях A и C. Спека: docs/specs/2026-07-30-stand-v2-realism.md, разделы 4 и 7. ## Дочерние тикеты Этап начат с проектирования: маршрут прокладывает карта #127 — развилки модели DDS, запуска трансформаций и витрин; нарезка тикетов исполнения — её финальный тикет #136. - [x] #127 — карта: проектирование трансформаций и витрин Нарезка исполнения — резолюция #136; порядок — цепочка нативных блокировок, с порога открыты #150 и #157 (#151 следует за контрактом события из #150): - [x] #150 — контракт события: представление dds.event_v - [x] #151 — модель заказа в DDS: dds.order и пересборка окна - [x] #152 — сессии: dds.session и нарезка визитов - [x] #153 — карта идентичностей: dds.identity_map и полный пересчёт - [x] #154 — витрины стенда: даг dm_transform, revenue_daily и daily_traffic - [x] #155 — сверка purchase против заказов: dm.purchase_vs_orders (A+C) - [x] #156 — конвейер etl_pipeline: сцепка дагов и пути запуска - [x] #157 — опись мира: счётчики классов A и C - [x] #158 — звено DQ конвейера и dm.dq_summary - [x] #159 — учебные задания витрин DM и даг самопроверки ## Наблюдаемые критерии приёмки этапа Стандартные цели зелены (make lint, make config-test и все три стендовые: make smoke, make check-clickhouse, make check-services — правило приёмки этапа из testing.md) — и сверх них этап наблюдаем так: - [x] На чистом прикладном мире подъём заканчивается собранным стендом: DDS наполнен за все дни стартового мира, витрины стенда свежие, звено DQ зелёное — без единого ручного шага. - [x] Живой день (world_live_day) зелёный: сессии получили новый день, окно заказов пересобрано, витрины и dq_summary догнали. - [x] Повторный ручной запуск etl_pipeline без нового дня не меняет делового содержимого публичных `_v`. - [x] dm.purchase_vs_orders_v показывает match, cancelled, amount_delta, awaiting_order; в днях закрытого окна счётчики классов сходятся с описью мира. - [x] Счётная сверка сессий с эталоном VisitID — нулевое расхождение по всем собранным дням. - [x] daily_traffic: «известные» ≤ «посетителей»; свежая покупка делает куку известной во всех её прошлых днях. - [x] Потребительские запросы и витрины читают `_v`; роль `bi` читает ODS, DDS и DM, но получает отказ при чтении STG.
ddmitry added a new dependency 2026-07-30 16:51:38 +03:00
ddmitry added a new dependency 2026-07-30 16:51:38 +03:00
Author
Owner

Хвост с приёмки #36 — вопрос к нарезке этого этапа, не решение.

Владелец, разбирая контракт схемы события, заметил странность в карте слоёв
(мастер-спека, раздел 7):

| DDS | dds.v_event | представление над ods.event: snake_case-имена,
расшифровка кодов DeviceCategory; витрины DM читают его, а не ODS
напрямую |

Странность в источнике: DDS — слой, где складывается модель данных, а здесь
он выходит переименовывающим представлением над типизированным сырьём.
Теоретически так бывает, но выглядит скорее опиской, чем замыслом: соседние
объекты того же слоя (dds.session, dds.identity_map, dds.order) —
именно модель, а не вид на ODS.

Проверить при нарезке этапа: либо строка правится и событие приходит в DDS
смоделированным объектом, либо решение осознанное — и тогда в спеке ему
нужен довод одной фразой, чтобы следующий читатель не спотыкался.

Связь с #36: контракт генератора несёт нормализованное имя колонки — имя
источника в нашем стиле. Имена атрибутов модели он намеренно не диктует
(уточнено в спеке генератора, раздел 3), так что этот вопрос открыт по
замыслу и ничего не блокирует.

Хвост с приёмки #36 — вопрос к нарезке этого этапа, не решение. Владелец, разбирая контракт схемы события, заметил странность в карте слоёв (мастер-спека, раздел 7): > | DDS | `dds.v_event` | представление над `ods.event`: snake_case-имена, > расшифровка кодов `DeviceCategory`; витрины DM читают его, а не ODS > напрямую | Странность в источнике: DDS — слой, где складывается модель данных, а здесь он выходит переименовывающим представлением над типизированным сырьём. Теоретически так бывает, но выглядит скорее опиской, чем замыслом: соседние объекты того же слоя (`dds.session`, `dds.identity_map`, `dds.order`) — именно модель, а не вид на ODS. Проверить при нарезке этапа: либо строка правится и событие приходит в DDS смоделированным объектом, либо решение осознанное — и тогда в спеке ему нужен довод одной фразой, чтобы следующий читатель не спотыкался. Связь с #36: контракт генератора несёт нормализованное имя колонки — имя источника в нашем стиле. Имена атрибутов модели он намеренно не диктует (уточнено в спеке генератора, раздел 3), так что этот вопрос открыт по замыслу и ничего не блокирует.
ddmitry self-assigned this 2026-08-22 10:16:39 +03:00
Author
Owner

Приёмка этапа пройдена 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 без падений;
  • живой день (28 м 00 с) добавил 2026-06-09: 10 371 сессия, окно заказов пересобрано, витрины и dq_summary догнали;
  • повторный ручной 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 в нём отсутствует;
  • сверка сессий с эталоном VisitID — нулевое расхождение по всем девяти собранным дням, независимый прогон SQL под ролью etl дал те же счётчики;
  • daily_traffic: нарушений «известные ≤ посетителей» нет; свежие покупки сделали куки известными в их прошлых днях — карта идентичностей выросла 1590 → 1830 при неизменных счётчиках посетителей прошлых дней;
  • роль bi читает ODS, DDS, DM и словарь; чтение STG — ACCESS_DENIED, код 497.

Оговорка к прочтению критериев: заказы и revenue_daily по замыслу отстают на день от прожитого (правило снапшота D−1, etl.md) — после дня 2026-06-09 заказные данные заканчиваются 2026-06-08.

Прогон вёл Codex по протоколу приёмки, ключевые цифры перепроверены оркестратором по живому стенду.

Приёмка этапа пройдена 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 без падений; - живой день (28 м 00 с) добавил 2026-06-09: 10 371 сессия, окно заказов пересобрано, витрины и dq_summary догнали; - повторный ручной `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 в нём отсутствует; - сверка сессий с эталоном VisitID — нулевое расхождение по всем девяти собранным дням, независимый прогон SQL под ролью etl дал те же счётчики; - daily_traffic: нарушений «известные ≤ посетителей» нет; свежие покупки сделали куки известными в их прошлых днях — карта идентичностей выросла 1590 → 1830 при неизменных счётчиках посетителей прошлых дней; - роль bi читает ODS, DDS, DM и словарь; чтение STG — ACCESS_DENIED, код 497. Оговорка к прочтению критериев: заказы и revenue_daily по замыслу отстают на день от прожитого (правило снапшота D−1, etl.md) — после дня 2026-06-09 заказные данные заканчиваются 2026-06-08. Прогон вёл Codex по протоколу приёмки, ключевые цифры перепроверены оркестратором по живому стенду.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Reference: ddmitry/clickstream-data-platform#6