ddmitry/airflow-greenplum
1
0 Fork 0
Code Issues 6 Pull Requests Actions Packages Projects Releases Wiki Activity

Лабораторная: реализовать инкрементальную загрузку источника в STG #10

New Issue
Open
opened 2026-09-22 16:35:47 +03:00 by ddmitry · 0 comments
ddmitry commented 2026-09-22 16:35:47 +03:00
Owner
Copy link
Copy source

Part of #8

Статус и учебный результат

Кандидат на расширение обязательного цикла; перед реализацией оценить объем и место в маршруте.

Студент пишет прием новых строк Postgres в STG и доказывает, какие строки относятся к текущей загрузке. Он различает границу отбора по времени события и идентификатор батча, проверяет повтор задачи и понимает ограничение приема по дате создания записи.

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

Ученик уже разобрал PXF и полный снимок. Кандидат — bookings. Внешняя таблица, целевой DDL и DAG могут быть даны готовыми; самостоятельная часть — отбор окна, запись сырья с техническими полями и проверка полноты. Обработка STG → ODS вынесена в отдельную работу.

Что предусмотреть

  1. Подготовить воспроизводимые состояния источника и STG. Отделить продвижение генератора от повторного запуска загрузки: полный STG-DAG создает следующий учебный день.
  2. Задать последовательность: A — первоначальная загрузка; повтор A; B — следующая пачка новых строк; повтор B; C — новый батч без новых строк источника. A, B и C имеют разные _load_id; каждый повтор использует идентификатор своего батча. Внутри пары загрузка/повтор источник и остальные STG-батчи неизменны.
  3. Для каждого шага задать нижнюю границу по MAX(event_ts) остальных батчей, включая начальное значение для пустого STG. Отбор использует строгое book_date > граница. Сверить ключи и бизнес-поля окна, включая записи на границе; старые батчи сохраняются, повтор текущего не добавляет дублей, C пуст.
  4. Назвать ограничение исторического повтора: при возвращении к A после B граница пересчитывается уже с учетом B, поэтому прежнее окно не воспроизводится и DQ может завершиться ошибкой. Поддерживаемый здесь сценарий — последовательные батчи и непосредственный повтор текущего на фиксированном входе.
  5. Показать на конкретной старой записи, что изменение суммы без изменения book_date не попадает в текущий отбор. Ученик формулирует границы метода; автоматический захват всех исправлений и CDC не входят в эту работу.

Критерии этой лабораторной

  • Начальное состояние, граница окна и значения меток для каждого шага A → повтор A → B → повтор B → C заданы однозначно.
  • Последовательность выполнена с проверкой ключей и значений; повторы сохраняют результат, пустое окно C различается с ошибкой потери данных.
  • Студент объясняет ограничение повтора A после B и показывает старую строку, которую отбор по book_date не перечитает.
  • Результат готов к отдельной работе по применению дельты в ODS; указано, как сохранить или воспроизвести ее вход.

Границы и результат работы автора

Подготовить задание для студента, необходимые заготовки/проверки и проверенный способ выполнения. Назвать входное состояние, самостоятельную часть, проверочные случаи и состояние для продолжения. Готовый стенд должен запускаться до лабораторной; выбранную часть разбирает уже студент во время задания. Стенд можно ломать и пересобирать, сохраняя файлы решения и понятный способ продолжения.

Материалы для автора и полное решение относятся к solution; инструкция для студента и необходимые общие средства — к main. Переносить изменения выборочно с учетом различий веток. При размещении задания обновить его место во входе в задания и связанные ссылки; существующие задания ODS, измерений и DM сохраняются.

Общая проверка готовности

  • Из описанного начального состояния выполнены все случаи задания на стенде; сохранены команды и наблюдаемые результаты.
  • Неверное решение обнаруживается предусмотренными проверками; восстановление и повторный запуск проверены там, где они входят в задание.
  • Инструкция на русском соответствует подготовке учащегося, различает готовые части и самостоятельные решения; результат позволяет продолжить маршрут.
  • Проверены ссылки и команды; git diff --check пройден. Для изменений Python/DAG выполнены make lint и make test, а пропуски тестов перечислены отдельно. Статические проверки не заменяют учебный прогон.

Сначала прочитать

