- Зачем:
- необходимо продемонстрировать студентам работу с одной сущностью в разных ролях (вылет/прилет) через 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` (полный цикл от очистки до витрины).
- Зачем:
- фильтр `_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 строк).
ddadmin