0 Fork 0

Files

T

ddadminandClaude Fable 5 4a04a2caf6 docs: лесенка схем, метод чтения пайплайна и таксономия DQ

Одна диаграмма отвечает на один вопрос: db_schema.md перестроен в лесенку
из четырёх схем (слои, звезда, сборка факта, витрины), полная lineage-карта
перенесена в конец как справочная. Новые документы: reading_the_pipeline.md
(метод чтения FROM/JOIN load-скрипта, разбор fact_src) и dq_taxonomy.md
(три класса DQ-проверок на реальных скриптах, семантика NULL). Точки входа:
корневой README, docs/README.md, assignment/README.md, qa-plan.md.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

2026-07-20 14:56:42 +03:00

4.6 KiB

Raw Blame History

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

DQ-проверка должна отвечать на конкретный вопрос. В этом проекте есть три класса. Один *_dq.sql может содержать проверки нескольких классов.

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-проверки, зафиксировано в разделе «Ключевые договорённости».

4.6 KiB Raw Blame History Unescape Escape