- Зачем:
- генерация с нуля занимала часы, boarding_passes были пустыми, данные
пропадали после docker compose down/up.
- Что:
- обновлён demodb до коммита 866e56f, добавлен патч install_connstr_no_hardcode.
- BOOKINGS_INIT_DAYS увеличен до 60, BOOKINGS_JOBS по умолчанию 2.
- добавлен seed-дамп bookings/seed/demo.sql.xz (42 MB, xz вместо 7z).
- make bookings-init восстанавливает из дампа (~18 сек) и применяет GUC из .env.
- make bookings-generate — генерация с нуля для разработчиков.
- generate_next_day.sql: COMMIT после continue(), pg_sleep(3) для jobs>1, synchronous_commit=on + CHECKPOINT.
- bookings-check-jobs: добавлена валидация нечисловых значений BOOKINGS_JOBS.
- bookings-init теперь вызывает bookings-check-jobs как prerequisite.
- синхронизированы внутренние документы (коммит demodb, init_days=60).
- Проверка:
- make bookings-init && make bookings-generate-day BOOKINGS_JOBS=2.
- make test.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
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; - зачем нужны тех.колонки
src_created_at_ts,load_dttm,batch_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 }}используется какbatch_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 → витрины.
Когда будете готовы к этим темам, вернитесь к этому разделу — он станет основой для следующего «модуля» лабораторных заданий.