Лабораторная: применить новые и измененные строки из STG в ODS #11

New Issue

2026-09-22T16:35:50+03:00

ddmitry commented

2026-09-22 16:35:50 +03:00

Part of #8

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

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

Студент собирает текущее типизированное состояние ODS из накопленных пачек STG: вставляет новые ключи, применяет изменения существующих и сохраняет происхождение данных. Он может проверить обработку дельты независимо от способа доставки источника.

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

Предпосылки для учащегося — существующие задания на снимки ODS и лабораторная по инкременту STG. Кандидат — bookings. Даны DDL и способ запуска; студент пишет преобразования, выбор версий и обновление ODS, затем собственные проверки результата.

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

Подготовить пачки STG с новыми ключами, несколькими версиями одного ключа и новой версией старого бронирования. Времена и порядок пачек должны однозначно определять ожидаемую версию; проверить несколько поступивших батчей перед одним запуском ODS.
Новую версию старой записи подать прямо в STG. Текущий прием источника по book_date ее автоматически не захватывает; успешный опыт ODS не является доказательством доставки такого исправления из Postgres.
Реализовать типизацию, дедупликацию дельты и применение изменений. Зафиксировать метки по договору эталона: новые и измененные строки получают _load_id и _load_ts выбранной версии STG; если book_date, total_amount и event_ts не изменились, строка ODS сохраняет прежние метки.
Развести два опыта. Для пустой дельты подготовить запуск, после которого MAX(_load_ts) ODS достиг максимума подготовленного STG, и повторить без новых данных. Затем подать отдельную пачку с более поздней _load_ts, но прежними бизнес-полями и event_ts. Она попадает в дельту, однако не меняет ODS и его границу загрузки; при повторе может читаться снова. Отсутствие изменений результата само по себе не означает пустую дельту.
Сверить ожидаемое состояние всех затронутых ключей, бизнес-поля и технические метки в каждом опыте. Испытать собственную проверку на известном неверном значении или пропущенном ключе и восстановить корректный результат.

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

Входные пачки и ожидаемые версии воспроизводимы; различены event_ts и _load_ts.
Новые ключи вставляются, изменения применяются, дублей нет; бизнес-поля и метки новых, измененных и неизмененных строк соответствуют заданному договору.
Несколько накопленных батчей обработаны одним запуском. Отдельно проверены пустая дельта и непустая дельта без изменений ODS, включая их повтор.
Собственная DQ-проверка обнаруживает внесенную ошибку и проходит после исправления.
После опыта ODS приведен в состояние, пригодное для следующих заданий DDS.

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

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

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

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

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

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

Part of #8 ## Статус и учебный результат Кандидат на расширение обязательного цикла; перед реализацией оценить объем и место в маршруте. Студент собирает текущее типизированное состояние ODS из накопленных пачек STG: вставляет новые ключи, применяет изменения существующих и сохраняет происхождение данных. Он может проверить обработку дельты независимо от способа доставки источника. ## Место и самостоятельная часть Предпосылки для учащегося — существующие задания на снимки ODS и лабораторная по инкременту STG. Кандидат — `bookings`. Даны DDL и способ запуска; студент пишет преобразования, выбор версий и обновление ODS, затем собственные проверки результата. ## Что предусмотреть 1. Подготовить пачки STG с новыми ключами, несколькими версиями одного ключа и новой версией старого бронирования. Времена и порядок пачек должны однозначно определять ожидаемую версию; проверить несколько поступивших батчей перед одним запуском ODS. 2. Новую версию старой записи подать прямо в STG. Текущий прием источника по `book_date` ее автоматически не захватывает; успешный опыт ODS не является доказательством доставки такого исправления из Postgres. 3. Реализовать типизацию, дедупликацию дельты и применение изменений. Зафиксировать метки по договору эталона: новые и измененные строки получают `_load_id` и `_load_ts` выбранной версии STG; если `book_date`, `total_amount` и `event_ts` не изменились, строка ODS сохраняет прежние метки. 4. Развести два опыта. Для пустой дельты подготовить запуск, после которого `MAX(_load_ts)` ODS достиг максимума подготовленного STG, и повторить без новых данных. Затем подать отдельную пачку с более поздней `_load_ts`, но прежними бизнес-полями и `event_ts`. Она попадает в дельту, однако не меняет ODS и его границу загрузки; при повторе может читаться снова. Отсутствие изменений результата само по себе не означает пустую дельту. 5. Сверить ожидаемое состояние всех затронутых ключей, бизнес-поля и технические метки в каждом опыте. Испытать собственную проверку на известном неверном значении или пропущенном ключе и восстановить корректный результат. ## Критерии этой лабораторной - [ ] Входные пачки и ожидаемые версии воспроизводимы; различены `event_ts` и `_load_ts`. - [ ] Новые ключи вставляются, изменения применяются, дублей нет; бизнес-поля и метки новых, измененных и неизмененных строк соответствуют заданному договору. - [ ] Несколько накопленных батчей обработаны одним запуском. Отдельно проверены пустая дельта и непустая дельта без изменений ODS, включая их повтор. - [ ] Собственная DQ-проверка обнаруживает внесенную ошибку и проходит после исправления. - [ ] После опыта ODS приведен в состояние, пригодное для следующих заданий DDS. ## Границы и результат работы автора Подготовить задание для студента, необходимые заготовки/проверки и проверенный способ выполнения. Назвать входное состояние, самостоятельную часть, проверочные случаи и состояние для продолжения. Готовый стенд должен запускаться до лабораторной; выбранную часть разбирает уже студент во время задания. Стенд можно ломать и пересобирать, сохраняя файлы решения и понятный способ продолжения. Материалы для автора и полное решение относятся к `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). - [Загрузка ODS](https://git.dementev.space/ddmitry/airflow-greenplum/src/branch/main/sql/ods/bookings_load.sql) - [DQ ODS](https://git.dementev.space/ddmitry/airflow-greenplum/src/branch/main/sql/ods/bookings_dq.sql) - [Руководство ODS](https://git.dementev.space/ddmitry/airflow-greenplum/src/branch/main/docs/bookings_to_gp_ods.md) - [Служебные поля](https://git.dementev.space/ddmitry/airflow-greenplum/src/branch/main/docs/design/naming_conventions.md)

ddmitry added the needs-triage label 2026-09-22 16:35:50 +03:00

ddmitry referenced this issue

2026-09-22 16:36:30 +03:00

Расширить обязательную программу практикой полного цикла DWH #8

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: ddmitry/airflow-greenplum#11