0 Fork 0

Files

T

ddadmin 35144e49f6 docs: согласованы руководства загрузок и учебный маршрут

Руководства STG/ODS/DDS/DM сверены с действующими SQL и DAG,
ожидания учебных заглушек связаны с ТЗ. Самопроверка заданий
отделена от проверок разработки и исторических планов.

Для dim_routes закреплено обновление описательных полей только
у открытых версий. SQL, DAG, DDL и настройки стенда не менялись.

Проверки: make lint; make test (4 passed, 14 skipped); карта;
292 локальные ссылки; маршрут чтения и карта в Chromium.
Живой ETL не запускался.

2026-09-20 15:53:39 -04:00

5.1 KiB

Raw Blame History

Классы DQ-проверок

DQ-проверка должна отвечать на конкретный вопрос. В этом проекте есть три класса. Один *_dq.sql может содержать проверки нескольких классов. Сверяйте их с полями и правилами своего объекта в ТЗ. Как запустить DQ и проверить задание, описано в инструкции самопроверки. На main учебные DQ содержат SELECT 1; и начнут проверять данные после вашей реализации.

1. Универсальные структурные проверки

Они проверяют форму таблицы: обязательные ключи заполнены, ключ уникален, а таблица не пуста там, где по контракту ожидаются строки. Так можно быстро поймать сломанное зерно или незавершённую загрузку без знания бизнес-смысла данных.

Реальные примеры:

sql/dds/dim_airports_dq.sql требует непустую таблицу, проверяет уникальность airport_sk и airport_bk, а также обязательные поля.
sql/ods/bookings_dq.sql ищет дубли book_ref и NULL или пустые значения в обязательных полях. Пустой инкрементальный батч здесь допустим.
sql/ods/tickets_dq.sql проверяет уникальность ticket_no, обязательные поля и отсутствие билетов без bookings.book_ref.

2. Проверки бизнес-правил

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

В sql/dm/sales_report_dq.sql для дат текущего запуска проверяется, что tickets_sold >= passengers_boarded, boarding_rate лежит между 0 и 1, а total_revenue неотрицательна.

3. Межслойные сверки

Они отвечают на вопрос: согласован ли слой N+1 со слоем N для нужного батча? Сверка находит потерянные или лишние строки на границе загрузки.

Реальные примеры используют разные способы сверки:

sql/ods/airports_dq.sql сравнивает множества airport_code: ищет пропущенные и лишние ключи относительно текущего STG-батча. Это сверка ключей, а не простое сравнение числа строк.
sql/stg/airplanes_dq.sql сравнивает число строк во внешней stg.airplanes_ext и в текущем батче stg.airplanes.
sql/dds/fact_flight_sales_dq.sql требует равенства числа строк факта и ods.segments, потому что зерно факта — один сегмент билета.

`NULL` — не всегда ошибка

В fact_flight_sales_load.sql измерения присоединяются через LEFT JOIN. Факт может прийти раньше измерения, поэтому route_sk, airplane_sk или passenger_sk временно бывают NULL. На ветке main это также ожидаемо, пока студент не реализовал эти измерения. Такой NULL сохраняет строку факта и не должен сам по себе останавливать пайплайн.

seat_no тоже может быть NULL: у билета уже есть сегмент, но записи boarding_passes ещё нет. Обязательный ключ, напротив, должен быть заполнен. Например, NULL в airport_sk измерения или в (ticket_no, flight_id) факта нарушает контракт таблицы.

Архитектурное решение о том, где живут DQ-проверки, зафиксировано в разделе «Ключевые договорённости».

5.1 KiB Raw Blame History Unescape Escape