- Зачем:
- улучшение производительности аналитических запросов и упрощение витрин согласно принципам Kimball Star Schema.
- Что:
- в dds.dim_routes добавлены денормализованные поля городов и моделей самолетов.
- в скрипт загрузки dim_routes_load.sql добавлена фаза refresh для актуализации атрибутов.
- загрузка dm.route_performance упрощена до 1 JOIN к измерению маршрутов.
- обновлен DAG bookings_to_gp_dds и smoke-тесты структуры графа.
- в документации (db_schema.md) отражены денормализация и lineage версий.
- в dim_routes_load.sql исправлено затирание _load_id при refresh исторических версий.
- Проверка:
- make test (smoke-тесты структуры DAG проходят успешно).
- Зачем:
- предоставить студентам полный набор аналитических витрин с примерами различных паттернов (UPSERT, Full Rebuild, UNION ALL, двухуровневая агрегация).
- Что:
- реализованы витрины: sales_report, route_performance, passenger_loyalty, airport_traffic, monthly_overview.
- исправлен баг в route_performance_load.sql: добавлены JOIN к dim_airports и dim_airplanes для корректной денормализации атрибутов.
- обновлен скрипт e2e_etl.sh: добавлена верификация всех 5 витрин и проверка бизнес-логики (load factor).
- обновлены DAGи, тесты и главный DDL скрипт.
- Проверка:
- автоматизированный прогон e2e_etl.sh через REST API Airflow.
- Зачем:
- необходимо продемонстрировать студентам работу с одной сущностью в разных ролях (вылет/прилет) через UNION ALL.
- Что:
- созданы DDL, Load и DQ скрипты для витрины dm.airport_traffic (пассажиропоток аэропортов).
- реализован паттерн Unpivot через UNION ALL для консолидации метрик вылета и прилета в одном разрезе.
- внедрена инкрементальная загрузка по затронутым датам (HWM) с честным подсчетом рейсов через COUNT(DISTINCT).
- добавлены подробные комментарии к колонкам выручки, предупреждающие о риске двойного счета.
- обновлены DAGи bookings_dm_ddl и bookings_to_gp_dm для включения витрины в общий пайплайн.
- Проверка:
- визуальный аудит SQL-кода на предмет использования airport_bk и корректной агрегации по ролям.
- наличие DQ-инварианта total_passengers = departures + arrivals.
- верификация блока UPDATE: теперь обновляются и денормализованные атрибуты (city, airport_bk).
- Зачем:
- необходимо продемонстрировать студентам метод инкрементального пересчета "затронутых ключей" для больших справочных витрин.
- Что:
- созданы DDL, Load и DQ скрипты для витрины dm.passenger_loyalty (лояльность пассажиров).
- реализован расчет моды (самый частый тариф) через PostgreSQL-специфику DISTINCT ON.
- внедрена корректная агрегация SCD2-измерений (unique_routes) по бизнес-ключу route_bk.
- настроено Heap-хранилище (WITH appendonly=false) для эффективного выполнения UPSERT.
- обновлены DAGи bookings_dm_ddl и bookings_to_gp_dm для включения новой витрины в конвейер.
- Проверка:
- визуальный аудит SQL на предмет использования p.passenger_id (BK) и r.route_bk.
- наличие учебной DQ-проверки ссылочной целостности и инварианта дат (first <= last).
- проверка параллельности задач в Airflow DAG.
- Зачем:
- необходимо продемонстрировать студентам альтернативный паттерн загрузки (Full Rebuild) и использование AO Column Store в Greenplum.
- Что:
- созданы DDL, Load и DQ скрипты для витрины dm.route_performance (эффективность маршрутов).
- реализована агрегация по бизнес-ключу route_bk для корректной обработки SCD2-измерений.
- настроен формат хранения AO Column Store с компрессией zstd (уровень 1).
- обновлены DAGи bookings_dm_ddl и bookings_to_gp_dm для параллельной оркестрации новой витрины.
- Проверка:
- визуальный аудит SQL-кода на соответствие naming_conventions.md.
- проверка структуры DAG в Airflow (параллельные ветки load -> dq).
- наличие бизнес-инварианта total_boarded <= total_tickets в DQ-скрипте.
- Зачем:
- необходимо визуализировать выбор типа хранения (Heap vs Append-Only) для учебных целей.
- автоматизировать проверку всей цепочки DWH для исключения ручных ошибок.
- сделать процесс отладки прозрачным и наглядным через стандартные инструменты Airflow.
- Что:
- внедрена клауза WITH (appendonly=...) во все DDL; ODS-справочники переведены на AO Row и TRUNCATE+INSERT.
- создан скрипт scripts/e2e_etl.sh для полного прогона ETL (DDL + 2 дня данных) через REST API.
- исправлены баги типизации (INTEGER[]), именования полей (amount, passenger_id) и удалены фантомные колонки (contact_data).
- обновлен e2e-etl-test-protocol.md: добавлен раздел по отладке, чтению логов и перезапуску задач через API.
- исправлены pytest-контракты под новую логику загрузки.
- Проверка:
- успешный прогон `make e2e-smoke` (полный цикл от очистки до витрины).
- Зачем:
- zstd (level 1) является современным стандартом для Greenplum 6.0+, обеспечивая более высокую скорость декомпрессии и лучшее сжатие.
- Что:
- обновлены все DDL стейджинга (STG) и базовых таблиц.
- обновлена архитектурная документация (ADR-3) и планы реализации.
- исправлены примеры кода в Airflow DAG и описании ETL.
- Проверка:
- успешное выполнение CREATE TABLE с новыми параметрами в Greenplum 6.27.1.
- Зачем:
- формализация проверки всей цепочки ETL (STG -> ODS -> DDS -> DM).
- Что:
- создан docs/e2e-etl-test-protocol.md и sql/truncate_gp.sql.
- в Makefile добавлена команда dwh-truncate.
- start_date во всех DAG изменен на 2017-01-01.
- Проверка:
- выполнение make dwh-truncate и прогон DAG.
- Зачем:
- исправление критических ошибок P0 (гонка HWM, ошибки в SQL CTE, непоследовательный lineage).
- использование временных таблиц делает код более читаемым для студентов и производительным для Greenplum.
- Что:
- в sql/ods/ (bookings, tickets, segments, boarding_passes, flights) выборка дельты вынесена в CREATE TEMP TABLE.
- HWM теперь вычисляется один раз, устраняя гонку между UPDATE и INSERT.
- во всех стейтментах используется оригинальный batch_id из STG для _load_id.
- поле _load_ts в ODS теперь берется из STG (load_dttm), что делает HWM-сравнение корректным.
- Проверка:
- визуальный аудит SQL-логики.
- Зачем:
- текущая реализация ODS batch_id теряла данные транзакционных таблиц, если между запусками ODS STG успевал отработать дважды (брался только последний батч).
- Что:
- изменены скрипты загрузки транзакционных таблиц (bookings, tickets, flights, segments, boarding_passes) для использования паттерна HWM по _load_ts вместо фильтрации по конкретному батчу.
- обновлен комментарий в DAG bookings_to_gp_ods, объясняющий разное поведение для справочников и транзакционных данных.
- сохранено использование оригинального batch_id из STG для поля _load_id в слое ODS для сквозного трассирования.
- Проверка:
- запуск пайплайнов и проверка, что все батчи загружаются из STG в ODS без потерь.
- Зачем:
- закрыты задачи P0 и P1 из ревью архитектуры для повышения понятности стенда для студентов.
- Что:
- исправлен distribution key для airport_traffic в дизайн-документе.
- добавлены комментарии о генерации SK и отсутствии SK в фактах.
- создан документ docs/dag_execution_order.md с описанием порядка запуска DAG-ов.
- объяснена логика late-arriving dimensions и batch resolver.
- добавлена legacy-пометка для хелпера greenplum.py.
- Проверка:
- визуальная проверка добавленных комментариев и новых файлов.
- Зачем:
- фильтр `_load_id = '{{ run_id }}'` использовал run_id DM-DAG-а, который не совпадает с run_id DDS-DAG-а, записанным в факты — витрина не находила дельту.
- Что:
- load: заменён _load_id-фильтр на HWM-подзапрос `_load_ts > MAX(_load_ts)` из dm.sales_report.
- dq: источник затронутых дат переключён с DDS на саму витрину (где _load_id уже корректный).
- Проверка:
- `make test` — smoke-тесты зелёные.
- запуск `bookings_to_gp_dm` в Airflow после загрузки DDS.
- Зачем:
- жесткая привязка инкремента к логической дате Airflow ({{ ds }}) приводила к пустой витрине при обработке исторических и "опоздавших" (late-arriving) данных.
- Что:
- изменена фильтрация в скрипте загрузки витрины: теперь динамически определяются даты, затронутые текущим батчем (через _load_id).
- обновлены DQ-проверки для валидации только тех дат, которые были изменены в рамках запущенного батча.
- в дизайн-документ добавлено описание паттерна работы с late-arriving facts для студентов.
- Проверка:
- запуск пайплайна "с нуля" за логическую дату 2024-01-01 приводит к корректному расчету агрегатов для исторических данных 2017 года (>8000 строк).
- Зачем:
- источник хранит мультиязычные названия как JSON ({"en": "...", "ru": "..."}),
- для упрощения downstream-логики (DDS/DM) нужны чистые строки на одном языке.
- Что:
- добавлен парсинг JSON с извлечением поля 'ru' в sql/ods/airports_load.sql
(airport_name, city, country).
- добавлен парсинг JSON с извлечением поля 'ru' в sql/ods/airplanes_load.sql
(model).
- обновлена документация docs/internal/bookings_ods_design.md с примечаниями
о нормализации.
- обновлены тестовые данные в tests/test_ods_snapshot_integration.py для
соответствия JSON-формату STG.
- Проверка:
- uv run make test (15 passed).
- SELECT airport_name FROM ods.airports → "Аль-Баха" (вместо JSON).
- Зачем:
- dq_ods_segments падал на непустых батчах из-за orphan flight_id в ods.segments.
- Что:
- доработан sql/ods/flights_load.sql: добавлено добирание рейсов из истории stg.flights для flight_id из stg.segments текущего batch.
- добавлен контрактный тест в tests/test_ods_sql_contract.py на покрытие flight_id из segments.
- обновлена документация DAG в docs/bookings_to_gp_ods.md.
- Проверка:
- make test.
- airflow dags trigger bookings_to_gp_ods -c '{"stg_batch_id":"manual__2026-01-18T18:47:18.316091+00:00"}'.
- Зачем:
- подготовлен учебный Star Schema слой для перехода от ODS к аналитике и витринам.
- Что:
- добавлены 21 SQL-файл для DDS (DDL/LOAD/DQ) с SCD1/SCD2 и фактом `fact_flight_sales`.
- добавлены DAG `bookings_dds_ddl` и `bookings_to_gp_dds`, а также smoke-тесты структуры DAG.
- обновлены `sql/ddl_gp.sql` и документация (`README`, `docs/*`, `db_schema`) под поток `stg -> ods -> dds`.
- Проверка:
- make test.
- Зачем:
- подготовлена учебная реализация ODS слоя с типизацией, UPSERT и DQ, чтобы продолжить работу от STG к DDS/DM.
- Что:
- добавлены SQL-скрипты `sql/ods/*_ddl.sql`, `sql/ods/*_load.sql`, `sql/ods/*_dq.sql` для 9 сущностей bookings.
- добавлены DAG `bookings_ods_ddl` и `bookings_to_gp_ods`, а также smoke-тесты для новых графов.
- ODS DDL интегрирован в `sql/ddl_gp.sql`; документация и план обновлены под единый запуск через `make ddl-gp`.
- Проверка:
- `make test`.
- `make ddl-gp`.
- Зачем:
- исключить нестабильные режимы генератора, в которых bookings может перестать пополняться.
- сделать причину ошибки понятной студенту сразу при запуске команд и SQL-скриптов.
- Что:
- добавлен precheck `bookings-check-jobs` в Makefile и подключён к `bookings-init` и `bookings-generate-day`.
- добавлены явные проверки `bookings.jobs = 1` в `bookings/generate_next_day.sql` и `sql/src/bookings_generate_day_if_missing.sql`.
- обновлена документация и `.env.example`: зафиксировано, что в стенде поддерживается только `BOOKINGS_JOBS=1`.
- Проверка:
- uv run make fmt.
- uv run make test.
- env BOOKINGS_JOBS=2 make bookings-init.
- env BOOKINGS_JOBS=2 make bookings-generate-day.
- make bookings-init.
- make bookings-generate-day.
ddadmin