Files
airflow-greenplum/docs/dag_execution_order.md
ddadmin 6655326caa docs(all): реструктурирована документация — docs/internal/ заменён на design/, reference/, archive/, plans/
- Зачем:
  - docs/internal/ превратился в свалку: дизайн-документы, ревью, планы и справочники лежали вперемешку.
  - архивные планы были неотличимы от живых документов.
- Что:
  - docs/internal/ удалён; файлы распределены по docs/design/, docs/reference/, docs/archive/, docs/plans/, docs/assignment/.
  - educational-tasks.md убран из корня в архив (устарел).
  - обновлены все перекрёстные ссылки в AGENTS.md, TODO.md, README.md, docs/README.md и внутри design/reference/.
  - актуализированы architecture_review.md (статус DM-слоя), db_schema.md (DM-слой), TESTING.md, dag_execution_order.md, pxf_bookings.md.
  - добавлены заглушки docs/assignment/README.md и docs/plans/README.md.
- Проверка:
  - make test && make lint
  - rg 'docs/internal' --glob '!docs/archive/*' — должно быть пусто.
2026-03-10 23:02:41 +03:00

2.9 KiB
Raw Permalink Blame History

Порядок запуска DAG (Cross-DAG Dependencies)

В этом стенде пайплайны разделены на несколько DAG-ов по слоям DWH (STG, ODS, DDS, DM). Они настроены с schedule=None, так как это учебный проект.

Чтобы данные корректно прошли от источника до витрин, запускать DAG-и нужно в определённом порядке.

1. DDL-скрипты (выполняются один раз)

Для создания структуры таблиц в аналитических слоях:

  1. Запустите bookings_stg_ddl — создаст STG-таблицы и внешние *_ext через PXF.
  2. Запустите bookings_ods_ddl — создаст таблицы ODS (типизированные, SCD1).
  3. Запустите bookings_dds_ddl — создаст таблицы для измерений и фактов в слое DDS.
  4. Запустите bookings_dm_ddl — создаст таблицы витрин в слое DM.

(Технический шорткат: make ddl-gp применяет DDL для всех 4 слоёв сразу).

2. Ежедневная загрузка (ETL)

Для прогрузки новой порции данных (или полного перерасчёта) соблюдайте следующую цепочку:

  1. bookings_to_gp_stage
    • Извлекает новые данные из демо-БД PostgreSQL и сохраняет их в stg-схему в Greenplum.
    • Генерирует stg_batch_id для текущей загрузки.
  2. bookings_to_gp_ods
    • Берёт последний согласованный stg_batch_id из STG-слоя.
    • Выполняет нормализацию и SCD1-UPSERT в слой ODS.
  3. bookings_to_gp_dds
    • Читает очищенные данные из ODS.
    • Обновляет измерения (SCD1, SCD2) и инкрементально догружает новые рейсы в таблицу фактов dds.fact_flight_sales.
  4. bookings_to_gp_dm
    • Читает новые факты из DDS.
    • Обновляет агрегированные витрины (использует HWM-инкрементальность по _load_ts или полный перерасчёт).

💡 Архитектурная заметка: В реальном production-окружении (Airflow) эти связи между DAG-ами обычно настраиваются автоматически через TriggerDagRunOperator, ExternalTaskSensor или механизмы Data-Aware Scheduling (Datasets/Data Assets). В учебных целях мы оставили их ручными, чтобы вы могли проинспектировать каждый слой после его загрузки.