From faf410b4e8d6e5e884a455cf55d65afec5483b3c Mon Sep 17 00:00:00 2001 From: Dmitry Dementev Date: Sun, 1 Mar 2026 17:52:59 +0300 Subject: [PATCH] =?UTF-8?q?docs(review):=20=D0=B4=D0=BE=D0=B1=D0=B0=D0=B2?= =?UTF-8?q?=D0=BB=D0=B5=D0=BD=20P0-=D0=B1=D0=B0=D0=B3=20=E2=80=94=20=D0=BF?= =?UTF-8?q?=D0=BE=D1=82=D0=B5=D1=80=D1=8F=20=D0=B4=D0=B0=D0=BD=D0=BD=D1=8B?= =?UTF-8?q?=D1=85=20=D0=BF=D1=80=D0=B8=20=D0=B4=D0=B2=D0=BE=D0=B9=D0=BD?= =?UTF-8?q?=D0=BE=D0=BC=20STG-=D0=B7=D0=B0=D0=BF=D1=83=D1=81=D0=BA=D0=B5?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - Зачем: - обнаружена проблема: ODS batch resolver берёт только последний batch, транзакционные данные промежуточных STG-запусков теряются навсегда. - Что: - добавлен P0 в architecture_review.md с описанием сценария и решения. - обновлена сводная таблица трудозатрат. - Проверка: - cat docs/internal/architecture_review.md | grep -A5 "batch resolver теряет". --- docs/internal/architecture_review.md | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/docs/internal/architecture_review.md b/docs/internal/architecture_review.md index 3f362b8..a233a4a 100644 --- a/docs/internal/architecture_review.md +++ b/docs/internal/architecture_review.md @@ -53,6 +53,16 @@ GP-специфичная best practice, которую забывают даж ### P0: Фактическая ошибка (исправить до показа студентам) +- [ ] **ODS batch resolver теряет данные при двух STG-запусках подряд** + - Сценарий: STG run_1 загружает день N, STG run_2 загружает день N+1, затем ODS запускается + - `_resolve_stg_batch_id()` выбирает только последний согласованный batch (`run_2`) + - Все ODS load-скрипты фильтруют `WHERE batch_id = 'run_2'` → данные `run_1` навсегда пропущены + - **Справочники** (airports, airplanes, routes, seats): проблемы нет — full snapshot, `run_2` содержит всё + - **Транзакционные таблицы** (bookings, tickets, flights, segments, boarding_passes): **потеря данных** — инкрементальные записи `run_1` никогда не попадут в ODS + - Корень проблемы: batch resolver проектировался для согласованности справочников (INTERSECT), но тот же single-batch фильтр применяется к транзакционным таблицам, где нужны **все необработанные** batch-и + - **Нужно**: разделить логику — для транзакционных таблиц загружать все batch-и с `_load_ts > MAX(_load_ts в ODS)` (аналог HWM из DM), для справочников — по-прежнему последний согласованный + - Файлы: `airflow/dags/bookings_to_gp_ods.py`, `sql/ods/bookings_load.sql`, `sql/ods/tickets_load.sql`, `sql/ods/flights_load.sql`, `sql/ods/segments_load.sql`, `sql/ods/boarding_passes_load.sql` + - [x] **Противоречие в distribution key для airport_traffic** - `bookings_dm_design.md` (строка 182): `DISTRIBUTED BY (traffic_date)` - `sales_report_ddl.sql`: явно объясняет, почему distribution by date — антипаттерн @@ -143,7 +153,8 @@ GP-специфичная best practice, которую забывают даж | Приоритет | Действие | Оценка | Ключевые файлы | |-----------|----------|--------|----------------| -| **P0** | Исправить distribution key в airport_traffic | 5 мин | `docs/internal/bookings_dm_design.md` | +| **P0** | ODS batch resolver: разделить логику для справочников и транзакций | 2-3 часа | ODS DAG + 5 транзакционных load-скриптов | +| ~~P0~~ | ~~Исправить distribution key в airport_traffic~~ | ~~5 мин~~ | ~~done~~ | | **P1** | Добавить 7 точечных комментариев | 30-40 мин | 6-7 файлов (DDL, load, DAG) | | **P2** | Рефакторинг hashdiff → TEMP TABLE | 1 час | `sql/dds/dim_routes_load.sql` | | **P2** | Переименовать STG поля в канон + заметка | 1-2 часа | 27 STG SQL + ODS load + naming_conventions.md |