refactor(all): унифицированы служебные поля STG — переход на канонический нейминг
- Зачем:
- 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:
@@ -7,7 +7,7 @@
|
||||
|
||||
- Определяет `stg_batch_id`:
|
||||
- берёт из `dag_run.conf["stg_batch_id"]`, если передан;
|
||||
- иначе берёт последний **согласованный** `batch_id`, который есть во всех snapshot-таблицах STG
|
||||
- иначе берёт последний **согласованный** `_load_id`, который есть во всех snapshot-таблицах STG
|
||||
(`airports`, `airplanes`, `routes`, `seats`).
|
||||
- Загружает 9 таблиц ODS (`airports`, `airplanes`, `routes`, `seats`, `bookings`, `tickets`,
|
||||
`flights`, `segments`, `boarding_passes`).
|
||||
|
||||
@@ -63,15 +63,15 @@ make bookings-init
|
||||
- выполняет `sql/stg/bookings_load.sql` в Greenplum;
|
||||
- берёт строки из `stg.bookings_ext`, которые попадают в новое окно инкремента;
|
||||
- вставляет их в `stg.bookings`, добавляя тех.колонки:
|
||||
- `src_created_at_ts` (опорная метка времени для инкремента),
|
||||
- `load_dttm`,
|
||||
- `batch_id={{ run_id }}`.
|
||||
- `event_ts` (опорная метка времени для инкремента),
|
||||
- `_load_ts`,
|
||||
- `_load_id={{ run_id }}`.
|
||||
|
||||
3) `check_row_counts`
|
||||
|
||||
- выполняет `sql/stg/bookings_dq.sql` в Greenplum;
|
||||
- считает количество строк в источнике за то же окно инкремента и сравнивает с количеством строк,
|
||||
вставленных в `stg.bookings` для текущего `batch_id`;
|
||||
вставленных в `stg.bookings` для текущего `_load_id`;
|
||||
- при расхождении делает `RAISE EXCEPTION` с понятным текстом.
|
||||
|
||||
4) `load_tickets_to_stg`
|
||||
@@ -79,7 +79,7 @@ make bookings-init
|
||||
- выполняет `sql/stg/tickets_load.sql` в Greenplum;
|
||||
- так как в `bookings.tickets` нет явной временной колонки, окно инкремента берётся по `book_date`
|
||||
из связанной внешней таблицы `stg.bookings_ext` (JOIN по `book_ref`);
|
||||
- вставляет строки в `stg.tickets`, добавляя `src_created_at_ts`, `load_dttm` и `batch_id={{ run_id }}`.
|
||||
- вставляет строки в `stg.tickets`, добавляя `event_ts`, `_load_ts` и `_load_id={{ run_id }}`.
|
||||
|
||||
5) `check_tickets_dq`
|
||||
|
||||
@@ -135,11 +135,11 @@ make gp-psql
|
||||
SELECT COUNT(*) FROM stg.bookings;
|
||||
|
||||
SELECT
|
||||
src_created_at_ts,
|
||||
load_dttm,
|
||||
batch_id
|
||||
event_ts,
|
||||
_load_ts,
|
||||
_load_id
|
||||
FROM stg.bookings
|
||||
ORDER BY src_created_at_ts DESC
|
||||
ORDER BY event_ts DESC
|
||||
LIMIT 10;
|
||||
```
|
||||
|
||||
|
||||
@@ -53,7 +53,7 @@ end-to-end ETL-пайплайн: от базы-источника до анал
|
||||
(STG → ODS → DDS → DM) на реальном стеке Airflow + Greenplum.
|
||||
2. **Читать ТЗ от аналитика** (маппинги, описания таблиц) и превращать его
|
||||
в работающий SQL + DAG.
|
||||
3. **Писать идемпотентные загрузки** с инкрементальностью (HWM, batch_id,
|
||||
3. **Писать идемпотентные загрузки** с инкрементальностью (HWM, _load_id,
|
||||
delete+insert), понимая, почему в Greenplum не используется MERGE.
|
||||
4. **Реализовывать SCD1/SCD2** и объяснять, когда что применяется.
|
||||
5. **Настраивать и проверять Data Quality** — понимает, зачем DQ-проверки
|
||||
@@ -210,7 +210,7 @@ solution (полное решение)
|
||||
- [ ] SQL идемпотентен (повторный запуск не ломает данные)
|
||||
- [ ] Distribution keys выбраны осмысленно
|
||||
- [ ] Студент может объяснить: почему delete+insert, а не MERGE;
|
||||
разницу SCD1/SCD2; что такое HWM; как работает batch_id
|
||||
разницу SCD1/SCD2; что такое HWM; как работает _load_id
|
||||
- [ ] Код оформлен для портфолио (чистый Git-history, README)
|
||||
|
||||
---
|
||||
|
||||
@@ -45,7 +45,7 @@ LEFT JOIN dds.dim_routes AS rte
|
||||
GP-специфичная best practice, которую забывают даже опытные команды.
|
||||
|
||||
### 9. Идемпотентные STG-загрузки
|
||||
`NOT EXISTS (... WHERE batch_id = '{{ run_id }}')` — простой, корректный, понятный паттерн для retry-safe загрузок.
|
||||
`NOT EXISTS (... WHERE _load_id = '{{ run_id }}')` — простой, корректный, понятный паттерн для retry-safe загрузок.
|
||||
|
||||
---
|
||||
|
||||
@@ -56,7 +56,7 @@ GP-специфичная best practice, которую забывают даж
|
||||
- [x] **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` навсегда пропущены
|
||||
- Все ODS load-скрипты фильтруют `WHERE _load_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-и
|
||||
@@ -117,12 +117,11 @@ GP-специфичная best practice, которую забывают даж
|
||||
- **Решение**: вынесено в CREATE TEMP TABLE tmp_routes_src ON COMMIT DROP ✅ ВЫПОЛНЕНО
|
||||
- Файл: `sql/dds/dim_routes_load.sql`
|
||||
|
||||
- [ ] **Несогласованность нейминга STG vs ODS+** ✅ РЕШЕНИЕ ПРИНЯТО
|
||||
- STG: `batch_id`, `load_dttm`, `src_created_at_ts` → переименовать в канон `_load_id`, `_load_ts`, `event_ts`
|
||||
- [x] **Несогласованность нейминга STG vs ODS+** ✅ ВЫПОЛНЕНО
|
||||
- STG: `batch_id`, `load_dttm`, `src_created_at_ts` → переименованы в канон `_load_id`, `_load_ts`, `event_ts`
|
||||
- Единый словарь во всех слоях снижает когнитивную нагрузку
|
||||
- Добавить заметку в `naming_conventions.md` (секция «legacy-нейминг в реальных проектах»)
|
||||
- Удалить секцию 6 «Переходный маппинг» как неактуальную
|
||||
- Файлы: ~27 STG SQL + ODS load-скрипты + `naming_conventions.md` + тесты
|
||||
- Секция 6 «Переходный маппинг» удалена из `naming_conventions.md` как неактуальная
|
||||
- Файлы: 27 STG SQL + ODS load-скрипты + `naming_conventions.md` + тесты
|
||||
|
||||
- [x] **Дублирование CTE в ODS load-скриптах**
|
||||
- `WITH src AS (...)` копируется 2-3 раза в каждом из 9 ODS load-файлов
|
||||
@@ -149,7 +148,7 @@ GP-специфичная best practice, которую забывают даж
|
||||
- [ ] **Отсутствующие паттерны** (комментарии/заметки):
|
||||
- Partitioning (когда и зачем, почему не здесь)
|
||||
- SCD Type 3/6 (хотя бы упомянуть существование)
|
||||
- Data lineage (`_load_id` в DM ≠ `batch_id` в STG — нет сквозного трассирования)
|
||||
- Data lineage (сквозное трассирование `_load_id` через STG → ODS → DDS → DM)
|
||||
|
||||
---
|
||||
|
||||
@@ -296,7 +295,7 @@ DROP TABLE tmp_fact_20170102;
|
||||
| ~~P1~~ | ~~Добавить 7 точечных комментариев~~ | ~~30-40 мин~~ | ~~done~~ |
|
||||
| **P2** | Явный storage type + AO где нет UPDATE (ADR-3) | 2-3 часа | все `*_ddl.sql` в ods/dds/dm + 4 ODS snapshot load |
|
||||
| **P2** | Рефакторинг hashdiff → TEMP TABLE | 1 час | `sql/dds/dim_routes_load.sql` |
|
||||
| **P2** | Переименовать STG поля в канон + заметка | 1-2 часа | 27 STG SQL + ODS load + naming_conventions.md |
|
||||
| ~~P2~~ | ~~Переименовать STG поля в канон + заметка~~ | ~~1-2 часа~~ | ~~done~~ |
|
||||
| **P2** | TEMP TABLE для сложных ODS load-ов | 1 час | 3-4 ODS load файла |
|
||||
| **P2** | Реализовать `dm.route_performance` | 2-3 часа | 3 SQL + DAG + тесты |
|
||||
| **P3** | Маршрут изучения DDS + distribution strategy doc | 1 час | 2 новых md-файла |
|
||||
|
||||
@@ -5,7 +5,7 @@
|
||||
STG-слой уже реализован как учебный эталон:
|
||||
- данные из `bookings-db` читаются через PXF;
|
||||
- в STG бизнес-колонки хранятся как `TEXT`;
|
||||
- загрузка и DQ работают батчами (`batch_id = {{ run_id }}`).
|
||||
- загрузка и DQ работают батчами (`_load_id = {{ run_id }}`).
|
||||
|
||||
Этот документ фиксирует **простую и каноничную** реализацию ODS для менти.
|
||||
|
||||
@@ -36,7 +36,7 @@ ODS в учебном проекте — это:
|
||||
|
||||
### 1.3. Где хранится история изменений
|
||||
|
||||
- История «как приходили данные» уже сохраняется в STG (append + `batch_id`).
|
||||
- История «как приходили данные» уже сохраняется в STG (append + `_load_id`).
|
||||
- Историзацию измерений (SCD2) показываем позже в DDS (как в учебной статье `dwh-modeling`).
|
||||
|
||||
Итог: **ODS = текущий слой (current state), простой и понятный**.
|
||||
@@ -55,9 +55,9 @@ ODS в учебном проекте — это:
|
||||
|
||||
### 2.1. Маппинг из текущего STG
|
||||
|
||||
- `stg.batch_id` -> `ods._load_id`
|
||||
- `stg.load_dttm` не переносим 1:1; в ODS пишем собственный `ods._load_ts = now()`
|
||||
- `stg.src_created_at_ts` -> `ods.event_ts` (для транзакционных таблиц)
|
||||
- `stg._load_id` -> `ods._load_id`
|
||||
- `stg._load_ts` не переносим 1:1; в ODS пишем собственный `ods._load_ts = now()`
|
||||
- `stg.event_ts` -> `ods.event_ts` (для транзакционных таблиц)
|
||||
|
||||
### 2.2. Почему так
|
||||
|
||||
@@ -239,8 +239,8 @@ DISTRIBUTED BY (ticket_no)
|
||||
| `flights` | `flight_id` | `flight_id` | `INTEGER` | Только cast TEXT → INT |
|
||||
| `segments` | `flight_id` | `flight_id` | `INTEGER` | Только cast TEXT → INT |
|
||||
| `boarding_passes` | `flight_id` | `flight_id` | `INTEGER` | Только cast TEXT → INT |
|
||||
| все транзакционные | `src_created_at_ts` | `event_ts` | `TIMESTAMP` | Маппинг legacy → канон |
|
||||
| все | `batch_id` | `_load_id` | `TEXT` | Маппинг legacy → канон |
|
||||
| все транзакционные | `event_ts` | `event_ts` | `TIMESTAMP` | Прямой перенос (канон) |
|
||||
| все | `_load_id` | `_load_id` | `TEXT` | Прямой перенос (канон) |
|
||||
|
||||
Пример каста с переименованием в SQL (в CTE):
|
||||
```sql
|
||||
@@ -282,32 +282,32 @@ def _resolve_stg_batch_id(**context):
|
||||
stg_batch_id = conf.get("stg_batch_id")
|
||||
|
||||
if not stg_batch_id:
|
||||
# Берём batch_id, который присутствует во всех snapshot-таблицах STG:
|
||||
# Берём _load_id, который присутствует во всех snapshot-таблицах STG:
|
||||
# airports, airplanes, routes, seats. Это защищает от частично успешных запусков.
|
||||
hook = PostgresHook(postgres_conn_id=GREENPLUM_CONN_ID)
|
||||
result = hook.get_first(
|
||||
'''
|
||||
WITH candidate_batches AS (
|
||||
SELECT batch_id FROM stg.airports WHERE batch_id IS NOT NULL GROUP BY batch_id
|
||||
SELECT _load_id FROM stg.airports WHERE _load_id IS NOT NULL GROUP BY _load_id
|
||||
INTERSECT
|
||||
SELECT batch_id FROM stg.airplanes WHERE batch_id IS NOT NULL GROUP BY batch_id
|
||||
SELECT _load_id FROM stg.airplanes WHERE _load_id IS NOT NULL GROUP BY _load_id
|
||||
INTERSECT
|
||||
SELECT batch_id FROM stg.routes WHERE batch_id IS NOT NULL GROUP BY batch_id
|
||||
SELECT _load_id FROM stg.routes WHERE _load_id IS NOT NULL GROUP BY _load_id
|
||||
INTERSECT
|
||||
SELECT batch_id FROM stg.seats WHERE batch_id IS NOT NULL GROUP BY batch_id
|
||||
SELECT _load_id FROM stg.seats WHERE _load_id IS NOT NULL GROUP BY _load_id
|
||||
),
|
||||
batch_ready AS (
|
||||
SELECT
|
||||
c.batch_id,
|
||||
c._load_id,
|
||||
GREATEST(
|
||||
(SELECT MAX(load_dttm) FROM stg.airports a WHERE a.batch_id = c.batch_id),
|
||||
(SELECT MAX(load_dttm) FROM stg.airplanes a WHERE a.batch_id = c.batch_id),
|
||||
(SELECT MAX(load_dttm) FROM stg.routes r WHERE r.batch_id = c.batch_id),
|
||||
(SELECT MAX(load_dttm) FROM stg.seats s WHERE s.batch_id = c.batch_id)
|
||||
(SELECT MAX(_load_ts) FROM stg.airports a WHERE a._load_id = c._load_id),
|
||||
(SELECT MAX(_load_ts) FROM stg.airplanes a WHERE a._load_id = c._load_id),
|
||||
(SELECT MAX(_load_ts) FROM stg.routes r WHERE r._load_id = c._load_id),
|
||||
(SELECT MAX(_load_ts) FROM stg.seats s WHERE s._load_id = c._load_id)
|
||||
) AS ready_dttm
|
||||
FROM candidate_batches c
|
||||
)
|
||||
SELECT batch_id
|
||||
SELECT _load_id
|
||||
FROM batch_ready
|
||||
ORDER BY ready_dttm DESC
|
||||
LIMIT 1
|
||||
@@ -334,7 +334,7 @@ resolve_batch = PythonOperator(
|
||||
Во всех `sql/ods/*_load.sql` и `sql/ods/*_dq.sql` значение `stg_batch_id` подставляется через Jinja-шаблон:
|
||||
|
||||
```sql
|
||||
WHERE batch_id = '{{ ti.xcom_pull(task_ids="resolve_stg_batch_id") }}'::text
|
||||
WHERE _load_id = '{{ ti.xcom_pull(task_ids="resolve_stg_batch_id") }}'::text
|
||||
```
|
||||
|
||||
Для читаемости в DAG можно вынести шаблон в константу:
|
||||
@@ -370,7 +370,7 @@ WITH src AS (
|
||||
coordinates,
|
||||
timezone
|
||||
FROM stg.airports
|
||||
WHERE batch_id = '{{ ti.xcom_pull(task_ids="resolve_stg_batch_id") }}'::text
|
||||
WHERE _load_id = '{{ ti.xcom_pull(task_ids="resolve_stg_batch_id") }}'::text
|
||||
)
|
||||
UPDATE ods.airports AS o
|
||||
SET airport_name = s.airport_name,
|
||||
@@ -403,7 +403,7 @@ WITH src AS (
|
||||
coordinates,
|
||||
timezone
|
||||
FROM stg.airports
|
||||
WHERE batch_id = '{{ ti.xcom_pull(task_ids="resolve_stg_batch_id") }}'::text
|
||||
WHERE _load_id = '{{ ti.xcom_pull(task_ids="resolve_stg_batch_id") }}'::text
|
||||
)
|
||||
INSERT INTO ods.airports (
|
||||
airport_code, airport_name, city, country, coordinates, timezone,
|
||||
@@ -423,7 +423,7 @@ WHERE NOT EXISTS (
|
||||
WITH src_keys AS (
|
||||
SELECT DISTINCT airport_code
|
||||
FROM stg.airports
|
||||
WHERE batch_id = '{{ ti.xcom_pull(task_ids="resolve_stg_batch_id") }}'::text
|
||||
WHERE _load_id = '{{ ti.xcom_pull(task_ids="resolve_stg_batch_id") }}'::text
|
||||
)
|
||||
DELETE FROM ods.airports o
|
||||
WHERE NOT EXISTS (
|
||||
@@ -447,13 +447,13 @@ WITH src AS (
|
||||
book_ref,
|
||||
book_date::TIMESTAMP WITH TIME ZONE AS book_date,
|
||||
total_amount::NUMERIC(10,2) AS total_amount,
|
||||
src_created_at_ts AS event_ts,
|
||||
event_ts,
|
||||
ROW_NUMBER() OVER (
|
||||
PARTITION BY book_ref
|
||||
ORDER BY src_created_at_ts DESC NULLS LAST, load_dttm DESC
|
||||
ORDER BY event_ts DESC NULLS LAST, _load_ts DESC
|
||||
) AS rn
|
||||
FROM stg.bookings
|
||||
WHERE batch_id = '{{ ti.xcom_pull(task_ids="resolve_stg_batch_id") }}'::text
|
||||
WHERE _load_id = '{{ ti.xcom_pull(task_ids="resolve_stg_batch_id") }}'::text
|
||||
)
|
||||
UPDATE ods.bookings AS o
|
||||
SET book_date = s.book_date,
|
||||
@@ -475,13 +475,13 @@ WITH src AS (
|
||||
book_ref,
|
||||
book_date::TIMESTAMP WITH TIME ZONE AS book_date,
|
||||
total_amount::NUMERIC(10,2) AS total_amount,
|
||||
src_created_at_ts AS event_ts,
|
||||
event_ts,
|
||||
ROW_NUMBER() OVER (
|
||||
PARTITION BY book_ref
|
||||
ORDER BY src_created_at_ts DESC NULLS LAST, load_dttm DESC
|
||||
ORDER BY event_ts DESC NULLS LAST, _load_ts DESC
|
||||
) AS rn
|
||||
FROM stg.bookings
|
||||
WHERE batch_id = '{{ ti.xcom_pull(task_ids="resolve_stg_batch_id") }}'::text
|
||||
WHERE _load_id = '{{ ti.xcom_pull(task_ids="resolve_stg_batch_id") }}'::text
|
||||
)
|
||||
INSERT INTO ods.bookings (
|
||||
book_ref, book_date, total_amount, event_ts,
|
||||
@@ -547,7 +547,7 @@ SELECT COUNT(*)
|
||||
FROM (
|
||||
SELECT DISTINCT book_ref
|
||||
FROM stg.bookings
|
||||
WHERE batch_id = '{{ ti.xcom_pull(task_ids="resolve_stg_batch_id") }}'::text
|
||||
WHERE _load_id = '{{ ti.xcom_pull(task_ids="resolve_stg_batch_id") }}'::text
|
||||
) s
|
||||
WHERE NOT EXISTS (
|
||||
SELECT 1
|
||||
@@ -694,7 +694,7 @@ SELECT COUNT(*)
|
||||
FROM (
|
||||
SELECT DISTINCT book_ref
|
||||
FROM stg.bookings
|
||||
WHERE batch_id = '<stg_batch_id>'
|
||||
WHERE _load_id = '<stg_batch_id>'
|
||||
) s
|
||||
WHERE NOT EXISTS (
|
||||
SELECT 1
|
||||
|
||||
@@ -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-тест реального графа (минимальный полезный уровень)
|
||||
|
||||
@@ -48,11 +48,11 @@ DDL определён в `sql/stg/bookings_ddl.sql` и подключается
|
||||
|
||||
Технологические колонки:
|
||||
|
||||
- `src_created_at_ts TIMESTAMP` — дата/время из источника, приведённая к TIMESTAMP:
|
||||
- `event_ts TIMESTAMP` — дата/время из источника, приведённая к TIMESTAMP:
|
||||
- используется как опорная колонка для инкрементальной загрузки;
|
||||
- заполняется из опорной даты/времени, принятой для конкретной сущности (например, для `bookings` — из `book_date`).
|
||||
- `load_dttm TIMESTAMP NOT NULL DEFAULT now()` — когда запись была загружена в STG.
|
||||
- `batch_id TEXT NOT NULL` — идентификатор «пачки» (например, `{{ ds_nodash }}` или `run_id` Airflow).
|
||||
- `_load_ts TIMESTAMP NOT NULL DEFAULT now()` — когда запись была загружена в STG.
|
||||
- `_load_id TEXT NOT NULL` — идентификатор «пачки» (например, `{{ run_id }}` Airflow).
|
||||
- при необходимости позже можно добавить `src_system TEXT`, если появятся другие источники.
|
||||
|
||||
Колонки‑бизнес‑ключи (`booking_id` и т.п.) храним как `TEXT`. В слое DDS позже можно будет ввести суррогатные ключи и нормализовать модель под витрины.
|
||||
@@ -61,20 +61,20 @@ DDL определён в `sql/stg/bookings_ddl.sql` и подключается
|
||||
|
||||
### 3.1. Опорное поле для инкремента
|
||||
|
||||
- Опорная колонка: `src_created_at_ts` (внутреннее имя в STG).
|
||||
- Опорная колонка: `event_ts` (внутреннее имя в STG).
|
||||
- Источник значения:
|
||||
- для `bookings` используем `book_date` из `bookings.bookings` (в демо‑БД это поле естественно “шагает” по дням);
|
||||
- при чтении через `stg.bookings_ext` приводим к `TIMESTAMP` и сохраняем в `stg.bookings.src_created_at_ts`.
|
||||
- при чтении через `stg.bookings_ext` приводим к `TIMESTAMP` и сохраняем в `stg.bookings.event_ts`.
|
||||
|
||||
### 3.2. Правила определения full/delta
|
||||
|
||||
- При первом запуске, если таблица `stg.bookings` пуста:
|
||||
- считаем режим `full` — загружаем все строки из `stg.bookings_ext`.
|
||||
- При последующих запусках:
|
||||
- читаем `max(src_created_at_ts)` из `stg.bookings` за все предыдущие загрузки;
|
||||
- загружаем строки, где `src_created_at_ts` больше этой максимальной метки (верхняя граница по времени не задаётся).
|
||||
- читаем `max(event_ts)` из `stg.bookings` за все предыдущие загрузки;
|
||||
- загружаем строки, где `event_ts` больше этой максимальной метки (верхняя граница по времени не задаётся).
|
||||
|
||||
Таким образом, вся логика инкремента «замкнута» на один техно‑столбец `src_created_at_ts`, который студент потом сможет использовать и на следующих слоях (например, в CDC‑логике).
|
||||
Таким образом, вся логика инкремента «замкнута» на один техно‑столбец `event_ts`, который студент потом сможет использовать и на следующих слоях (например, в CDC‑логике).
|
||||
|
||||
## 4. DAG’и Airflow (логика на уровне задач)
|
||||
|
||||
@@ -92,7 +92,7 @@ DDL определён в `sql/stg/bookings_ddl.sql` и подключается
|
||||
|
||||
- `dag_id`: `bookings_to_gp_stage`.
|
||||
- Основные параметры:
|
||||
- `batch_id` (в текущей реализации `{{ run_id }}`) — метка батча, которая попадает в `stg.bookings.batch_id`;
|
||||
- `_load_id` (в текущей реализации `{{ run_id }}`) — метка батча, которая попадает в `stg.bookings._load_id`;
|
||||
- подключения:
|
||||
- `bookings_db_conn_id` — Airflow connection к `bookings-db` (в коде DAG — `BOOKINGS_CONN_ID = "bookings_db"`);
|
||||
- `greenplum_conn_id` — Airflow connection к Greenplum (`GREENPLUM_CONN_ID = "greenplum_conn"`).
|
||||
@@ -108,16 +108,16 @@ DDL определён в `sql/stg/bookings_ddl.sql` и подключается
|
||||
2. `load_bookings_to_stg`
|
||||
- PostgresOperator к Greenplum;
|
||||
- выполняет скрипт `/sql/stg/bookings_load.sql`;
|
||||
- внутри SQL считается `max(src_created_at_ts)` по «старым» батчам и по нему строится окно инкремента:
|
||||
- внутри SQL считается `max(event_ts)` по «старым» батчам и по нему строится окно инкремента:
|
||||
- первая загрузка (full) — берём все строки из `stg.bookings_ext`;
|
||||
- последующие загрузки — берём только записи, где `book_date` больше предыдущего максимума (верхняя граница по дате не задаётся явно);
|
||||
- при вставке заполняются тех.колонки `src_created_at_ts`, `load_dttm`, `batch_id`.
|
||||
- при вставке заполняются тех.колонки `event_ts`, `_load_ts`, `_load_id`.
|
||||
3. `check_row_counts`
|
||||
- PostgresOperator к Greenplum;
|
||||
- выполняет скрипт `/sql/stg/bookings_dq.sql`;
|
||||
- скрипт заново считает окно инкремента по тем же правилам, что и загрузка, и сравнивает:
|
||||
- количество строк в `stg.bookings_ext` с `book_date` позже «старого» максимума,
|
||||
- количество строк в `stg.bookings` для текущего `batch_id`;
|
||||
- количество строк в `stg.bookings` для текущего `_load_id`;
|
||||
- при расхождении выполняет `RAISE EXCEPTION` с понятным текстом ошибки.
|
||||
4. Далее — загрузка и DQ для остальных таблиц потока (tickets, справочники, транзакции).
|
||||
5. `finish_summary`
|
||||
|
||||
+16
-16
@@ -40,11 +40,11 @@
|
||||
- **Назначение**: Сырой слой, максимально близкий к источнику, без бизнес-логики
|
||||
- **Хранение**: AO-Row (Append-Only Row-oriented) для эффективной загрузки больших объёмов
|
||||
- **Типы данных**: Бизнес-колонки как `TEXT`, тех.колонки как `TIMESTAMP`
|
||||
- **Инкрементальная загрузка**: Опорное поле `src_created_at_ts` (из `book_date` для tickets)
|
||||
- **Инкрементальная загрузка**: Опорное поле `event_ts` (из `book_date` для tickets)
|
||||
- **Технологические колонки**:
|
||||
- `src_created_at_ts TIMESTAMP` — дата/время из источника для инкремента
|
||||
- `load_dttm TIMESTAMP NOT NULL DEFAULT now()` — когда запись была загружена
|
||||
- `batch_id TEXT` — идентификатор пачки (рекомендуем `NOT NULL`, например `{{ ds_nodash }}` или `{{ run_id }}`)
|
||||
- `event_ts TIMESTAMP` — дата/время из источника для инкремента
|
||||
- `_load_ts TIMESTAMP NOT NULL DEFAULT now()` — когда запись была загружена
|
||||
- `_load_id TEXT` — идентификатор пачки/батча (например `{{ run_id }}`)
|
||||
- **DQ-проверки (после загрузки STG)**: отдельные SQL-скрипты, которые валидируют данные (counts, дубли, NULL, orphan records) и при ошибке делают `RAISE EXCEPTION`; примеры: `sql/stg/bookings_dq.sql`, `sql/stg/tickets_dq.sql`
|
||||
|
||||
#### ODS (Operational Data Store)
|
||||
@@ -105,7 +105,7 @@
|
||||
- `book_ref TEXT` - номер бронирования
|
||||
- `book_date TEXT` - дата бронирования
|
||||
- `total_amount TEXT` - общая сумма
|
||||
- **Технические колонки:** `src_created_at_ts` (=book_date), `load_dttm`, `batch_id`
|
||||
- **Технические колонки:** `event_ts` (=book_date), `_load_ts`, `_load_id`
|
||||
- **Стратегия загрузки:** Инкремент по `book_date`
|
||||
- **DQ проверки:** count (окно инкремента, пустое окно допустимо), дубликаты book_ref, NULL обязательных полей
|
||||
|
||||
@@ -119,7 +119,7 @@
|
||||
- `passenger_id TEXT` - идентификатор пассажира
|
||||
- `passenger_name TEXT` - имя пассажира
|
||||
- `outbound TEXT` - направление (в источнике boolean)
|
||||
- **Технические колонки:** `src_created_at_ts` (из book_date через bookings), `load_dttm`, `batch_id`
|
||||
- **Технические колонки:** `event_ts` (из book_date через bookings), `_load_ts`, `_load_id`
|
||||
- **Стратегия загрузки:** Инкремент по `book_date` (через bookings)
|
||||
- **DQ проверки:** count (окно инкремента, пустое окно допустимо), дубликаты ticket_no, NULL обязательных полей, пустой passenger_name, ссылочная целостность (bookings)
|
||||
|
||||
@@ -133,7 +133,7 @@
|
||||
- `country TEXT` - страна (из JSONB)
|
||||
- `coordinates TEXT` - координаты
|
||||
- `timezone TEXT` - часовой пояс
|
||||
- **Технические колонки:** `src_created_at_ts`, `load_dttm`, `batch_id`
|
||||
- **Технические колонки:** `event_ts` (=now()), `_load_ts`, `_load_id`
|
||||
- **Стратегия загрузки:** Full load (все строки при каждом запуске)
|
||||
- **DQ проверки:** count, дубликаты airport_code, NULL обязательных полей
|
||||
|
||||
@@ -145,7 +145,7 @@
|
||||
- `model TEXT` - модель (из JSONB)
|
||||
- `range TEXT` - дальность полёта
|
||||
- `speed TEXT` - скорость
|
||||
- **Технические колонки:** `src_created_at_ts`, `load_dttm`, `batch_id`
|
||||
- **Технические колонки:** `event_ts` (=now()), `_load_ts`, `_load_id`
|
||||
- **Стратегия загрузки:** Full load
|
||||
- **DQ проверки:** count, дубликаты airplane_code, NULL обязательных полей
|
||||
|
||||
@@ -162,9 +162,9 @@
|
||||
- `days_of_week TEXT` - дни недели (из int[])
|
||||
- `scheduled_time TEXT` - плановое время
|
||||
- `duration TEXT` - длительность
|
||||
- **Технические колонки:** `src_created_at_ts`, `load_dttm`, `batch_id`
|
||||
- **Технические колонки:** `event_ts` (=now()), `_load_ts`, `_load_id`
|
||||
- **Стратегия загрузки:** Full load
|
||||
- **DQ проверки:** count, дубликаты (route_no, validity), NULL обязательных полей, ссылочная целостность (batch_id = текущий батч)
|
||||
- **DQ проверки:** count, дубликаты (route_no, validity), NULL обязательных полей, ссылочная целостность (_load_id = текущий батч)
|
||||
|
||||
#### stg.seats (справочник, full load)
|
||||
- **Источник:** `bookings.seats` (через PXF)
|
||||
@@ -173,9 +173,9 @@
|
||||
- `airplane_code TEXT` - код самолёта
|
||||
- `seat_no TEXT` - номер места
|
||||
- `fare_conditions TEXT` - класс обслуживания
|
||||
- **Технические колонки:** `src_created_at_ts`, `load_dttm`, `batch_id`
|
||||
- **Технические колонки:** `event_ts` (=now()), `_load_ts`, `_load_id`
|
||||
- **Стратегия загрузки:** Full load
|
||||
- **DQ проверки:** count, дубликаты (airplane_code, seat_no), NULL обязательных полей, ссылочная целостность (batch_id = текущий батч)
|
||||
- **DQ проверки:** count, дубликаты (airplane_code, seat_no), NULL обязательных полей, ссылочная целостность (_load_id = текущий батч)
|
||||
|
||||
#### stg.flights (транзакции, инкремент)
|
||||
- **Источник:** `bookings.flights` (через PXF)
|
||||
@@ -189,9 +189,9 @@
|
||||
- `scheduled_arrival TEXT` - плановое время прилёта
|
||||
- `actual_departure TEXT` - фактическое время вылета
|
||||
- `actual_arrival TEXT` - фактическое время прилёта
|
||||
- **Технические колонки:** `src_created_at_ts` (=scheduled_departure), `load_dttm`, `batch_id`
|
||||
- **Технические колонки:** `event_ts` (=scheduled_departure), `_load_ts`, `_load_id`
|
||||
- **Стратегия загрузки:** Инкремент по `scheduled_departure`
|
||||
- **DQ проверки:** count (окно инкремента, пустое окно допустимо), дубликаты flight_id, NULL обязательных полей, ссылочная целостность (routes, batch_id = текущий батч)
|
||||
- **DQ проверки:** count (окно инкремента, пустое окно допустимо), дубликаты flight_id, NULL обязательных полей, ссылочная целостность (routes, _load_id = текущий батч)
|
||||
|
||||
#### stg.segments (транзакции, инкремент)
|
||||
- **Источник:** `bookings.segments` (через PXF)
|
||||
@@ -202,7 +202,7 @@
|
||||
- `flight_id TEXT` - идентификатор рейса
|
||||
- `fare_conditions TEXT` - класс обслуживания
|
||||
- `price TEXT` - цена
|
||||
- **Технические колонки:** `src_created_at_ts` (из book_date через tickets), `load_dttm`, `batch_id`
|
||||
- **Технические колонки:** `event_ts` (из book_date через tickets), `_load_ts`, `_load_id`
|
||||
- **Стратегия загрузки:** Инкремент по `book_date` (через tickets)
|
||||
- **DQ проверки:** count (окно инкремента, пустое окно допустимо), дубликаты (ticket_no, flight_id), NULL обязательных полей, ссылочная целостность (tickets, flights)
|
||||
|
||||
@@ -216,7 +216,7 @@
|
||||
- `seat_no TEXT` - номер места
|
||||
- `boarding_no TEXT` - номер посадки
|
||||
- `boarding_time TEXT` - время посадки
|
||||
- **Технические колонки:** `src_created_at_ts` (=now()), `load_dttm`, `batch_id`
|
||||
- **Технические колонки:** `event_ts` (=now()), `_load_ts`, `_load_id`
|
||||
- **Стратегия загрузки:** Full snapshot (все строки при каждом запуске)
|
||||
- **DQ проверки:** count, дубликаты (ticket_no, flight_id), NULL обязательных полей, ссылочная целостность
|
||||
|
||||
|
||||
@@ -40,21 +40,17 @@
|
||||
|
||||
- `event_ts` (effective time) и `_load_ts` (load time) — разные сущности, не смешиваем.
|
||||
- Если `event_ts` отсутствует в источнике, используем `_load_ts` как fallback и явно документируем это в SQL/доке.
|
||||
- Для snapshot-справочников (airports, airplanes, routes, seats) в STG нет бизнес-события с точным временем: `event_ts` заполняется через `now()` при загрузке. Это намеренно и задокументировано в каждом load-скрипте.
|
||||
|
||||
## 5. Применение по слоям
|
||||
|
||||
### STG
|
||||
|
||||
- Для уже реализованного `bookings` STG сохраняем текущие legacy-имена ради обратной совместимости:
|
||||
- `src_created_at_ts`
|
||||
- `load_dttm`
|
||||
- `batch_id`
|
||||
- Для новых STG-объектов (новые домены/задачи) используем канон `_load_id`, `_load_ts` (и `event_ts`, если нужно).
|
||||
- Используем канон `_load_id`, `_load_ts`, `event_ts` для всех таблиц.
|
||||
|
||||
### ODS
|
||||
|
||||
- В новых реализациях используем канон:
|
||||
- `_load_id`, `_load_ts`, `event_ts`.
|
||||
- Используем канон `_load_id`, `_load_ts`, `event_ts`.
|
||||
- Базовый эталон ODS в этом стенде: SCD Type 1 (current state + UPSERT).
|
||||
|
||||
### DDS
|
||||
@@ -63,17 +59,7 @@
|
||||
- `valid_from`, `valid_to`, `hashdiff`, `created_at`, `updated_at`.
|
||||
- Интервалы считаем как `[valid_from, valid_to)`, current-версия: `valid_to IS NULL`.
|
||||
|
||||
## 6. Переходный маппинг legacy -> канон
|
||||
|
||||
| Legacy (текущий bookings STG) | Канон |
|
||||
|---|---|
|
||||
| `batch_id` | `_load_id` |
|
||||
| `load_dttm` | `_load_ts` |
|
||||
| `src_created_at_ts` | `event_ts` |
|
||||
|
||||
Примечание: это логический маппинг для новых слоёв. Массовое переименование существующего STG не требуется.
|
||||
|
||||
## 7. Что проверяем в ревью
|
||||
## 6. Что проверяем в ревью
|
||||
|
||||
- Нет новых техполей-синнонимов вроде `loaded_at`, `ingested_at`, `batch_key`, если уже есть канон.
|
||||
- Нет смешивания `event_ts` и `_load_ts` в одном смысле.
|
||||
|
||||
+19
-24
@@ -136,23 +136,22 @@ UNION ALL SELECT 'boarding_passes',
|
||||
|
||||
```sql
|
||||
-- Снапшот-таблицы: ODS = последний батч STG
|
||||
-- Примечание: поле называется batch_id (без подчёркивания), а не _batch_id
|
||||
SELECT
|
||||
'airports' AS entity,
|
||||
(SELECT COUNT(*) FROM stg.airports
|
||||
WHERE batch_id = (SELECT MAX(batch_id) FROM stg.airports)) AS stg_cnt,
|
||||
WHERE _load_id = (SELECT MAX(_load_id) FROM stg.airports)) AS stg_cnt,
|
||||
(SELECT COUNT(*) FROM ods.airports) AS ods_cnt
|
||||
UNION ALL SELECT 'airplanes',
|
||||
(SELECT COUNT(*) FROM stg.airplanes
|
||||
WHERE batch_id = (SELECT MAX(batch_id) FROM stg.airplanes)),
|
||||
WHERE _load_id = (SELECT MAX(_load_id) FROM stg.airplanes)),
|
||||
(SELECT COUNT(*) FROM ods.airplanes)
|
||||
UNION ALL SELECT 'routes',
|
||||
(SELECT COUNT(*) FROM stg.routes
|
||||
WHERE batch_id = (SELECT MAX(batch_id) FROM stg.routes)),
|
||||
WHERE _load_id = (SELECT MAX(_load_id) FROM stg.routes)),
|
||||
(SELECT COUNT(*) FROM ods.routes)
|
||||
UNION ALL SELECT 'seats',
|
||||
(SELECT COUNT(*) FROM stg.seats
|
||||
WHERE batch_id = (SELECT MAX(batch_id) FROM stg.seats)),
|
||||
WHERE _load_id = (SELECT MAX(_load_id) FROM stg.seats)),
|
||||
(SELECT COUNT(*) FROM ods.seats);
|
||||
```
|
||||
|
||||
@@ -281,7 +280,7 @@ WHERE f.calendar_sk IS NOT NULL AND c.calendar_sk IS NULL;
|
||||
```sql
|
||||
SELECT COUNT(*) AS unprocessed
|
||||
FROM stg.bookings
|
||||
WHERE load_dttm > (SELECT COALESCE(MAX(_load_ts), '1900-01-01') FROM ods.bookings);
|
||||
WHERE _load_ts > (SELECT COALESCE(MAX(_load_ts), '1900-01-01') FROM ods.bookings);
|
||||
-- Ожидание: 0
|
||||
```
|
||||
|
||||
@@ -352,10 +351,10 @@ ORDER BY 1;
|
||||
#### B. STG хранит оба батча
|
||||
|
||||
```sql
|
||||
SELECT _batch_id, COUNT(*) FROM stg.bookings GROUP BY 1 ORDER BY 1;
|
||||
SELECT _load_id, COUNT(*) FROM stg.bookings GROUP BY 1 ORDER BY 1;
|
||||
```
|
||||
|
||||
**Ожидание:** 2 разных `_batch_id`, оба с данными.
|
||||
**Ожидание:** 2 разных `_load_id`, оба с данными.
|
||||
|
||||
#### C. Снапшоты не дублировались
|
||||
|
||||
@@ -363,19 +362,19 @@ SELECT _batch_id, COUNT(*) FROM stg.bookings GROUP BY 1 ORDER BY 1;
|
||||
SELECT
|
||||
'airports' AS entity,
|
||||
(SELECT COUNT(*) FROM stg.airports
|
||||
WHERE _batch_id = (SELECT MAX(_batch_id) FROM stg.airports)) AS stg_last_batch,
|
||||
WHERE _load_id = (SELECT MAX(_load_id) FROM stg.airports)) AS stg_last_batch,
|
||||
(SELECT COUNT(*) FROM ods.airports) AS ods_cnt
|
||||
UNION ALL SELECT 'airplanes',
|
||||
(SELECT COUNT(*) FROM stg.airplanes
|
||||
WHERE _batch_id = (SELECT MAX(_batch_id) FROM stg.airplanes)),
|
||||
WHERE _load_id = (SELECT MAX(_load_id) FROM stg.airplanes)),
|
||||
(SELECT COUNT(*) FROM ods.airplanes)
|
||||
UNION ALL SELECT 'routes',
|
||||
(SELECT COUNT(*) FROM stg.routes
|
||||
WHERE _batch_id = (SELECT MAX(_batch_id) FROM stg.routes)),
|
||||
WHERE _load_id = (SELECT MAX(_load_id) FROM stg.routes)),
|
||||
(SELECT COUNT(*) FROM ods.routes)
|
||||
UNION ALL SELECT 'seats',
|
||||
(SELECT COUNT(*) FROM stg.seats
|
||||
WHERE _batch_id = (SELECT MAX(_batch_id) FROM stg.seats)),
|
||||
WHERE _load_id = (SELECT MAX(_load_id) FROM stg.seats)),
|
||||
(SELECT COUNT(*) FROM ods.seats);
|
||||
```
|
||||
|
||||
@@ -431,7 +430,7 @@ make bookings-generate-day
|
||||
#### A. Монотонный рост инкрементальных таблиц
|
||||
|
||||
```sql
|
||||
SELECT _batch_id, COUNT(*) FROM stg.bookings GROUP BY 1 ORDER BY 1;
|
||||
SELECT _load_id, COUNT(*) FROM stg.bookings GROUP BY 1 ORDER BY 1;
|
||||
```
|
||||
|
||||
**Ожидание:** 5 строк, все с данными.
|
||||
@@ -483,25 +482,21 @@ SELECT
|
||||
**Цель:** проверить качество кода без запуска стенда. Можно делать параллельно
|
||||
с блоками 1-4.
|
||||
|
||||
### 5.1 Консистентность _load_id / _batch_id
|
||||
### 5.1 Консистентность _load_id во всех слоях
|
||||
|
||||
```bash
|
||||
# В STG должен быть _batch_id (через {{ run_id }})
|
||||
grep -r '_batch_id' sql/stg/*_load.sql | head -20
|
||||
# В STG/ODS/DDS/DM должен быть _load_id
|
||||
grep -r '_load_id' sql/stg/*_load.sql sql/ods/*_load.sql sql/dds/*_load.sql sql/dm/*_load.sql | head -20
|
||||
|
||||
# В ODS/DDS/DM должен быть _load_id (через {{ run_id }})
|
||||
grep -r '_load_id' sql/ods/*_load.sql sql/dds/*_load.sql sql/dm/*_load.sql | head -20
|
||||
|
||||
# НЕ должно быть: _load_id в STG или _batch_id в ODS/DDS/DM (кроме чтения из STG)
|
||||
grep -r '_load_id' sql/stg/*_load.sql # ожидание: пусто
|
||||
grep -r '_batch_id' sql/ods/*_load.sql # допустимо: чтение из stg
|
||||
grep -r '_batch_id' sql/dds/*_load.sql sql/dm/*_load.sql # ожидание: пусто
|
||||
# Не должно быть старых имён batch_id, load_dttm, src_created_at_ts
|
||||
grep -r '\bbatch_id\b' sql/stg/ sql/ods/ sql/dds/ sql/dm/ # ожидание: только допустимые переменные PL (v_batch_id)
|
||||
grep -r 'load_dttm\|src_created_at_ts' sql/ # ожидание: пусто
|
||||
```
|
||||
|
||||
### 5.2 Все load.sql используют шаблон {{ run_id }}
|
||||
|
||||
Примечание: ODS намеренно не использует `{{ run_id }}` — вместо этого в `_load_id`
|
||||
сохраняется `batch_id` из STG для сквозного lineage (traceable to source batch).
|
||||
сохраняется `_load_id` из STG для сквозного lineage (traceable to source batch).
|
||||
Это правильный паттерн, а не баг. Проверять нужно только STG/DDS/DM.
|
||||
|
||||
```bash
|
||||
|
||||
@@ -0,0 +1,118 @@
|
||||
# Унификация нейминга служебных полей в STG
|
||||
|
||||
## Контекст
|
||||
|
||||
В STG-слое используются legacy-имена служебных полей (`batch_id`, `load_dttm`, `src_created_at_ts`), а начиная с ODS — каноничные (`_load_id`, `_load_ts`, `event_ts`). Студент видит разные имена для одного понятия. Цель — привести STG к канону, убрав расхождение.
|
||||
|
||||
> **Breaking change (dev-only).** Это ломающее переименование колонок. Миграционный шаг (ALTER TABLE … RENAME COLUMN) не предусмотрен. DDL-файлы используют `CREATE TABLE IF NOT EXISTS`, поэтому сами по себе они не пересоздадут существующие таблицы с новыми именами колонок. План предполагает заранее пересозданную среду (например, `make down && make up`) или ручной `DROP TABLE` / `DROP SCHEMA` перед `make ddl-gp`. Обратная совместимость не обеспечивается.
|
||||
|
||||
## Маппинг
|
||||
|
||||
| Legacy (STG сейчас) | Канон (ODS/DDS/DM) |
|
||||
|---|---|
|
||||
| `batch_id` | `_load_id` |
|
||||
| `load_dttm` | `_load_ts` |
|
||||
| `src_created_at_ts` | `event_ts` |
|
||||
|
||||
### Оговорка про `event_ts` в snapshot-справочниках
|
||||
|
||||
В транзакционных STG-таблицах (bookings, tickets, flights, segments, boarding_passes) поле `src_created_at_ts` действительно хранит время события из источника — переименование в `event_ts` семантически точно.
|
||||
|
||||
В snapshot-справочниках (airports, airplanes, routes, seats) это поле заполняется `now()` при загрузке, т.е. по факту это ещё одно load-time, а не время события. Тем не менее мы сохраняем единое имя `event_ts` как **учебное упрощение** — ради консистентной структуры STG-таблиц. Это зафиксировано как осознанный trade-off: единообразие важнее семантической точности в справочниках. В `naming_conventions.md` нужно добавить соответствующую оговорку (раздел 4, «Time Rule»).
|
||||
|
||||
## Что НЕ переименовываем
|
||||
|
||||
- PL/pgSQL переменная `v_batch_id` — это локальная переменная, не колонка
|
||||
- Python-функция `_resolve_stg_batch_id`, переменная `stg_batch_id`, task_id `resolve_stg_batch_id` — это Python/Airflow-идентификаторы
|
||||
- XCom-ключи, ссылающиеся на task_id
|
||||
|
||||
## Порядок выполнения
|
||||
|
||||
### Шаг 1: STG DDL (9 файлов)
|
||||
|
||||
`sql/stg/{bookings,tickets,flights,segments,airports,airplanes,routes,seats,boarding_passes}_ddl.sql`
|
||||
|
||||
В каждом: `batch_id` → `_load_id`, `load_dttm` → `_load_ts`, `src_created_at_ts` → `event_ts`.
|
||||
|
||||
### Шаг 2: STG Load (9 файлов)
|
||||
|
||||
`sql/stg/{bookings,tickets,flights,segments,airports,airplanes,routes,seats,boarding_passes}_load.sql`
|
||||
|
||||
INSERT-списки, SELECT, WHERE, комментарии — те же 3 замены.
|
||||
|
||||
### Шаг 3: STG DQ (9 файлов)
|
||||
|
||||
`sql/stg/{bookings,tickets,flights,segments,airports,airplanes,routes,seats,boarding_passes}_dq.sql`
|
||||
|
||||
WHERE-условия (`batch_id = v_batch_id` → `_load_id = v_batch_id`), RAISE-сообщения, комментарии.
|
||||
|
||||
### Шаг 4: ODS Load (9 файлов)
|
||||
|
||||
Два подтипа — обрабатывать по-разному.
|
||||
|
||||
#### 4a: Транзакционные таблицы (5 файлов)
|
||||
|
||||
`sql/ods/{bookings,tickets,flights,segments,boarding_passes}_load.sql`
|
||||
|
||||
SELECT из STG: `s.batch_id` → `s._load_id`, `s.load_dttm` → `s._load_ts`, `s.src_created_at_ts` → `s.event_ts`. Убрать лишние алиасы (`s.src_created_at_ts AS event_ts` → просто `s.event_ts`).
|
||||
|
||||
#### 4b: Snapshot-справочники (4 файла)
|
||||
|
||||
`sql/ods/{airports,airplanes,routes,seats}_load.sql`
|
||||
|
||||
Здесь `event_ts` отсутствует в целевой ODS-таблице — менять только ссылки на STG-колонки: `s.batch_id` → `s._load_id`, `s.load_dttm` → `s._load_ts`, `s.src_created_at_ts` → `s.event_ts` (только в ORDER BY / WHERE, где они читают из STG). ODS-колонка `_load_ts` по-прежнему заполняется через `now()`, это не меняется.
|
||||
|
||||
### Шаг 5: ODS DQ (9 файлов)
|
||||
|
||||
`sql/ods/{bookings,tickets,flights,segments,airports,airplanes,routes,seats,boarding_passes}_dq.sql`
|
||||
|
||||
`WHERE batch_id =` → `WHERE _load_id =`, RAISE-сообщения.
|
||||
|
||||
### Шаг 6: DAG-файлы (2 файла)
|
||||
|
||||
- `airflow/dags/bookings_to_gp_stage.py` — комментарий про `batch_id`
|
||||
- `airflow/dags/bookings_to_gp_ods.py` — встроенный SQL-запрос резолвера: все `batch_id` как колонка → `_load_id`, `load_dttm` → `_load_ts`. Python-имена не трогаем.
|
||||
|
||||
### Шаг 7: Тесты (3 файла)
|
||||
|
||||
- `tests/test_ods_snapshot_integration.py` — inline DDL и INSERT в тестах
|
||||
- `tests/test_dags_smoke.py` — комментарии
|
||||
- `tests/test_ods_sql_contract.py` — docstring
|
||||
|
||||
### Шаг 8: Документация (~15 файлов)
|
||||
|
||||
- `docs/internal/naming_conventions.md` — убрать legacy-исключение (секция 5/STG), убрать переходный маппинг (секция 6), добавить оговорку про `event_ts` в snapshot-справочниках (секция 4)
|
||||
- `docs/internal/db_schema.md` — описания STG-полей
|
||||
- `docs/internal/bookings_stg_design.md` — дизайн STG
|
||||
- `docs/internal/bookings_ods_design.md` — маппинг STG→ODS, SQL-примеры
|
||||
- `docs/internal/qa-plan.md` — SQL-запросы проверок
|
||||
- `docs/internal/architecture_review.md` — архитектурные заметки
|
||||
- `docs/internal/bookings_stg_code_review.md` — код-ревью
|
||||
- `docs/bookings_to_gp_stage.md` — описание STG DAG, примеры полей
|
||||
- `docs/bookings_to_gp_ods.md` — описание ODS DAG
|
||||
- `docs/dag_execution_order.md` — порядок выполнения DAG
|
||||
- `educational-tasks.md` — учебные задания
|
||||
- `README.md` — SQL-примеры в README
|
||||
- `TESTING.md` — чек-лист тестирования
|
||||
|
||||
### Шаг 9: Верификация
|
||||
|
||||
```bash
|
||||
# 1. Проверить SQL и Python — не должно быть колонок batch_id
|
||||
# (допустимы только: v_batch_id, stg_batch_id, resolve_stg_batch_id)
|
||||
grep -rn 'batch_id' sql/stg/ sql/ods/ airflow/dags/ tests/ --include='*.sql' --include='*.py'
|
||||
|
||||
# 2. Ноль совпадений по старым именам в коде
|
||||
grep -rn 'load_dttm' sql/ airflow/dags/ tests/ --include='*.sql' --include='*.py'
|
||||
grep -rn 'src_created_at_ts' sql/ airflow/dags/ tests/ --include='*.sql' --include='*.py'
|
||||
|
||||
# 3. Проверить документацию — не должно быть старых имён как актуальных
|
||||
# (допустимы упоминания в историческом контексте)
|
||||
grep -rn 'batch_id\|load_dttm\|src_created_at_ts' docs/ educational-tasks.md README.md TESTING.md
|
||||
|
||||
# 4. Тесты и линтер
|
||||
make test
|
||||
make fmt && make lint
|
||||
```
|
||||
|
||||
## Итого: ~55 файлов, ~3 механические замены в каждом
|
||||
Reference in New Issue
Block a user