Part of #8 ## Статус и учебный результат Кандидат на расширение обязательного цикла; перед реализацией оценить объем и место в маршруте. Студент пишет прием новых строк Postgres в STG и доказывает, какие строки относятся к текущей загрузке. Он различает границу отбора по времени события и идентификатор батча, проверяет повтор задачи и понимает ограничение приема по дате создания записи. ## Место и самостоятельная часть Ученик уже разобрал PXF и полный снимок. Кандидат — `bookings`. Внешняя таблица, целевой DDL и DAG могут быть даны готовыми; самостоятельная часть — отбор окна, запись сырья с техническими полями и проверка полноты. Обработка STG → ODS вынесена в отдельную работу. ## Что предусмотреть 1. Подготовить воспроизводимые состояния источника и STG. Отделить продвижение генератора от повторного запуска загрузки: полный STG-DAG создает следующий учебный день. 2. Задать последовательность: A — первоначальная загрузка; повтор A; B — следующая пачка новых строк; повтор B; C — новый батч без новых строк источника. A, B и C имеют разные `_load_id`; каждый повтор использует идентификатор своего батча. Внутри пары загрузка/повтор источник и остальные STG-батчи неизменны. 3. Для каждого шага задать нижнюю границу по `MAX(event_ts)` остальных батчей, включая начальное значение для пустого STG. Отбор использует строгое `book_date > граница`. Сверить ключи и бизнес-поля окна, включая записи на границе; старые батчи сохраняются, повтор текущего не добавляет дублей, C пуст. 4. Назвать ограничение исторического повтора: при возвращении к A после B граница пересчитывается уже с учетом B, поэтому прежнее окно не воспроизводится и DQ может завершиться ошибкой. Поддерживаемый здесь сценарий — последовательные батчи и непосредственный повтор текущего на фиксированном входе. 5. Показать на конкретной старой записи, что изменение суммы без изменения `book_date` не попадает в текущий отбор. Ученик формулирует границы метода; автоматический захват всех исправлений и CDC не входят в эту работу. ## Критерии этой лабораторной - [ ] Начальное состояние, граница окна и значения меток для каждого шага A → повтор A → B → повтор B → C заданы однозначно. - [ ] Последовательность выполнена с проверкой ключей и значений; повторы сохраняют результат, пустое окно C различается с ошибкой потери данных. - [ ] Студент объясняет ограничение повтора A после B и показывает старую строку, которую отбор по `book_date` не перечитает. - [ ] Результат готов к отдельной работе по применению дельты в ODS; указано, как сохранить или воспроизвести ее вход. ## Границы и результат работы автора Подготовить задание для студента, необходимые заготовки/проверки и проверенный способ выполнения. Назвать входное состояние, самостоятельную часть, проверочные случаи и состояние для продолжения. Готовый стенд должен запускаться до лабораторной; выбранную часть разбирает уже студент во время задания. Стенд можно ломать и пересобирать, сохраняя файлы решения и понятный способ продолжения. Материалы для автора и полное решение относятся к `solution`; инструкция для студента и необходимые общие средства — к `main`. Переносить изменения выборочно с учетом различий веток. При размещении задания обновить его место во входе в задания и связанные ссылки; существующие задания ODS, измерений и DM сохраняются. ## Общая проверка готовности - [ ] Из описанного начального состояния выполнены все случаи задания на стенде; сохранены команды и наблюдаемые результаты. - [ ] Неверное решение обнаруживается предусмотренными проверками; восстановление и повторный запуск проверены там, где они входят в задание. - [ ] Инструкция на русском соответствует подготовке учащегося, различает готовые части и самостоятельные решения; результат позволяет продолжить маршрут. - [ ] Проверены ссылки и команды; `git diff --check` пройден. Для изменений Python/DAG выполнены `make lint` и `make test`, а пропуски тестов перечислены отдельно. Статические проверки не заменяют учебный прогон. ## Сначала прочитать - Задачу серии #8 и [авторскую заметку](https://git.dementev.space/ddmitry/airflow-greenplum/src/branch/solution/docs/design/labs_development.md). - [Инкремент STG](https://git.dementev.space/ddmitry/airflow-greenplum/src/branch/main/sql/stg/bookings_load.sql) - [DQ окна](https://git.dementev.space/ddmitry/airflow-greenplum/src/branch/main/sql/stg/bookings_dq.sql) - [STG-DAG и генератор](https://git.dementev.space/ddmitry/airflow-greenplum/src/branch/main/airflow/dags/bookings_to_gp_stage.py) - [Руководство STG](https://git.dementev.space/ddmitry/airflow-greenplum/src/branch/main/docs/bookings_to_gp_stage.md)
ddmitry added the needs-triage label 2026-09-22 16:35:47 +03:00
Sign in to join this conversation.
No Branch/Tag Specified
Labels
Clear labels
needs-info
Ждём уточнений от автора постановки.
 needs-triage
Постановка подготовлена; требуется оценить объем и готовность к работе.
 ready-for-agent
Полностью описано, можно отдавать AFK-агенту.
 ready-for-human
Требует реализации человеком.
 wontfix
Делать не будем.
No labels needs-triage
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
ddmitry (Dmitry Dementiev)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: ddmitry/airflow-greenplum#10