Пайплайн может отработать «зелёным» и при этом положить в витрину мусор: пустую выгрузку, задвоенные строки, суммы в копейках вместо рублей. Пользователь узнаёт об этом раньше вас, и доверие к данным теряется надолго. Поэтому проверки качества это часть пайплайна, а не разовая акция.
Измерения качества
- Полнота: все ли строки и поля на месте. Пустые обязательные поля, пропавший день, половина партиций.
- Уникальность: нет дублей по ключу.
- Валидность: значения в допустимом формате и диапазоне: email похож на email, сумма не отрицательная, статус из списка.
- Согласованность: данные согласованы между таблицами и системами: у каждого заказа есть клиент, сумма заказа равна сумме позиций, выручка в DWH сходится с бухгалтерией.
- Свежесть (timeliness): данные обновились вовремя.
- Точность: данные соответствуют реальности. Проверяется сверками с источником.
Какие проверки ставить
- На входе (после загрузки в staging): схема совпадает, объём в ожидаемых пределах, обязательные поля заполнены. Если проверка критичная и падает, дальше по пайплайну плохие данные не идут.
- После трансформаций: уникальность ключей витрин, ссылочная целостность, бизнес-инварианты (выручка не отрицательная, доля от 0 до 1).
- Сверки: число строк и суммы между источником и хранилищем.
- Мониторинг по времени: свежесть таблиц, аномалии объёма и распределений (сегодня строк вдвое меньше, чем обычно по вторникам; доля NULL выросла с 1% до 30%).
Проверки делятся по реакции: блокирующие (остановить пайплайн, витрина не обновится, но и мусор не покажет) и предупреждающие (алерт, данные проходят). Блокирующих должно быть немного, но точных: иначе пайплайн будет постоянно стоять из-за ложных срабатываний.
Инструменты: тесты dbt, Great Expectations, Soda, проверки в самом SQL, платформы наблюдаемости данных. Важнее инструмента дисциплина: каждая важная таблица покрыта проверками, у каждого алерта есть владелец.
Контракты данных
Частая причина поломок: команда сервиса переименовала колонку или поменяла смысл поля, а аналитический пайплайн узнал об этом утром по упавшим отчётам. Контракт данных это явное соглашение между производителем и потребителем:
- схема: поля, типы, обязательность;
- семантика: что означает поле, единицы измерения, допустимые значения;
- гарантии: свежесть, объём, способ доставки;
- владелец и порядок изменений: несовместимые изменения через версию и уведомление.
Контракт проверяется автоматически: в CI сервиса (миграция, ломающая контракт, не проходит), в реестре схем для событий Kafka (правила совместимости), на входе пайплайна.
Совместимость схем:
- Обратная (backward): новые потребители читают старые данные. Можно удалить поле, добавить поле со значением по умолчанию.
- Прямая (forward): старые потребители читают новые данные. Можно добавить поле.
- Несовместимые изменения: переименование, смена типа, смена смысла. Только через новую версию.
Lineage
Lineage (происхождение данных) показывает, откуда пришли данные таблицы и куда они идут дальше. Нужен, чтобы оценить влияние изменения («кто сломается, если удалить колонку»), найти первопричину инцидента и выполнять требования (где хранятся персональные данные). dbt строит lineage автоматически по ref и source, для всей платформы используют каталоги данных.
Инциденты с данными
Когда данные сломались:
- Остановить распространение: пометить витрину, приостановить зависимые задачи.
- Сообщить потребителям, что данные за период под вопросом.
- Найти первопричину по lineage и логам.
- Исправить и перезагрузить затронутые периоды: здесь окупается идемпотентность пайплайнов.
- Добавить проверку, которая поймала бы это в следующий раз.
Частые ошибки
- Проверять только то, что задача завершилась без ошибок.
- Сотни предупреждающих алертов, на которые никто не смотрит.
- Жёсткие пороги объёма без учёта сезонности и дня недели.
- Изменения схем источника без уведомления потребителей.
- Исправлять данные руками в витрине вместо исправления пайплайна и перезагрузки.
Что спросят на собесе
- Какие бывают измерения качества данных.
- Какие проверки вы ставите и где в пайплайне, какие блокируют.
- Что такое контракт данных, обратная и прямая совместимость схем.
- Что такое lineage и зачем он нужен.
- Как вы действуете при инциденте с данными.