И что дальше? Как приложить?
Как мне когда-то говорили: "Чтобы представить 5-мерное пространство, то закройте глаза и представьте трехмерное, а затем громко и уверенно скажите: "ПЯТЬ!""
Так и тут. Датчик температуры замените на любой статистически значимый показатель, который отслеживается
Классический Data Quality отвечает на вопрос: «как данные могут сломаться?» Мы заранее придумываем правила — schema, ranges, uniqueness, freshness, business constraints — и ждём их нарушения.
Но часть неприятных проблем устроена иначе. Данные проходят все проверки и при этом начинают вести себя не так, как раньше.
Допустим, температурный датчик на заводе продолжает стабильно присылать данные. Schema не изменилась, NULL'ов нет, значения в допустимом диапазоне, частота сообщений нормальная. Но исторически температура хорошо коррелировала с нагрузкой оборудования, а сегодня эта связь внезапно исчезла.
Причина может быть в firmware, mapping, единицах измерения, upstream join или изменении самого процесса. Формально данные валидны. Поведенчески — произошло что.-то странное.
Если compute достаточно много, можно попробовать строить Data Quality не только вокруг заранее известных failure modes, но и вокруг fingerprint нормального поведения данных.
Для каждой таблицы, партиции, машины, сенсора или завода можно отслеживать распределения, частоты, missingness patterns, correlations, сезонность и связи между признаками. А затем искать отклонения от собственной истории этой сущности.
Получается:
table / source / sensor → normal behavior → deviation → investigateЗдесь есть интересная аналогия с [NVIDIA Morpheus Digital Fingerprinting](https://docs.nvidia.com/morpheus/developer_guide/guides/5_digital_fingerprinting.html). Morpheus — cybersecurity framework, не Data Quality продукт. Но его подход похож: строится профиль нормального поведения пользователя, аккаунта, сервиса или машины, после чего новые события получают anomaly score.
Из этого паттерна для DQ мне нравятся три идеи:
• Не нужно заранее знать все способы поломки. Можно искать само изменение поведения.
• Baseline должен быть контекстным. Нормальное для одного завода, сенсора или типа оборудования может быть аномалией для другого.
• Detection и explanation можно разделить. Массовую обработку и anomaly scoring делать специализированными вычислениями, а LLM подключать уже после — для объяснения, triage и работы с человеком.
При большом числе источников и срезов быстро начинается combinatorial explosion. plant × machine × product × shift × supplier × operating mode превращает сотню ручных проверок в десятки тысяч потенциальных сигналов.
И вот здесь GPU становится интересен не как ускоритель одной проверки, а как способ сделать такой уровень наблюдаемости экономически возможным.
Не только проверять то, что мы уже знаем как ошибку.
А замечать, когда данные перестали быть похожими на самих себя.