Качество данных: четыре метрики, которые реально работают
Большинство программ по качеству данных заходят в тупик из-за абстрактных метрик. Вот четыре конкретных измерения, которые рано выявляют проблемы и связаны с бизнес-результатами.
Качество данных - одна из тех тем, где теория разумна, а практика болезненна. Команды соглашаются, что качество важно, кого-то просят «измерить его», и через несколько недель появляется дашборд, на который никто не смотрит.
Обычная причина: выбранные метрики слишком общие, чтобы по ним что-то делать. «Общая заполненность: 94%» почти ничего не говорит о том, что исправлять и где ущерб.
Я нашёл небольшой набор измерений, которые стабильно выявляют реальные проблемы и достаточно дёшевы в поддержке.
Заполненность по полю, а не по записи
Стандартный подход измеряет, в скольких записях заполнены все поля. Это число скрывает всё. Запись может быть заполнена на 95% и при этом быть бесполезной, если единственное отсутствующее поле - то, от которого зависят ваши отчёты.
Полезнее: отслеживать заполненность каждого критичного поля отдельно, а «критичным» считать то, отсутствие которого сломает downstream-отчёт или решение. Обычно это пять-восемь полей на датасет. Проверяйте их ежедневно.
Свежесть - не «джоб прошёл зелёным», а «насколько старые данные»
У большинства пайплайнов есть флаг успеха: задача выполнена, ошибок нет. Но флаги успеха не говорят, актуальны ли данные. Я видел системы, где задача «успешно» перезагружает снимок прошлой недели, потому что апстрим был недоступен, а ошибка была проглочена молча.
Отслеживайте возраст самой новой записи в каждом критичном датасете. Установите порог - скажем, «данные о продажах старше 26 часов - это проблема» - и оповещайте об этом. Это ловит класс инцидентов с устаревшими данными, которые незаметно идут несколько дней.
Ссылочная согласованность между системами
В большинстве компаний одна и та же сущность - клиент, продукт, договор - существует в нескольких системах с разными идентификаторами. Отчёты, которые делают join между системами, молча теряют строки, когда ключи не совпадают.
Измеряйте: для каждого кросс-системного join в слое отчётности отслеживайте процент совпадений. Если вчера 98% заказов совпадали с записью о клиенте, а сегодня 91% - что-то сломалось. По флагу успеха пайплайна этого не увидеть.
Аномалии объёма относительно истории
Резкое падение числа строк - или резкий рост - почти всегда сигнал о проблеме выше по потоку. Исходная таблица была очищена. Случайно добавился фильтр. Изменилось окно выгрузки.
Отслеживайте ежедневное число строк по каждому датасету относительно скользящего среднего. Простое правило - пометить всё, что выходит за пределы 20% от диапазона за 30 дней, - ловит большинство таких инцидентов до того, как бизнес это замечает.
Связывание качества с ценой
Эти четыре метрики поддерживаются только тогда, когда кто-то видит цену их игнорирования. Я всегда стараюсь привязать каждую метрику к бизнес-событию: устаревший фид цен означает, что предложения выставляются по вчерашним ставкам; битый join по клиентам означает, что часть заказов пропадает из отчётов по выручке.
Когда разговор переходит от «наш индекс заполненности 93%» к «три раза в прошлом месяце маркетинговые отчёты теряли 8% заказов, потому что join к таблице продуктов ломался в полночь» - поддержка становится приоритетом, а не уборкой.
Минимальная отправная точка
Для начала не нужна платформа наблюдаемости данных. Набор SQL-запросов, выполняемых ежедневно и записывающих результаты в таблицу, достаточен для формирования привычки. Платформа придёт позже, когда команда разберётся, какие проверки важны и как реагировать на сбои.
Цель первых трёх месяцев - не идеальный индекс качества. Это выработка инстинкта проверять перед тем, как доверять.