Move STG->ODS to Airflow batch and align monitoring

plans/clickhouse_ddl.md

@@ -31,16 +31,16 @@
 
 Эта схема укладывается в задание так:
 
-- **Kafka → STG → ODS** можно сделать полностью внутри ClickHouse через `ENGINE = Kafka` + MV (стриминг, 1 json = 1 row).
-- “**регулярный процесс**” — батч‑трансформации `ODS → DDS (→ DM)` в виде SQL (`INSERT INTO … SELECT …`) по расписанию (в будущем Airflow; пока — ручной запуск).
-- Airflow (когда появится) можно использовать как **тонкий оркестратор**: применить DDL и запускать batch‑SQL по расписанию.
+- **Kafka → STG** реализуется внутри ClickHouse через `ENGINE = Kafka` + MV (стриминг, 1 json = 1 row).
+- “**регулярный процесс**” — батч‑трансформации `STG → ODS → DDS (→ DM)` в виде SQL (`INSERT INTO … SELECT …`) по расписанию (Airflow).
+- Airflow используется как основной оркестратор batch‑шагов и DQ‑проверок.
 
 ### Выбранное решение (MVP)
 
 Чтобы сделать “хорошо, но без оверинжиниринга”, фиксируем такое MVP:
 
-- **STG → ODS** — инкрементально через MV (парсинг/типизация рядом с ingest).
-- **DDS** — батч‑сборка из ODS через SQL (`INSERT INTO … SELECT …`) как “регулярный процесс”.
+- **STG → ODS** — batch через SQL (`sql/ods/20_stg_to_ods.sql`) внутри `etl_pipeline`.
+- **DDS** — batch‑сборка из ODS через SQL (`INSERT INTO … SELECT …`) как “регулярный процесс”.
   - Причина: `MV + JOIN` в `ODS → DDS` плохо переносит произвольный порядок прихода данных и может давать некорректные результаты (eventual consistency ODS, версии в разных партициях и т.п.).
 - **DM** — `VIEW` (витрины “на чтении”) поверх DDS, чтобы не плодить лишние таблицы и джобы под демо.
 - На стороне BI считаем, что запросы всегда идут с фильтрами по времени (`event_date`/`event_ts`) и не сканируют всю историю.
@@ -75,10 +75,10 @@ flowchart LR
     v_dq[dm.v_dq_errors_daily]
   end
 
-  stg_browser -->|MV parse| ods_browser
-  stg_location -->|MV parse| ods_location
-  stg_device -->|MV parse| ods_device
-  stg_geo -->|MV parse| ods_geo
+  stg_browser -->|Batch SQL| ods_browser
+  stg_location -->|Batch SQL| ods_location
+  stg_device -->|Batch SQL| ods_device
+  stg_geo -->|Batch SQL| ods_geo
 
   ods_browser -->|Batch SQL| dds_event
   ods_location -->|Batch SQL| dds_event
@@ -125,7 +125,7 @@ flowchart LR
 
 - `sql/ddl/00_databases.sql` — базы `stg/ods/dds/dm`.
 - `sql/ddl/stg/10_stg.sql` — STG raw (`stg.*_raw`) + Kafka source tables (`ENGINE = Kafka`) + MV `Kafka → STG`.
-- `sql/ddl/ods/20_ods.sql` — ODS таблицы типизации + DQ (`parse_errors`) + MV `STG → ODS` + таблицы `ods_*_errors` для строк с битыми ключами.
+- `sql/ddl/ods/20_ods.sql` — ODS таблицы типизации + DQ (`parse_errors`) + удаление legacy MV `STG → ODS`.
 - `sql/ddl/dds/30_dds.sql` — DDS таблицы (`dds.event`, `dds.click`) **без MV** (только `CREATE TABLE`).
 - `sql/ddl/dm/40_dm.sql` — витрины `VIEW` для Superset (`dm.v_*`).
 
@@ -136,13 +136,17 @@ BI-ограничения (ресурсы/пользователь) **не вы
 - `sql/dds/30_ods_to_dds.sql` — регулярная батч‑сборка DDS из ODS:
   - получить “последнюю версию” строк по ключам (`event_id`/`click_id`) через `argMax(..., src_ingest_ts)` (или эквивалент);
   - выполнить join snapshot’ов и загрузить в `dds.event`/`dds.click` (для демо возможно “full rebuild”; позже — инкрементально).
+- `sql/ods/20_stg_to_ods.sql` — регулярная батч‑сборка ODS из STG:
+  - очистить ODS (`TRUNCATE`) перед пересборкой;
+  - типизировать валидные строки в `ods.*`;
+  - сложить критичные ошибки парсинга в `ods.*_errors`.
 
 ### Исполнение DDL (make сейчас / Airflow потом)
 
 Требования к файлам `sql/*/*.sql`:
 
 - идемпотентность (`IF NOT EXISTS`), чтобы повторные прогоны были безопасны;
-- строгий порядок исполнения: `00 → 10 → 20 → 30 → 40` (из‑за зависимостей MV);
+- строгий порядок исполнения: `00 → 10 → 20 → 30 → 40` (из‑за зависимостей объектов);
 - единые имена топиков Kafka: `browser_events`, `location_events`, `device_events`, `geo_events` (их создаёт `make data`).
 
 ### Дедупликация и обработка “битых” ключей (ODS)
@@ -167,8 +171,8 @@ BI-ограничения (ресурсы/пользователь) **не вы
 
 Batch‑трансформации (целевое, для реализации следующим шагом):
 
-- `make transform` (или аналогичная команда) запускает `sql/dds/30_ods_to_dds.sql` через `clickhouse-client`;
-- в будущем Airflow будет делать то же самое по расписанию (один job‑SQL = один task).
+- `make transform` (или аналогичная команда) запускает `sql/ods/20_stg_to_ods.sql`, `sql/dds/30_ods_to_dds.sql` и `sql/dm/40_dds_to_dm.sql` через `clickhouse-client`;
+- Airflow может выполнять те же шаги как отдельные task (с ретраями и мониторингом).
 
 ### Параметры окружения (docker compose)