ddmitry/airflow-greenplum
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

refactor(all): унифицированы служебные поля STG — переход на канонический нейминг

Browse Source 
- Зачем:
  - STG-слой использовал legacy-имена (batch_id, load_dttm, src_created_at_ts),
    тогда как ODS/DDS/DM уже работали с каноном (_load_id, _load_ts, event_ts).
    Студент видел разные имена для одного понятия — это убрано.
- Что:
  - переименованы колонки в 9 STG DDL: batch_id→_load_id, load_dttm→_load_ts,
    src_created_at_ts→event_ts; добавлен NOT NULL для _load_id во всех таблицах.
  - обновлены 9 STG Load, 9 STG DQ, 9 ODS Load, 9 ODS DQ (INSERT/SELECT/WHERE).
  - обновлены DAG-файлы bookings_to_gp_stage.py и bookings_to_gp_ods.py
    (встроенный SQL резолвера, комментарии; Python-идентификаторы не тронуты).
  - обновлены тесты и ~15 документов (naming_conventions, PRD, db_schema,
    design-docs, qa-plan, README, TESTING и др.).
- Проверка:
  - grep -rn 'load_dttm\|src_created_at_ts' sql/ airflow/ tests/ — 0 совпадений.
  - make test — 4 passed.
  - e2e-etl: day1 прошёл полностью, day2 стартовал без ошибок.
This commit is contained in:
ddadmin
2026-03-10 00:07:08 +03:00
parent 3de4db8aa6
commit 5972bcc2d8
64 changed files with 582 additions and 484 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/internal/bookings_stg_code_review.md
+8 -8
View File
@@ -44,16 +44,16 @@
### 2.2. DQ-проверки ссылочной целостности: “текущий батч” vs “вся история” (статус: исправлено)
Часть DQ-скриптов проверяет наличие “родительских” записей в таблице **без фильтра `batch_id`**.
Часть DQ-скриптов проверяет наличие “родительских” записей в таблице **без фильтра `_load_id`**.
При append-only истории это может скрыть проблемы текущей загрузки:
родитель был загружен в прошлом батче → проверка пройдёт, даже если текущий батч родителя не загрузил.
Что сделано:
- `routes_dq.sql`: проверка airports/airplanes стала батч-строгой (`batch_id = текущий батч`).
- `seats_dq.sql`: проверка airplanes стала батч-строгой (`batch_id = текущий батч`).
- `flights_dq.sql`: проверка routes стала батч-строгой (`batch_id = текущий батч`).
- `routes_dq.sql`: проверка airports/airplanes стала батч-строгой (`_load_id = текущий батч`).
- `seats_dq.sql`: проверка airplanes стала батч-строгой (`_load_id = текущий батч`).
- `flights_dq.sql`: проверка routes стала батч-строгой (`_load_id = текущий батч`).
Примечание (почему не везде `batch_id = текущий батч`):
Примечание (почему не везде `_load_id = текущий батч`):
- Если дочерняя таблица грузится инкрементом, то ссылки могут указывать на “исторические” записи,
загруженные в предыдущих батчах → для таких связей корректнее проверять “существует в STG вообще”.
- Для `boarding_passes` (full snapshot) ссылки на `tickets/segments` также проверяются по STG-истории,
@@ -94,11 +94,11 @@
Типовой паттерн:
```sql
WHERE NOT EXISTS (
SELECT 1 FROM stg.table WHERE batch_id = '{{ run_id }}' AND key = ext.key
SELECT 1 FROM stg.table WHERE _load_id = '{{ run_id }}' AND key = ext.key
);
```
Это в первую очередь защита от повторного запуска того же таска в рамках одного `batch_id` (retry),
Это в первую очередь защита от повторного запуска того же таска в рамках одного `_load_id` (retry),
а не “лечение” дублей в источнике.
Что сделано:
@@ -126,7 +126,7 @@ WHERE NOT EXISTS (
```sql
LEFT JOIN stg.airports AS a
ON r.departure_airport = a.airport_code
AND a.batch_id = v_batch_id
AND a._load_id = v_batch_id
```
### 4.2. Smoke-тест реального графа (минимальный полезный уровень)