Files
airflow-greenplum/educational-tasks.md
T
ddadmin 5972bcc2d8 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 стартовал без ошибок.
2026-03-10 00:07:08 +03:00

7.4 KiB
Raw Blame History

Учебные задания по стенду

Этот документ собирает в одном месте задания для менти.
Он разбит на блоки: от архитектуры Greenplum и демо‑БД bookings до реализации аналитических слоев DWH.

Если вы только начинаете, выполняйте задания по порядку.


1. Greenplum и модель данных (введение)

В следующих заданиях мы будем опираться на демо‑БД bookings (Postgres) и слой STG в Greenplum.
На этом этапе достаточно бегло посмотреть на структуру и понять общую идею, детальная проработка пойдёт позже.

1.1. Знакомство с демо‑БД bookings

  1. Прочитайте bookings/README.md — какие сервисы и команды относятся к демобазе.
  2. Поднимите стенд и выполните:
    • make up
    • make bookings-init
  3. Подключитесь к демобазе:
    • make bookings-psql
    • посмотрите таблицы в схеме bookings (например, \dt bookings.*).
  4. Найдите таблицу bookings.bookings и посмотрите на её структуру:
    • какие типы колонок используются;
    • какие поля выглядят как ключи, даты, суммы.

1.2. Знакомство с STG в Greenplum

  1. Прочитайте sql/stg/bookings_ddl.sql и краткое описание потока docs/bookings_to_gp_stage.md (если интересно — docs/internal/bookings_stg_design.md).
  2. Ответьте себе на вопросы:
    • чем внешняя таблица stg.bookings_ext отличается от внутренней stg.bookings;
    • зачем нужны тех.колонки event_ts, _load_ts, _load_id;
    • чем слой STG отличается от итоговых витрин (DDS/DM) с точки зрения моделирования.
  3. Выполните make ddl-gp, затем зайдите в Greenplum (make gp-psql) и проверьте наличие схемы и таблиц:
    • \dn и \dt stg.*
    • SELECT * FROM stg.bookings LIMIT 5; (после запуска соответствующего DAG).

1.3. Как генерируются учебные данные bookings

  1. Откройте файл bookings/generate_next_day.sql и ответьте себе на вопросы:
    • с какой даты начинается генерация данных (посмотрите на GUC bookings.start_date и переменную v_start_cfg);
    • сколько дней генерируется при первой установке (переменная bookings.init_days);
    • что происходит, если таблица bookings.bookings уже не пустая.
  2. В демобазе (make bookings-psql) выполните:
    • SELECT min(book_date), max(book_date) FROM bookings.bookings;
    • затем запустите make bookings-generate-day и повторите запрос — как изменился максимальный день?
  3. Откройте sql/src/bookings_generate_day_if_missing.sql и обратите внимание, что:
    • логическая дата запуска DAG ({{ ds }}) не влияет на выбор дня генерации;
    • скрипт всегда смотрит на max(book_date) и добавляет следующий день (или несколько стартовых дней, если база пуста).
  4. Сделайте вывод: генератор всегда «шагает» по датам вперёд от максимальной даты, поэтому:
    • при make bookings-init вы получаете готовые данные из seed-дампа (при make bookings-generate генератор создаст BOOKINGS_INIT_DAYS дней начиная с BOOKINGS_START_DATE);
    • при последующих вызовах (make bookings-generate-day или DAG) добавляется ровно один новый день.

2. DAG bookings_to_gp_stage (заготовка заданий)

Этот DAG показывает путь данных от демо‑БД bookings в Postgres до сырого слоя STG в Greenplum.
Сейчас он уже реализован как учебный пример, а в будущем вокруг него появятся отдельные задания по моделированию DWH.

2.1. Что есть сейчас

  1. Откройте airflow/dags/bookings_to_gp_stage.py.
  2. Найдите в коде ссылки на SQL‑файлы:
    • sql/src/bookings_generate_day_if_missing.sql
    • sql/stg/bookings_load.sql
    • sql/stg/bookings_dq.sql
  3. Соотнесите шаги DAG с документом docs/bookings_to_gp_stage.md:
    • генерация учебного дня в bookings.bookings;
    • загрузка инкремента в stg.bookings;
    • проверка количества строк между источником и STG.
  4. Обратите внимание, как в DAG используется логическая дата запуска:
    • {{ run_id }} используется как _load_id — метка загрузки в таблице stg.bookings для конкретного запуска;
    • сами даты данных (какие дни есть в bookings.bookings) определяются генератором по max(book_date), а не по ds.

На этом этапе достаточно понять общую цепочку. Детальные задания по переработке модели данных и построению ODS/DDS/DM слоёв будут добавлены позже.

2.2. Идеи для будущих заданий (черновик)

Ниже — набросок задач, к которым мы вернёмся, когда базовые темы по Airflow будут освоены.

Планируемые направления:

  • Спроектировать модель данных для основных сущностей демобазы bookings (рейсы, билеты, перелёты) в слоях ODS/DDS/DM.
  • Реализовать слой ODS поверх STG, аккуратно работая с временными атрибутами и ключами.
  • Построить витрины (DM) для типичных аналитических вопросов: загрузка рейсов, выручка по направлениям, динамика бронирований.
  • Добавить DAG’и, которые используют stg.bookings как источник и строят следующие слои DWH.
  • Расширить проверки качества данных для потоков bookings → STG → витрины.

Когда будете готовы к этим темам, вернитесь к этому разделу — он станет основой для следующего «модуля» лабораторных заданий.