- Зачем:
- на main docs и DAG-docstrings утверждали «все реализовано», хотя 18 заглушек;
студент застревал после шага 6 без явного «что дальше».
- Что:
- README: маркетинг-баннер, шаг 6 (только эталонные таблицы), шаг 7 → задания.
- docs/assignment/README: полный гид студента (эталон → ТЗ → заглушки → validate).
- analyst_spec: DAG-интеграция — «таски уже подключены, менять DAG не нужно».
- docs ODS/DDS/DM: пометки заглушек, адаптация секций проверки результата.
- 4 DAG docstrings: эталон vs задания (заглушки).
- Проверка:
- make test (4 passed, 14 skipped), make lint (clean).
- grep «все 5 витрин|все реализован» — ложных утверждений без оговорок нет.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
4.8 KiB
Учебные задания
О чём задание
В стенде уже работает эталонный вертикальный срез — полная цепочка
STG → ODS → DDS → DM для витрины dm.sales_report. Ваша задача —
реализовать недостающие загрузки по аналогии с эталоном.
На месте ваших заданий сейчас стоят заглушки (SELECT 1;). Вы замените
их на реальную SQL-логику, и после этого весь DWH будет заполнен.
Перед началом
Убедитесь, что стенд запущен и данные загружены — пройдите шаги 1–6 из README (Быстрый старт).
После этого в Greenplum будут данные в эталонных таблицах (stg.*, ods.bookings,
dds.dim_airports, dds.fact_flight_sales, dm.sales_report и др.).
Шаг 1. Изучите эталон
Прежде чем писать код, разберите, как устроены эталонные загрузки. По одному файлу на каждый ключевой паттерн:
| Паттерн | Файл для изучения | Что посмотреть |
|---|---|---|
| ODS: TRUNCATE + INSERT (snapshot-справочник) | sql/ods/airports_load.sql |
Фильтрация по stg_batch_id, дедупликация через ROW_NUMBER() |
| DDS: SCD1 UPSERT (измерение) | sql/dds/dim_airports_load.sql |
TEMP TABLE → UPDATE (IS DISTINCT FROM) → INSERT |
| DM: витрина с UPSERT | sql/dm/sales_report_load.sql |
HWM-инкремент, агрегация фактов по измерениям |
Описания каждого DAG — в docs/:
STG ·
ODS ·
DDS ·
DM
Шаг 2. Откройте ТЗ
Техническое задание от аналитика: analyst_spec.md.
Там описаны все таблицы, которые нужно реализовать, с маппингами, бизнес-правилами и подсказками. Рекомендуемый порядок (от простого к сложному):
- ODS:
airplanes,seats - DDS:
dim_airplanes,dim_passengers(SCD1) - DDS:
dim_routes(SCD2 — ключевой вызов курсовой) - DM:
airport_traffic,route_performance,monthly_overview,passenger_loyalty
Шаг 3. Реализуйте задания
- Файлы-заглушки уже на месте — например,
sql/ods/airplanes_load.sqlсодержитSELECT 1;. Ваша задача: заменитьSELECT 1;на реальную SQL-логику. - DDL уже создан — таблицы существуют, создавать их не нужно.
- Таски в DAG-ах уже подключены —
PostgresOperatorссылается на ваши SQL-файлы. Менять Python-код DAG-ов не нужно. - Нейминг полей: сверяйтесь с
docs/design/naming_conventions.md.
Шаг 4. Проверьте себя валидационным DAG-ом
DAG bookings_validate — автоматическая проверка вашей реализации.
- Три группы проверок:
validate_ods,validate_dds,validate_dm— запускаются параллельно. Можно проверять ODS, пока DDS ещё не готов. - Включает активный SCD2-тест для
dim_routes: загружает изменённые данные и проверяет, что версионирование работает корректно. - Сообщения об ошибках подскажут, что именно не так и что делать дальше.
Цель: все проверки зелёные.
Если застряли
- Изучите эталонные SQL-скрипты — в них те же паттерны, что нужны для заданий.
- Загляните в
docs/design/naming_conventions.md— единый источник нейминга полей. - Сверьтесь с веткой
solution— там полная рабочая реализация.
Для менторов
Дизайн заданий и педагогическая логика — в ветке solution
(docs/design/assignment_design.md).