Лабораторная: собрать факт продаж с ключами измерений #12

New Issue

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

ddmitry commented

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

Part of #8

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

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

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

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

Учащийся выполнил существующие задания на измерения DDS; после этой работы переходит к витринам DM. Кандидат — dds.fact_flight_sales. DDL и запуск можно оставить готовыми; студент собирает факт с нуля собственным SQL, затем проверяет обновление уже записанных строк. При подготовке решить, входит ли самостоятельный DDL сюда или в отдельный опыт с распределением.

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

После загрузки и проверки измерений очистить dds.fact_flight_sales перед первым запуском собственного SQL. Согласовать этот шаг с существующим пересчетом после измерений: первую сборку выполняет студент. При непустом ODS проверка должна обнаруживать отсутствие его INSERT; готовые строки эталона не засчитываются как результат.
Описать требования к SQL: зерно (ticket_no, flight_id), обязательные источники, допустимое отсутствие посадочного талона, две роли аэропорта, ключи измерений и версия маршрута на дату рейса.
Подготовить небольшой разборчивый контрольный набор: билет с несколькими сегментами, сегмент без талона, рейсы по обе стороны границы SCD2 и точно на ней. Проверить полуоткрытые интервалы версий.
Восстановить загрузку новых строк и обновление цены, места и признака посадки. Зафиксировать договор существующей реализации: SK уже записанного факта сохраняются. Первичная сборка после очистки заполняет SK из готовых измерений; переобогащение существующих строк опоздавшими измерениями остается отдельной задачей.
Сверить ключи и бизнес-поля с независимым расчетом по источникам; намеренные потеря и размножение строк должны обнаруживаться. Одного равенства числа строк недостаточно.
После собственной сборки проверить повтор, затем изменение цены или появление талона на подготовленной строке ODS. Между этими запусками факт сохраняется, чтобы проверялся UPDATE существующей строки. Проверка должна обнаружить пропуск обновления. Подготовить проверенный факт для последующих витрин.

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

Первичная сборка начинается с пустого факта и проверенных измерений; отсутствие собственного INSERT обнаруживается проверкой.
Все исходные ключи покрыты ровно один раз; значения и ссылки на измерения проверены, включая границу SCD2.
Повтор не меняет бизнес-результат; изменение цены или появление талона обновляет существующую строку без дублей и смены SK. Пропуск UPDATE обнаруживается проверкой.
Подготовленные ошибки обнаруживаются; эталонная витрина sales_report работает на восстановленном факте.

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

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

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

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

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

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

Part of #8 ## Статус и учебный результат Кандидат на расширение обязательного цикла; перед реализацией определить объем вычитания и место после измерений DDS. Студент самостоятельно собирает факт на зерне сегмента билета, соединяет операционные данные с измерениями и проверяет сохранение ключей и значений. Он применяет SCD2 при подборе версии измерения и умеет проверить обновление существующего факта. ## Место и самостоятельная часть Учащийся выполнил существующие задания на измерения DDS; после этой работы переходит к витринам DM. Кандидат — `dds.fact_flight_sales`. DDL и запуск можно оставить готовыми; студент собирает факт с нуля собственным SQL, затем проверяет обновление уже записанных строк. При подготовке решить, входит ли самостоятельный DDL сюда или в отдельный опыт с распределением. ## Что предусмотреть 1. После загрузки и проверки измерений очистить `dds.fact_flight_sales` перед первым запуском собственного SQL. Согласовать этот шаг с существующим [пересчетом после измерений](https://git.dementev.space/ddmitry/airflow-greenplum/src/branch/main/docs/assignment/analyst_spec.md#пересчёт-факта-после-реализации-измерений): первую сборку выполняет студент. При непустом ODS проверка должна обнаруживать отсутствие его INSERT; готовые строки эталона не засчитываются как результат. 2. Описать требования к SQL: зерно `(ticket_no, flight_id)`, обязательные источники, допустимое отсутствие посадочного талона, две роли аэропорта, ключи измерений и версия маршрута на дату рейса. 3. Подготовить небольшой разборчивый контрольный набор: билет с несколькими сегментами, сегмент без талона, рейсы по обе стороны границы SCD2 и точно на ней. Проверить полуоткрытые интервалы версий. 4. Восстановить загрузку новых строк и обновление цены, места и признака посадки. Зафиксировать договор существующей реализации: SK уже записанного факта сохраняются. Первичная сборка после очистки заполняет SK из готовых измерений; переобогащение существующих строк опоздавшими измерениями остается отдельной задачей. 5. Сверить ключи и бизнес-поля с независимым расчетом по источникам; намеренные потеря и размножение строк должны обнаруживаться. Одного равенства числа строк недостаточно. 6. После собственной сборки проверить повтор, затем изменение цены или появление талона на подготовленной строке ODS. Между этими запусками факт сохраняется, чтобы проверялся UPDATE существующей строки. Проверка должна обнаружить пропуск обновления. Подготовить проверенный факт для последующих витрин. ## Критерии этой лабораторной - [ ] Первичная сборка начинается с пустого факта и проверенных измерений; отсутствие собственного INSERT обнаруживается проверкой. - [ ] Все исходные ключи покрыты ровно один раз; значения и ссылки на измерения проверены, включая границу SCD2. - [ ] Повтор не меняет бизнес-результат; изменение цены или появление талона обновляет существующую строку без дублей и смены SK. Пропуск UPDATE обнаруживается проверкой. - [ ] Подготовленные ошибки обнаруживаются; эталонная витрина `sales_report` работает на восстановленном факте. ## Границы и результат работы автора Подготовить задание для студента, необходимые заготовки/проверки и проверенный способ выполнения. Назвать входное состояние, самостоятельную часть, проверочные случаи и состояние для продолжения. Готовый стенд должен запускаться до лабораторной; выбранную часть разбирает уже студент во время задания. Стенд можно ломать и пересобирать, сохраняя файлы решения и понятный способ продолжения. Материалы для автора и полное решение относятся к `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). - [Сборка факта](https://git.dementev.space/ddmitry/airflow-greenplum/src/branch/main/sql/dds/fact_flight_sales_load.sql) - [DDL факта](https://git.dementev.space/ddmitry/airflow-greenplum/src/branch/main/sql/dds/fact_flight_sales_ddl.sql) - [DQ факта](https://git.dementev.space/ddmitry/airflow-greenplum/src/branch/main/sql/dds/fact_flight_sales_dq.sql) - [Разбор соединений](https://git.dementev.space/ddmitry/airflow-greenplum/src/branch/main/docs/design/reading_the_pipeline.md#fact-joins) - [Требования к измерениям](https://git.dementev.space/ddmitry/airflow-greenplum/src/branch/main/docs/assignment/analyst_spec.md)

ddmitry added the needs-triage label 2026-09-22 16:35:55 +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#12