airflow-greenplum/docs/design/labs_development.md

# Развитие лабораторных работ

Рабочая заметка для автора программы, 22 сентября 2026 года.
Документ хранится в ветке `solution`; оценка программы и ссылки
на действующие задания и код относятся к учебной ветке `main`.
Приоритет — закрыть пробелы обязательного цикла. Принятое решение о новой
лабораторной записано отдельно от предложений, которые еще обсуждаются.
Действующий маршрут и требования находятся в [учебных заданиях](https://git.dementev.space/ddmitry/airflow-greenplum/src/branch/main/docs/assignment/README.md)
и [ТЗ](https://git.dementev.space/ddmitry/airflow-greenplum/src/branch/main/docs/assignment/analyst_spec.md).

## Аудитория и цель

Студент хорошо изучил PostgreSQL и прошел 16-часовой курс Greenplum от Яндекса.
Теперь ему нужна практика применения этих знаний в работе Data Engineer.
Стенд служит учебным пособием, похожим на небольшое хранилище компании:
здесь есть источники, связанные слои данных, загрузки и потребители.

Программа должна дать опыт подключения источника, построения загрузок
и моделей, оркестрации, проверки результата и восстановления после ошибок.
Знакомые SQL-инструменты студент применяет к инженерным задачам и объясняет
свои решения на данных. Разнообразие работ определяется новыми действиями
и решениями; дополнительная витрина полезна, если она дает такой опыт.

Подготовка по Airflow пока не задана. Первые необходимые действия в UI
нужно сопровождать короткой инструкцией или ссылкой на нее. Самостоятельное
написание задач и зависимостей вводится явно в соответствующей работе.

## Метод и рост самостоятельности

Стенд учебный: его можно ломать и восстанавливать. Готовая реализация
позволяет сначала увидеть работающую цепочку, а затем самостоятельно
реализовать выбранный участок. Полнота эталона при первом запуске
не ограничивает состав лабораторных.

Этот прием уже используется в
[программе Clickstream](https://git.dementev.space/ddmitry/clickstream-data-platform/src/branch/main/docs/specs/2026-09-01-labs-program.md):
при «вычитании» студент удаляет готовую реализацию и пишет свою;
при работе «собери рядом» сравнивает свою реализацию с работающей;
при расследовании находит и устраняет причину подготовленной ошибки.
Можно также расширять стенд новым источником или объектом по ТЗ.

Границу самостоятельной работы определяет навык: в задании по SQL можно
оставить готовый DAG, а в задании по оркестрации — готовые SQL-скрипты.
Вычитание дает способ выделить участок для работы; самостоятельность
обеспечивают решения, которые студент принимает и проверяет:

1. В первых работах даны требования к результату, близкий пример и готовая
   проверка. Студент выбирает реализацию и испытывает ее на заданных случаях.
2. Дальше студент обосновывает способ загрузки или устройство таблицы,
   пишет собственные проверки и показывает, какие ошибки они обнаруживают.
3. В работах на диагностику даны симптом и критерий восстановления.
   Студент сам находит причину, выбирает исправление и подтверждает результат.

Так помощь постепенно сокращается, а ответственность растет.
Заранее оставлять заглушки во всех учебных участках не требуется.
В частности, зависимость ODS от общего STG-батча объясняет
[готовый STG в текущей программе](https://git.dementev.space/ddmitry/airflow-greenplum/src/branch/main/docs/assignment/analyst_spec.md#почему-stg-слой-уже-реализован),
но позволяет временно разобрать его в отдельной работе.

## Принято: прием справочника входит в обязательную программу

Добавить лабораторную **«Восстановите прием справочника из источника»**.
Она закрывает практику подключения через PXF и загрузки полного снимка
в STG, которые сейчас даны готовыми.

Предлагаемый объем: восстановить внешнюю таблицу для существующего
справочника Postgres, написать его загрузку в STG и проверить передачу
полей, ключей и меток батча. Студент должен различить повтор загрузки
в том же батче и получение нового снимка. Результат должен снова
участвовать в действующей цепочке ODS → DDS → DM.

Конкретный справочник, состав удаляемых файлов, место в маршруте и проверки
еще предстоит выбрать. Кандидат — `airports`: рядом есть
[внешняя и внутренняя таблицы](https://git.dementev.space/ddmitry/airflow-greenplum/src/branch/main/sql/stg/airports_ddl.sql),
[загрузка снимка](https://git.dementev.space/ddmitry/airflow-greenplum/src/branch/main/sql/stg/airports_load.sql) и
[преобразование в ODS](https://git.dementev.space/ddmitry/airflow-greenplum/src/branch/main/sql/ods/airports_load.sql).

## Покрытие обязательного цикла

Оценка основана на текущем ТЗ и коде. Наличие готового примера или главы
для чтения учитывается отдельно от самостоятельной реализации.

| Участок | Что студент делает сейчас | Что стоит добавить |
|---|---|---|
| PXF и снимок STG | Запускает готовую цепочку | Принятая лабораторная по приему справочника |
| Инкремент STG | Использует готовый отбор по дате источника | Самостоятельную загрузку новых данных и проверку границы отбора |
| Снимки ODS | Реализует `airplanes`, `seats` и их DQ | Сохранить задания; использовать их после знакомства с приемом данных |
| Инкремент ODS | Использует готовые загрузки | Обработку новых ключей и изменений уже полученных строк |
| Измерения DDS | Реализует SCD1 и SCD2 | Сохранить существующий блок |
| Факт DDS | Читает пример и запускает готовую сборку | Самостоятельную сборку факта с ключами измерений |
| Витрины DM | Реализует четыре витрины с разными способами пересчета | Сохранить существующий блок; сначала закрыть пробелы ниже DM |
| DDL и физическая организация | Получает готовые таблицы, типы и ключи распределения | Написать DDL одного объекта и проверить выбор распределения опытом; предложение раскрыто ниже |
| Airflow | Запускает готовые DAG; задачи уже подключены к SQL | Самостоятельное включение загрузок и проверок в DAG |
| DQ и повторяемость | Пишет `*_dq.sql`; для ODS проверяет повтор; пользуется `bookings_validate` | Обязательные опыты на обнаружение ошибки, идемпотентность и восстановление после сбоя |

## Предложения по оставшимся пробелам

Следующие изменения пока не утверждены как обязательные лабораторные.

1. **Загрузите новые и измененные данные: STG → ODS.** Кандидат —
   `bookings`: [прием в STG](https://git.dementev.space/ddmitry/airflow-greenplum/src/branch/main/sql/stg/bookings_load.sql) и
   [обновление ODS](https://git.dementev.space/ddmitry/airflow-greenplum/src/branch/main/sql/ods/bookings_load.sql). Проверить первую
   загрузку, следующую пачку, повтор и отсутствие новых данных.
   Для изменения существующего ключа подготовить новую версию в STG:
   текущий отбор источника по `book_date` сам по себе не подхватывает
   исправления старых бронирований. Различие времени события и времени
   загрузки — часть учебного результата. Разделение на две работы зависит
   от объема самостоятельного SQL.
2. **Соберите факт продаж.** После измерений восстановить
   [загрузку факта](https://git.dementev.space/ddmitry/airflow-greenplum/src/branch/main/sql/dds/fact_flight_sales_load.sql): сохранить
   зерно `(ticket_no, flight_id)`, подобрать ключи измерений и версию
   маршрута на дату рейса, обработать обновления и повторный запуск.
   Проверить покрытие ключей, значения и отсутствие размножения строк.
   Простого совпадения количества строк недостаточно.
3. **Организуйте загрузку в Airflow и восстановите ее после сбоя.**
   Использовать уже написанный SQL, самостоятельно связать задачи загрузки
   и DQ. На подготовленном входе вызвать сбой, определить состояние данных
   и завершить обработку повторным запуском. Генератор управляется отдельно:
   его повтор продвигает источник на новый день и меняет условия опыта.
4. **Проверьте физическую организацию таблицы в Greenplum.** Предлагается
   включить в обязательный цикл компактный опыт: написать DDL, сравнить
   два варианта распределения одних данных, посмотреть строки по сегментам
   и планы одного запроса, обосновать выбор. Результат запроса должен
   совпадать в обоих вариантах. Наличие нескольких сегментов и достаточный
   для наблюдения объем нужно проверить при подготовке работы. Место опыта
   еще не выбрано; кандидат — задание по факту. Подробную оптимизацию
   можно развить в факультативах.

## Предлагаемые переходы между работами

Порядок обсуждения новых работ: прием справочника → инкремент STG/ODS →
сборка факта → оркестрация и восстановление. Между ними остаются
существующие задания на снимки ODS, измерения и витрины. Точное место
новых работ, включая опыт с распределением, еще обсуждается.

Для встраивания в маршрут предлагаются следующие границы:

| Новая работа | Состояние перед началом | Результат для продолжения |
|---|---|---|
| Прием справочника | Пройден быстрый старт, работает эталонная цепочка до `sales_report`; выбран участок для вычитания | Собственная загрузка получает новый снимок STG, который участвует в общем батче справочников и принимается ODS |
| Инкремент STG/ODS | Разобраны прием снимка и существующие задания ODS; подготовлены таблицы и входные пачки | Собственные загрузки дают ожидаемое текущее состояние ODS после всех проверочных случаев |
| Сборка факта | Реализованы и проверены измерения DDS | Факт построен собственным SQL, проверены ключи и значения; на нем можно выполнять задания DM |
| Оркестрация и восстановление | SQL выбранного участка реализован и проверен | DAG выполняет загрузку и DQ в нужном порядке; после подготовленного сбоя обработка завершается с ожидаемыми данными |

Готовность оценивается по нужному этапу: на исходной `main` часть таблиц
еще является заданием, поэтому проход всех проверок будущих слоев
не может быть условием начала первой работы. Действующие особенности
запусков и состояния слоев описаны в [порядке выполнения DAG](https://git.dementev.space/ddmitry/airflow-greenplum/src/branch/main/docs/dag_execution_order.md).

Предложения основаны на чтении исходников; воспроизводимость новых
сценариев на стенде еще не проверялась.

## Как подготовить лабораторную

Эти критерии общие для обязательных работ и факультативов. Перед написанием
инструкции определите:

- **Навык:** рабочая ситуация, новое действие или решение DE и его отличие
  от уже пройденных работ.
- **Вход:** необходимые задания, состояние таблиц и загрузок, подготовка
  данных и способ воспроизвести ситуацию.
- **Самостоятельная часть:** что студент получает готовым, что пишет
  или меняет сам и какие решения должен обосновать.
- **Результат:** что будет работать после задания и по каким наблюдениям
  студент сможет это подтвердить.
- **Проверочные случаи:** конкретные данные или события, ожидаемый результат
  каждого случая и способ обнаружить неверное решение.
- **Выход:** что сохраняется для следующей работы и как получить нужное
  состояние стенда после опыта или перерыва.

Для инкремента получение новых строк из источника и применение уже
полученных изменений в ODS проверяются отдельно. Для собственной DQ-проверки
нужны отказ на известной ошибке и успех после исправления. Сверка с готовой
реализацией подтверждает совпадение поведения; проверки по источнику
подтверждают полноту и бизнес-правила.

Полная пересборка стенда допустима. Адресное восстановление требуется там,
где оно само является предметом работы. При пересборке инструкция должна
объяснять, как снова применить сохраненные файлы решения и получить
состояние для продолжения.

Лабораторная готова к выдаче, когда все ее проверочные случаи пройдены
на стенде из описанного начального состояния, проверки обнаружили
предусмотренные ошибки, а заявленный выход позволяет продолжить маршрут.
Команды и результаты проверки сохраняются вместе с изменением задания.
Текстовая вычитка и проверка ссылок подтверждают только качество документа.

## Основа для будущих факультативов

Факультативы расширяют опыт за пределами обязательного набора. При генерации
кандидатов используйте общие критерии выше и указывайте, после каких
обязательных работ доступен каждый сюжет.

Направления для последующей генерации: изменения схемы источника,
опоздавшие данные, история и пересчеты, углубленная оптимизация запросов
Greenplum, свежесть данных, разграничение доступа, новые способы приема.
Это исходные темы для отбора, а не утвержденный список заданий.