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

Что проверяют

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

Как отвечать

Назовите измерения качества и к каждому привяжите проверку:

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

Дальше расскажите, где проверки живут. На входе контракт схемы с источником. Внутри пайплайна тесты между этапами: встроенные тесты dbt (unique, not_null, accepted_values, relationships), Great Expectations или Soda, для Spark библиотека Deequ, для pandas pandera. Проверки делят на блокирующие, которые останавливают загрузку и уводят строки в карантинную таблицу, и предупреждающие, которые только шлют алерт владельцу данных.

Для ML добавьте своё. Утечка таргета при подготовке признаков. Расхождение признаков при обучении и в проде (training/serving skew): общий код расчёта признаков снимает большую часть проблемы. Дрейф: PSI или KS-тест по признакам, отчёты Evidently. Качество разметки: выборочная перепроверка и согласие разметчиков.

Закончите примером из практики: какая проверка сработала и что было бы без неё.

Где спотыкаются

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

Проверяют только схему и NULL. Если выгрузка пришла наполовину пустой, not_null пройдёт, а упавшее вдвое число строк заметит только проверка объёма.

Делают все проверки блокирующими. Пайплайн встаёт из-за мелочи, команда начинает отключать проверки, и через месяц не остаётся ни одной.