Витрины DM: форма и состав #135

New Issue

2026-08-22T10:26:46+03:00

ddmitry commented

2026-08-22 10:26:46 +03:00

Part of #127.

Вопрос

Форма и состав слоя DM: база dm (в DDL её ещё нет), витрины
представлениями dm.*_v поверх DDS или материализованными таблицами,
устройство dm.dq_summary с партиционной заменой (политика «без
TRUNCATE»), состав по спеке §7 — revenue_daily_v,
purchase_vs_orders_v (сверка A+C с классами), utm_effectiveness_v,
daily_traffic_v (пара «посетители»/«известные пользователи»), переезд
ролей витрин v1 на dds.event_v — и что из этого получает Superset
этапом 8.

Сначала прочитать

мастер-спека, разделы 4 и 7 («Витрины DM»);
резолюции развилок модели заказа и контракта dds.event_v (блокеры);
docs/architecture/testing.md — куда встанут проверки витрин.

Part of #127. ## Вопрос Форма и состав слоя DM: база `dm` (в DDL её ещё нет), витрины представлениями `dm.*_v` поверх DDS или материализованными таблицами, устройство `dm.dq_summary` с партиционной заменой (политика «без TRUNCATE»), состав по спеке §7 — `revenue_daily_v`, `purchase_vs_orders_v` (сверка A+C с классами), `utm_effectiveness_v`, `daily_traffic_v` (пара «посетители»/«известные пользователи»), переезд ролей витрин v1 на `dds.event_v` — и что из этого получает Superset этапом 8. ## Сначала прочитать - мастер-спека, разделы 4 и 7 («Витрины DM»); - резолюции развилок модели заказа и контракта `dds.event_v` (блокеры); - `docs/architecture/testing.md` — куда встанут проверки витрин.

ddmitry added the wayfinder:grilling label 2026-08-22 10:26:49 +03:00

ddmitry added a new dependency 2026-08-22 10:27:11 +03:00

#130 Модель заказа в DDS: зерно, связи, материализация

ddmitry added a new dependency 2026-08-22 10:27:11 +03:00

#132 Контракт dds.event_v: атрибуты бизнес-модели

ddmitry added a new dependency 2026-08-22 10:27:12 +03:00

#134 Запуск трансформаций до etl_pipeline

ddmitry added a new dependency 2026-08-22 10:27:14 +03:00

#136 Нарезать тикеты этапа 4 по резолюциям карты

ddmitry referenced this issue

2026-08-22 10:27:31 +03:00

Карта: проектирование трансформаций и витрин (этап 4) #127

ddmitry referenced this issue

2026-08-25 10:22:59 +03:00

Запуск трансформаций до etl_pipeline #134

ddmitry self-assigned this 2026-08-25 10:29:30 +03:00

ddmitry referenced this issue from a commit

2026-08-25 11:40:34 +03:00

docs(dm): спроектирован слой витрин DM

ddmitry referenced a pull request that will close this issue

2026-08-25 11:40:43 +03:00

Слой витрин DM: форма по зерну, дележ с менти, контур DQ #147

ddmitry commented

2026-08-25 11:41:13 +03:00

Резолюция

Форма — по зерну, не по цене запроса. Витрина, меняющая зерно источника (дневной агрегат, сверка по заказам), материализуется: dm.<имя>_rep / _dist + публичное dm.<имя>_v, наполнение — дагом dm_transform, ритм пересборки — по подвижности источника: событийные и сессионные витрины догоняют хвост заменой дневных партиций, заказные дышат окном K, а daily_traffic вслед за картой идентичностей пересчитывается целиком каждый прогон в ReplacingMergeTree — дневных партиций у неё нет: партиция — единица замены, а витрина заменяется только целиком. Инкремент затронутых дней по first_matched_at стенду не нужен и стал идеей лабы повышенной сложности #149 (обсуждение горячего ревью). Витрина, сохраняющая зерно источника, остаётся представлением. На объёмах стенда всё обошлось бы представлениями (исследование #128), но учебная цель — показать, как строят хранилища: пересборка агрегатов партициями — производственный паттерн, а пара «таблица рядом с представлением» показывает, что форма — решение по роли.

Дележ витрин: стенд и менти. Стенд строит витрины трёх сюжетов дашборда этапа 8 и инфраструктуру контроля: revenue_daily (образец для ТЗ), purchase_vs_orders (сверка A+C, ко-локация заказов по cityHash64(order_id)), daily_traffic (пара «посетители»/«известные»), dq_summary. Остальные — учебные задания менти по ТЗ с образцом: разминка events_enriched_v, затем top_pages_daily, session_overview, dq_errors_daily, финалом utm_effectiveness с уроком declared_*. Построенная витрина встаёт в dm_transform руками менти — финальный пункт каждого ТЗ (горячее ревью). Дашборд этапа 8 стоит только на витринах стенда; расширение дашборда по своим витринам — домашка после этапа 8.

dm.dq_summary. Зерно «день данных × проверка», партиция — день данных, наполнение REPLACE PARTITION — политика «без TRUNCATE» той же механикой, что у витрин. Пишет её звено DQ.

