airflow-greenplum/docs/design/labs_development.md

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

Рабочая заметка для автора программы, 22 сентября 2026 года. Документ хранится в ветке solution; оценка программы и ссылки на действующие задания и код относятся к учебной ветке main. Приоритет — закрыть пробелы обязательного цикла. Принятое решение о новой лабораторной записано отдельно от предложений, которые еще обсуждаются. Действующий маршрут и требования находятся в учебных заданиях и ТЗ.

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

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

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

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

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

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

Этот прием уже используется в программе Clickstream: при «вычитании» студент удаляет готовую реализацию и пишет свою; при работе «собери рядом» сравнивает свою реализацию с работающей; при расследовании находит и устраняет причину подготовленной ошибки. Можно также расширять стенд новым источником или объектом по ТЗ.

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

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

Так помощь постепенно сокращается, а ответственность растет. Заранее оставлять заглушки во всех учебных участках не требуется. В частности, зависимость ODS от общего STG-батча объясняет готовый STG в текущей программе, но позволяет временно разобрать его в отдельной работе.

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

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

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

Конкретный справочник, состав удаляемых файлов, место в маршруте и проверки еще предстоит выбрать. Кандидат — airports: рядом есть внешняя и внутренняя таблицы, загрузка снимка и преобразование в ODS.

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

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

Участок	Что студент делает сейчас	Что стоит добавить
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 и обновление ODS. Проверить первую загрузку, следующую пачку, повтор и отсутствие новых данных. Для изменения существующего ключа подготовить новую версию в STG: текущий отбор источника по book_date сам по себе не подхватывает исправления старых бронирований. Различие времени события и времени загрузки — часть учебного результата. Разделение на две работы зависит от объема самостоятельного SQL.
2. Соберите факт продаж. После измерений восстановить загрузку факта: сохранить зерно (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.

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

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

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

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

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

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

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

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

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

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