airflow-greenplum/docs/internal/assignment_design.md

Дизайн курсового задания

Тактические решения по нарезке задания, порядку выполнения и самопроверке. Стратегию и контекст см. в PRD.md.

---

1. Эталонный срез: витрина sales_report

Эталоном выбрана витрина dm.sales_report и вся её цепочка вниз по слоям.

Почему sales_report:

• Покрывает SCD1 (airports, tariffs), HWM-инкремент, fact load
• Богатая денормализация — хороший образец для подражания
• Средняя сложность — не пугает, но и не тривиальна

Эталонные таблицы (даны студенту)

Слой	Таблицы
DM	sales_report
DDS	fact_flight_sales, dim_airports (SCD1), dim_tariffs (SCD1), dim_calendar
ODS	bookings, tickets, segments, flights, boarding_passes, airports
STG	bookings, tickets, segments, flights, boarding_passes, airports

Задание студенту

Слой	Таблицы	Что нового для студента
STG	airplanes, seats, routes	Практика по аналогии с эталоном
ODS	airplanes, seats, routes	Практика SCD1 UPSERT по аналогии
DDS	dim_airplanes (SCD1), dim_passengers (SCD1), dim_routes (SCD2)	SCD2 — ключевой вызов курсовой
DM	airport_traffic, monthly_overview, route_performance, passenger_loyalty	Разная сложность (от простой к сложной)

---

2. Рекомендуемый порядок выполнения

Студенту рекомендуется (но не обязательно) двигаться в таком порядке:

1. STG (airplanes, seats, routes) — разминка, по аналогии
2. ODS (airplanes, seats, routes) — закрепление UPSERT
3. DDS dim_airplanes, dim_passengers (SCD1) — новые измерения
4. DDS dim_routes (SCD2) — ключевой вызов
5. DM airport_traffic — простая витрина, похожа на sales_report
6. DM route_performance — TRUNCATE+INSERT, SCD2-агрегация по BK
7. DM monthly_overview — двухуровневая агрегация
8. DM passenger_loyalty — самая сложная, пересчёт истории

Порядок выстроен от простого к сложному. Каждый шаг опирается на опыт предыдущего.

---

3. SCD2: подход «рецепт без готового SQL»

Реализация dim_routes (SCD2) — ключевой вызов курсовой. Студент делает это самостоятельно, но ТЗ содержит пошаговую подсказку:

1. Алгоритм SCD2 текстом (без SQL):
   • Вычисли hashdiff по набору атрибутов (атрибуты перечислены в ТЗ)
   • Найди строки, у которых hashdiff изменился
   • Закрой старую версию (valid_to = текущая_дата)
   • Вставь новую версию (valid_from = текущая_дата, valid_to = NULL)
2. Формула hashdiff: md5(concat_ws('|', field1, field2, ...))
3. Ссылка на naming_conventions.md (поля valid_from, valid_to, hashdiff)
4. Напоминание: полуоткрытый интервал [valid_from, valid_to)
5. Если застрял — ветка solution

Самостоятельная реализация — ключ к запоминанию. SCD2 — обязательный вопрос на собеседованиях DE, и студент должен уметь объяснить его на основе собственного опыта.

---

4. Валидационный DAG (bookings_validate)

Отдельный DAG для самопроверки студента. Запускается вручную в Airflow UI после реализации заданий. Таски сгруппированы по слоям — студент видит, где именно проблема. Дополнительный бонус — практика чтения логов Airflow.

Примерная структура тасков

bookings_validate
├── validate_stg
│   ├── check_stg_airplanes_exists      (таблица создана, >0 строк)
│   ├── check_stg_seats_exists
│   └── check_stg_routes_exists
├── validate_ods
│   ├── check_ods_airplanes_rowcount    (ODS >= STG по кол-ву уникальных BK)
│   ├── check_ods_seats_rowcount
│   ├── check_ods_routes_rowcount
│   └── check_ods_no_null_pks           (PK not null)
├── validate_dds
│   ├── check_dim_airplanes_exists
│   ├── check_dim_passengers_exists
│   ├── check_dim_routes_scd2           (valid_from/valid_to корректны)
│   └── check_dim_routes_no_gaps        (нет «дыр» в версиях SCD2)
└── validate_dm
    ├── check_airport_traffic_exists
    ├── check_monthly_overview_exists
    ├── check_route_performance_exists
    └── check_passenger_loyalty_exists

Реализация

• PostgresOperator + SQL-скрипты в sql/validate/
• Каждый SQL-скрипт выполняет SELECT и бросает исключение (через DO $$ ... RAISE EXCEPTION ... $$), если проверка не пройдена
• Сообщения об ошибках — дружелюбные, с подсказкой что делать дальше

Ключевые проверки

• Таблицы существуют и содержат данные
• PK не содержат NULL
• SCD2: valid_to IS NULL для текущих версий, нет перекрытий интервалов
• Кросс-слойная консистентность (row count ODS vs STG)
• DM-витрины содержат данные за загруженные дни

---

5. Формат ТЗ от аналитика

Файл: docs/assignment/analyst_spec.md (или несколько файлов по слоям).

Для каждой таблицы-задания документ содержит:

• Имя таблицы и целевая схема (stg / ods / dds / dm)
• Описание — что хранит таблица, бизнес-смысл
• Список полей с типами и описанием
• Маппинг источников — откуда берётся каждое поле
• Бизнес-правила и фильтры (если есть)
• Тип историзации (SCD1 / SCD2 / snapshot / append)
• Гранулярность (одна строка = ?)
• Distribution key (подсказка или задание на выбор)

Формат — приближен к реальным ТЗ, которые студент встретит на работе.