- Зачем:
- 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 стартовал без ошибок.
7.4 KiB
Учебные задания по стенду
Этот документ собирает в одном месте задания для менти.
Он разбит на блоки: от архитектуры Greenplum и демо‑БД bookings до реализации аналитических слоев DWH.
Если вы только начинаете, выполняйте задания по порядку.
1. Greenplum и модель данных (введение)
В следующих заданиях мы будем опираться на демо‑БД bookings (Postgres) и слой STG в Greenplum.
На этом этапе достаточно бегло посмотреть на структуру и понять общую идею, детальная проработка пойдёт позже.
1.1. Знакомство с демо‑БД bookings
- Прочитайте
bookings/README.md— какие сервисы и команды относятся к демобазе. - Поднимите стенд и выполните:
make upmake bookings-init
- Подключитесь к демобазе:
make bookings-psql- посмотрите таблицы в схеме
bookings(например,\dt bookings.*).
- Найдите таблицу
bookings.bookingsи посмотрите на её структуру:- какие типы колонок используются;
- какие поля выглядят как ключи, даты, суммы.
1.2. Знакомство с STG в Greenplum
- Прочитайте
sql/stg/bookings_ddl.sqlи краткое описание потокаdocs/bookings_to_gp_stage.md(если интересно —docs/internal/bookings_stg_design.md). - Ответьте себе на вопросы:
- чем внешняя таблица
stg.bookings_extотличается от внутреннейstg.bookings; - зачем нужны тех.колонки
event_ts,_load_ts,_load_id; - чем слой STG отличается от итоговых витрин (DDS/DM) с точки зрения моделирования.
- чем внешняя таблица
- Выполните
make ddl-gp, затем зайдите в Greenplum (make gp-psql) и проверьте наличие схемы и таблиц:\dnи\dt stg.*SELECT * FROM stg.bookings LIMIT 5;(после запуска соответствующего DAG).
1.3. Как генерируются учебные данные bookings
- Откройте файл
bookings/generate_next_day.sqlи ответьте себе на вопросы:- с какой даты начинается генерация данных (посмотрите на GUC
bookings.start_dateи переменнуюv_start_cfg); - сколько дней генерируется при первой установке (переменная
bookings.init_days); - что происходит, если таблица
bookings.bookingsуже не пустая.
- с какой даты начинается генерация данных (посмотрите на GUC
- В демобазе (
make bookings-psql) выполните:SELECT min(book_date), max(book_date) FROM bookings.bookings;- затем запустите
make bookings-generate-dayи повторите запрос — как изменился максимальный день?
- Откройте
sql/src/bookings_generate_day_if_missing.sqlи обратите внимание, что:- логическая дата запуска DAG (
{{ ds }}) не влияет на выбор дня генерации; - скрипт всегда смотрит на
max(book_date)и добавляет следующий день (или несколько стартовых дней, если база пуста).
- логическая дата запуска DAG (
- Сделайте вывод: генератор всегда «шагает» по датам вперёд от максимальной даты, поэтому:
- при
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. Что есть сейчас
- Откройте
airflow/dags/bookings_to_gp_stage.py. - Найдите в коде ссылки на SQL‑файлы:
sql/src/bookings_generate_day_if_missing.sqlsql/stg/bookings_load.sqlsql/stg/bookings_dq.sql
- Соотнесите шаги DAG с документом
docs/bookings_to_gp_stage.md:- генерация учебного дня в
bookings.bookings; - загрузка инкремента в
stg.bookings; - проверка количества строк между источником и STG.
- генерация учебного дня в
- Обратите внимание, как в 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 → витрины.
Когда будете готовы к этим темам, вернитесь к этому разделу — он станет основой для следующего «модуля» лабораторных заданий.