Files
ddadminandClaude Opus 4.6 af27314878 docs(main): онбординг студента — гид, маркетинг, адаптация docs и docstrings
- Зачем:
  - на 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>
2026-03-14 10:49:40 +03:00

4.8 KiB
Raw Permalink Blame History

Учебные задания

О чём задание

В стенде уже работает эталонный вертикальный срез — полная цепочка 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.

Там описаны все таблицы, которые нужно реализовать, с маппингами, бизнес-правилами и подсказками. Рекомендуемый порядок (от простого к сложному):

  1. ODS: airplanes, seats
  2. DDS: dim_airplanes, dim_passengers (SCD1)
  3. DDS: dim_routes (SCD2 — ключевой вызов курсовой)
  4. 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).