# Развитие лабораторных работ Рабочая заметка для автора программы, 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. В [#9](https://git.dementev.space/ddmitry/airflow-greenplum/issues/9) выбран `airports`; место — после быстрого старта и знакомства с моделью, перед снимками ODS. Студент восстанавливает внешний DDL и загрузку, сохраняя готовыми внутреннюю таблицу, JDBC-конфигурацию, DQ и DAG. Перед реализацией очищает старые снимки только `stg.airports`. Опыты с повторным выполнением, изменением источника и восстановлением описаны в [инструкции main](https://git.dementev.space/ddmitry/airflow-greenplum/src/branch/main/docs/assignment/pxf_airports.md); обоснование и эталон — в [материалах автора](pxf_airports_lab.md). ## Покрытие обязательного цикла Оценка основана на текущем ТЗ и коде. Наличие готового примера или главы для чтения учитывается отдельно от самостоятельной реализации. | Участок | Что студент делает сейчас | Что стоит добавить | |---|---|---| | PXF и снимок STG | Восстанавливает прием `airports`, испытывает повтор, изменение источника и передачу в ODS | Закрыто лабораторной #9 | | Инкремент 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` | Собственная загрузка проверена; источник восстановлен, новый общий снимок принят ODS и готов для заданий `airplanes` и `seats` | | Инкремент 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). Оставшиеся предложения основаны на чтении исходников; их воспроизводимость на стенде еще не проверялась. Состояние проверки приема `airports` зафиксировано отдельно в [материалах #9](pxf_airports_lab.md#проверочный-прогон). ## Как подготовить лабораторную Эти критерии общие для обязательных работ и факультативов. Перед написанием инструкции определите: - **Навык:** рабочая ситуация, новое действие или решение DE и его отличие от уже пройденных работ. - **Вход:** необходимые задания, состояние таблиц и загрузок, подготовка данных и способ воспроизвести ситуацию. - **Самостоятельная часть:** что студент получает готовым, что пишет или меняет сам и какие решения должен обосновать. - **Результат:** что будет работать после задания и по каким наблюдениям студент сможет это подтвердить. - **Проверочные случаи:** конкретные данные или события, ожидаемый результат каждого случая и способ обнаружить неверное решение. - **Выход:** что сохраняется для следующей работы и как получить нужное состояние стенда после опыта или перерыва. Для инкремента получение новых строк из источника и применение уже полученных изменений в ODS проверяются отдельно. Для собственной DQ-проверки нужны отказ на известной ошибке и успех после исправления. Сверка с готовой реализацией подтверждает совпадение поведения; проверки по источнику подтверждают полноту и бизнес-правила. Полная пересборка стенда допустима. Адресное восстановление требуется там, где оно само является предметом работы. При пересборке инструкция должна объяснять, как снова применить сохраненные файлы решения и получить состояние для продолжения. Лабораторная готова к выдаче, когда все ее проверочные случаи пройдены на стенде из описанного начального состояния, проверки обнаружили предусмотренные ошибки, а заявленный выход позволяет продолжить маршрут. Команды и результаты проверки сохраняются вместе с изменением задания. Текстовая вычитка и проверка ссылок подтверждают только качество документа. ## Основа для будущих факультативов Факультативы расширяют опыт за пределами обязательного набора. При генерации кандидатов используйте общие критерии выше и указывайте, после каких обязательных работ доступен каждый сюжет. Направления для последующей генерации: изменения схемы источника, опоздавшие данные, история и пересчеты, углубленная оптимизация запросов Greenplum, свежесть данных, разграничение доступа, новые способы приема. Это исходные темы для отбора, а не утвержденный список заданий.