← вся теориятеория к собесу · ETL и оркестрация

Качество данных в пайплайне

Качество данных: проверки в пайплайне

Качество данных это проверки как часть пайплайна, а не «разберёмся, если пожалуются». Собес проверяет, встраиваешь ли ты контроль на границах слоёв и различаешь ли блокирующие проверки от предупреждающих.

Стержень: зелёный статус джобы отвечает только на «выполнилась ли», а не на «данные верны ли»; проверяют свежесть, объём, схему, ключи, NULL, целостность.

// Формулировки: «как контролируешь качество данных?», «что такое data contract?», «как ловить аномалии объёма?».

Что и где проверять

Набор проверок: свежесть (данные не старше порога от расписания), объём, схема, уникальность ключей, доля NULL, ссылочная целостность. Это минимум, встроенный в конвейер.

Проверки ставят на границах: на входе (сырьё от источника - schema drift, аномальные объёмы) и на выходе (витрина перед публикацией). Так проблему ловят до потребителя и локализуют до конкретного слоя.

// Главный сдвиг мышления: «джоба зелёная» не значит «данные живые». Пайплайн может отработать успешно и записать мусор, поэтому проверяют сами данные, а не только факт выполнения.

freshness check: данные не старше порога от расписания
schema drift: незапланированное изменение схемы источника

Severity и аномалии

Severity разделяют. Blocker роняет пайплайн (дубль ключей в core - публиковать нельзя), warning алертит без остановки (рост доли NULL на 2%). Крайности вредны одинаково: всё-blocker даёт вечно красный конвейер, всё-warning - алерты, которые никто не смотрит.

Объёмные аномалии проверяют против истории, а не против констант: «строк сегодня в пределах ±3σ от того же дня недели» встраивает сезонность. Порог-константа «больше 1000 строк» ломается на праздниках и росте.

// Понедельник после праздников - законный провал объёма; проверка против истории это учтёт, а константа поднимет ложную тревогу и приучит игнорировать алерты.

blocker / warning: роняет пайплайн / алертит без остановки
anomaly detection: проверка объёмов и распределений против истории

Инструменты, контракты, статус

Проверки делают декларативными и версионируемыми: dbt tests (unique, not_null, relationships, accepted_values), Great Expectations - они живут в коде рядом с моделями. Data contract с источником фиксирует схему, типы и SLA (service level agreement) поставки явно, превращая смену схемы без предупреждения из «сюрприза» в нарушение контракта.

Инцидент означает пометку данных: потребитель видит статус (не свежо, подозрительно). Дашборд на битых данных без плашки опаснее пустого - ему верят.

// И само качество мониторят как процесс: доля прошедших проверок, время до обнаружения инцидента, повторяемость. Разовый аудит качество не держит - держит непрерывный контроль.

dbt tests: декларативные проверки моделей: unique, not_null, FK (foreign key)
data contract: формальное соглашение о схеме и SLA поставки

Как отвечать: «Как встроить проверки качества данных в пайплайн?»

Я отношусь к качеству как к части пайплайна, а не к разбору жалоб постфактум. Ставлю проверки на границах: на входе ловлю schema drift и аномальные объёмы от источника, на выходе проверяю витрину перед публикацией - так проблема не доходит до потребителя и локализуется до слоя. Проверяю не факт «джоба зелёная», а сами данные: свежесть, объёмы, уникальность ключей, долю NULL, ссылочную целостность. Проверки делю по severity - блокирующие роняют пайплайн, если публиковать нельзя, предупреждающие алертят; и то и другое в меру, иначе либо вечно красный конвейер, либо алерты, которые игнорируют. Объёмы сверяю с историей с учётом сезонности, а не с константой. Всё это держу декларативно в dbt tests или Great Expectations рядом с моделями, а со источниками фиксирую data contract. И помечаю данные статусом при инциденте, чтобы на битой витрине была плашка.

Почему это сильный ответ: проверки на границах, контроль данных а не статуса, разумный баланс severity, аномалии против истории и декларативные инструменты с контрактами - зрелый процесс, а не набор ассертов.

На чём валят

−Проверять только «джоба зелёная» - пайплайн жив, данные мертвы.
−Пороги-константы («больше 1000 строк») - ломаются на сезонности и росте.
−Все проверки блокирующие - праздничный понедельник останавливает всё хранилище.
−Проверки есть, алерты - в канал, который никто не читает.
−Чинить данные руками в витрине, не фиксируя причину в пайплайне - инцидент вернётся.

Проверьте себя

Пять вопросов из банка по этой подтеме. Всего их 10, остальные разбираются в тренажёре.