Звено DQ конвейера (туман карты закрыт): встаёт в etl_pipeline после DM, проверяет только объекты стенда — счётная сверка сессий с эталоном VisitID из ods.event_v, счётчики классов расхождений против описи по закрытым дням, счётные сверки витрин с DDS-источниками. Рабочее DQ — само учебный материал: как контроль качества устроен в бою.

Даг самопроверки домашек — отдельный, без расписания, запуск рукой: задача витрины красная, пока не построено или не сходится, зелёная — когда верно; проверки — инварианты против источников, в dq_summary не пишет. Приём перенесён с соседнего учебного стенда Airflow + Greenplum (валидационный даг bookings_validate).

База dm заводится в DDL вместе с объектами слоя при нарезке. Нарезке же остаются: имена задач, ключи шардирования остальных витрин, тексты ТЗ, точный список проверок, механика сверки A+C в SQL (рамка — спека §4/§7).

Отклонённые варианты — в доке: весь слой представлениями; материализовать всё; гибрид по цене запроса; проверки домашек в конвейерном звене; «жёлтый» статус; самопроверка в dq_summary; Superset поверх DDS.

Дока: docs/architecture/dm.md (PR #147).

## Резолюция **Форма — по зерну, не по цене запроса.** Витрина, меняющая зерно источника (дневной агрегат, сверка по заказам), материализуется: `dm.<имя>_rep` / `_dist` + публичное `dm.<имя>_v`, наполнение — дагом `dm_transform`, ритм пересборки — по подвижности источника: событийные и сессионные витрины догоняют хвост заменой дневных партиций, заказные дышат окном K, а `daily_traffic` вслед за картой идентичностей пересчитывается целиком каждый прогон в ReplacingMergeTree — дневных партиций у неё нет: партиция — единица замены, а витрина заменяется только целиком. Инкремент затронутых дней по `first_matched_at` стенду не нужен и стал идеей лабы повышенной сложности #149 (обсуждение горячего ревью). Витрина, сохраняющая зерно источника, остаётся представлением. На объёмах стенда всё обошлось бы представлениями (исследование #128), но учебная цель — показать, как строят хранилища: пересборка агрегатов партициями — производственный паттерн, а пара «таблица рядом с представлением» показывает, что форма — решение по роли. **Дележ витрин: стенд и менти.** Стенд строит витрины трёх сюжетов дашборда этапа 8 и инфраструктуру контроля: `revenue_daily` (образец для ТЗ), `purchase_vs_orders` (сверка A+C, ко-локация заказов по `cityHash64(order_id)`), `daily_traffic` (пара «посетители»/«известные»), `dq_summary`. Остальные — учебные задания менти по ТЗ с образцом: разминка `events_enriched_v`, затем `top_pages_daily`, `session_overview`, `dq_errors_daily`, финалом `utm_effectiveness` с уроком `declared_*`. Построенная витрина встаёт в `dm_transform` руками менти — финальный пункт каждого ТЗ (горячее ревью). Дашборд этапа 8 стоит только на витринах стенда; расширение дашборда по своим витринам — домашка после этапа 8. **`dm.dq_summary`.** Зерно «день данных × проверка», партиция — день данных, наполнение `REPLACE PARTITION` — политика «без TRUNCATE» той же механикой, что у витрин. Пишет её звено DQ. **Звено DQ конвейера** (туман карты закрыт): встаёт в `etl_pipeline` после DM, проверяет только объекты стенда — счётная сверка сессий с эталоном `VisitID` из `ods.event_v`, счётчики классов расхождений против описи по закрытым дням, счётные сверки витрин с DDS-источниками. Рабочее DQ — само учебный материал: как контроль качества устроен в бою. **Даг самопроверки домашек** — отдельный, без расписания, запуск рукой: задача витрины красная, пока не построено или не сходится, зелёная — когда верно; проверки — инварианты против источников, в `dq_summary` не пишет. Приём перенесён с соседнего учебного стенда Airflow + Greenplum (валидационный даг `bookings_validate`). **База `dm`** заводится в DDL вместе с объектами слоя при нарезке. Нарезке же остаются: имена задач, ключи шардирования остальных витрин, тексты ТЗ, точный список проверок, механика сверки A+C в SQL (рамка — спека §4/§7). Отклонённые варианты — в доке: весь слой представлениями; материализовать всё; гибрид по цене запроса; проверки домашек в конвейерном звене; «жёлтый» статус; самопроверка в `dq_summary`; Superset поверх DDS. Дока: docs/architecture/dm.md (PR #147).

ddmitry closed this issue

2026-08-25 11:41:52 +03:00

ddmitry referenced this issue

2026-08-25 11:42:29 +03:00

Идея: домашки по слоям ниже DM — своя трансформация по ТЗ и образцу #148

ddmitry referenced this issue from a commit

2026-08-25 11:57:24 +03:00

docs(dm): вычитана дока слоя витрин

ddmitry referenced this issue

2026-08-25 13:32:15 +03:00

Идея лабы: инкрементальное обновление daily_traffic от first_matched_at #149

ddmitry referenced this issue