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 стартовал без ошибок.

docs/internal/PRD.md

@@ -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)
 
 ---

docs/internal/architecture_review.md

@@ -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-файла |

docs/internal/bookings_ods_design.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

docs/internal/bookings_stg_code_review.md

@@ -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-тест реального графа (минимальный полезный уровень)

docs/internal/bookings_stg_design.md

@@ -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`

docs/internal/db_schema.md

@@ -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 обязательных полей, ссылочная целостность
 

docs/internal/naming_conventions.md

@@ -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` в одном смысле.

docs/internal/qa-plan.md

@@ -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

docs/internal/stg_naming_unification_plan.md

@@ -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 механические замены в каждом