- Зачем:
- 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 стартовал без ошибок.
92 lines
7.4 KiB
Markdown
92 lines
7.4 KiB
Markdown
# Учебные задания по стенду
|
||
|
||
Этот документ собирает в одном месте задания для менти.
|
||
Он разбит на блоки: от архитектуры 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 → витрины.
|
||
|
||
Когда будете готовы к этим темам, вернитесь к этому разделу — он станет основой для следующего «модуля» лабораторных заданий.
|