airflow-greenplum/docs/bookings_to_gp_dm.md

Загрузка DDS → DM: bookings_to_gp_dm

DAG собирает витрины из факта и измерений DDS. На main полностью работает dm.sales_report; остальные четыре загрузки и их DQ содержат SELECT 1;. Успешный запуск с заглушками не означает, что все витрины наполнены.

На карте sales_report можно проследить источники полей. Как сегменты билетов превращаются в строки витрины, объясняет руководство о структуре. Карту открывайте локально.

Перед запуском

Дождитесь успешного bookings_to_gp_dds. Создайте таблицы через bookings_dm_ddl, если еще не запускали его или общий make ddl-gp. Затем запустите bookings_to_gp_dm в Airflow UI. Общий порядок находится в инструкции запуска DAG.

Для готовой sales_report достаточно готового факта, календаря, аэропортов и тарифов. Для своих витрин сначала заполните нужные измерения и выполните пересчет факта после заданий DDS.

Что делает sales_report

Зерно витрины: (flight_date, departure_airport_sk, arrival_airport_sk, tariff_sk). Одна строка содержит продажи сегментов за дату вылета, пару аэропортов и тариф. tickets_sold = COUNT(*) считает строки факта в этой группе.

sales_report_load.sql работает в три шага:

1. Находит даты вылета фактов с _load_ts > MAX(_load_ts) витрины. Для пустой витрины нижняя граница равна 1900-01-01.
2. Для этих дат пересчитывает агрегаты по всем их фактам во временную таблицу. В расчет входят и строки, загруженные ранее: например, новая посадка меняет итог дня, сохраняя остальные продажи этого дня.
3. Обновляет существующие группы при изменении проверяемых полей и вставляет новые. _load_id записанных строк равен текущему run_id DM.

Если после пропуска запуска в DDS накопились факты с более новой _load_ts, следующий запуск включит их даты в пересчет. Изменение только описания измерения само по себе не выбирает дату: отбор привязан к метке факта.

sales_report_dq.sql берет даты из строк витрины, записанных текущим запуском. Для них проверяет непустоту при наличии фактов, дубли ключа, обязательные поля, неотрицательную выручку и долю посадок от 0 до 1. Если витрина в этом запуске не менялась, DQ выводит NOTICE и завершает работу.

Учебные витрины

Ниже указано ожидаемое поведение заданий. Поля и формулы находятся в ТЗ; загрузку и DQ для каждого объекта нужно написать самостоятельно.

Задание	Одна строка	Что нужно пересчитывать
airport_traffic	Дата и аэропорт	Полные итоги затронутых дат, с учетом ролей вылета и прилета
route_performance	Маршрут по route_bk	Всю историю при каждом запуске, объединяя версии маршрута
monthly_overview	Год, месяц и модель по airplane_sk	Затронутые месяцы; сначала метрики рейса, затем месяца
passenger_loyalty	Пассажир по passenger_sk	Всю историю пассажиров, чьи факты изменились

Готовый пример отбора затронутых дат находится в sales_report_load.sql. В заданиях меняется единица пересчета: дата, месяц, пассажир или вся таблица. Следуйте порядку заданий, чтобы каждый следующий расчет опирался на уже освоенный прием.

Порядок задач

В DAG start_dm запускает пять независимых веток. Каждая имеет вид load_dm_<витрина> → dq_dm_<витрина> → finish_dm_summary. Финальная задача ждет все пять DQ. Витрины читают DDS и не читают друг друга, поэтому между их задачами загрузки нет зависимостей.

Проверка результата

В make gp-psql посмотрите готовую витрину:

SELECT COUNT(*) FROM dm.sales_report;

SELECT flight_date, departure_airport_bk, arrival_airport_bk,
       fare_conditions, tickets_sold, passengers_boarded, total_revenue
FROM dm.sales_report
ORDER BY flight_date DESC, departure_airport_bk, arrival_airport_bk,
         fare_conditions
LIMIT 10;

SELECT COUNT(*) AS invalid_boarding_rows
FROM dm.sales_report
WHERE tickets_sold < passengers_boarded;

После первого успешного запуска sales_report непуста, invalid_boarding_rows = 0. Возьмите одну строку и найдите на карте, откуда пришли ее дата, два аэропорта и тариф.

После реализации своих витрин запустите bookings_validate и посмотрите validate_dm. Проверки этой группы требуют непустые таблицы; правильность метрик должна проверять ваша DQ по ТЗ. Соблюдайте правила запуска валидации: в том же DAG выполняется активный SCD2-тест с восстановлением данных.

Если загрузка не прошла

• Нет dm.*: выполните bookings_dm_ddl.
• sales_report пуста: проверьте наличие факта и соответствий его SK календарю, аэропортам и тарифам. Витрина соединяет их через INNER JOIN.
• Учебная витрина пуста: проверьте замену загрузочной заглушки и наличие необходимых SK факта после заданий DDS.
• Ошибка метрики: разберите одну группу и сравните результат со строками факта и формулой в ТЗ. Дополнительные примеры проверок есть в справочнике DQ.
• finish_dm_summary не выполняется: найдите первую упавшую задачу, откройте ее Log и исправьте причину до следующего запуска слоя.