#data_quality1 / 5
Зачем ставить проверки данных на входе пайплайна (data contracts)?
A)Fail fast: ловим битые данные на входе, пока они не отравили витрины
B)Проверки на входе замедляют пайплайн и не приносят пользы
C)Данные на источнике идеально чистые, поэтому входные проверки — лишняя перестраховка
D)Контракт данных нужен юридическому отделу компании
показать ответ и разбор
+A)Fail fast: ловим битые данные на входе, пока они не отравили витрины
// разбор: Дешевле упасть на входе, чем потом чинить каскад испорченных витрин и переобучать на грязных данных модели. Data contract фиксирует ожидания к источнику (схема, типы, доли пропусков, объёмы) и проверяет их до трансформаций. Источники ломаются молча — сменили колонку, прислали пустую партицию, — и fail-fast ловит это первым.
#data_quality2 / 5
Почему проверять только совпадение числа строк с прошлым запуском недостаточно?
A)Совпадения числа строк с предыдущим запуском достаточно
B)Счётчик строк пропустит сдвиг схемы, всплеск null'ов, дрейф распределений
C)Проверять распределения значений в проде технически сложно
D)Проверка сложнее подсчёта строк вредит стабильности пайплайна
показать ответ и разбор
+B)Счётчик строк пропустит сдвиг схемы, всплеск null'ов, дрейф распределений
// разбор: Число строк может не измениться, а содержимое уже испорчено: колонка стала null, категория переименовалась, значения уехали за диапазон, распределение сместилось. Нужны содержательные проверки — соответствие схемы, доля пропусков, границы значений, стабильность распределений (например, PSI), — иначе «тихая» порча пройдёт незамеченной.
#data_quality3 / 5
Что такое схема данных (schema) и зачем её валидировать на входе пайплайна?
A)Схема данных — это подробный граф всех зависимостей между задачами внутри оркестратора
B)Схема — цветовая палитра дашборда, её проверяют дизайнеры интерфейса
C)Схема — контракт на имена и типы колонок; валидация рано ловит сломанный источник
D)Схема — это число строк в таблице, которое сверяют между запусками пайплайна
показать ответ и разбор
+C)Схема — контракт на имена и типы колонок; валидация рано ловит сломанный источник
// разбор: Схема — контракт на структуру данных: имена колонок, типы, обязательность. Валидация схемы на входе ловит молчаливые поломки источника (переименовали колонку, сменили тип, прислали лишнее поле) до того, как они отравят трансформации и витрины. Это дешёвый fail-fast против дорогого разбора испорченных данных ниже по потоку.
#data_quality4 / 5
Задача отработала без ошибок, но в витрину пришло 10 строк вместо обычных 10 млн. Что поймало бы это?
A)Ничего: раз задача завершилась без ошибок, то и данные корректны
B)Проверка синтаксиса SQL-запроса перед его запуском в пайплайне
C)Проверка объёма: сравнение числа строк с историческим ожиданием, алерт на резкое отклонение
D)Увеличение числа повторных попыток задачи при её падении с ошибкой
показать ответ и разбор
+C)Проверка объёма: сравнение числа строк с историческим ожиданием, алерт на резкое отклонение
// разбор: «Зелёная» задача не гарантирует корректность данных: источник мог прислать пустую партицию или сломать фильтр. Volume-чек сравнивает объём выхода с историческим ожиданием (±N% или диапазон), а freshness-чек — что данные вообще свежие. Такие проверки ловят «тихие» обвалы, которые не роняют пайплайн, но отравляют витрину.
#data_quality5 / 5
Что делать с отдельными битыми записями, чтобы не ронять весь пайплайн?
A)Останавливать весь пайплайн из-за одной битой записи
B)Отправлять их в карантин/dead-letter, продолжив обработку валидных записей
C)Молча пропускать битые записи вообще без всякого учёта и логирования
D)Автоматически исправлять битые записи случайными подставленными значениями
показать ответ и разбор
+B)Отправлять их в карантин/dead-letter, продолжив обработку валидных записей
// разбор: Одна битая строка не должна валить весь батч. Валидные записи обрабатывают дальше, а невалидные отправляют в карантин (dead-letter таблицу/очередь) с причиной отклонения — их потом разбирают, не теряя. Метрика доли записей в карантине служит сигналом деградации источника: скачок — повод расследовать.

дальше

Теорию прочитали. Навык ставится повторением

В Сеньорчике эта подтема идёт в ежедневных сессиях: движок возвращает её, пока ответы не станут уверенными, и ведёт прогресс отдельно по каждой подтеме. Теория внутри тоже бесплатна, лимит только на количество вопросов в день.

Открыть тренажёр Вся тема: ETL и оркестрация