Почему ваши dbt-тесты врут, или Зачем дата-инженеру статистика
Привет! Меня зовут Черняховский Денис и я Data Engineer. Я достаточно подолжительное время работаю с данными и увлекаюсь математической статистикой. Совсем недавно решил поискать в интернете, как другие опытные дата инженеры исследуют качество данных при помощи статистики, и обнаружил, что никак ..... пум пум пум. А далее обнаружил, что проблема уходит корнями гораздо глубже, чем может показаться.В этой статье я постараюсь рассказать: - Почему дата инженерам необходимо использовать статистику и почему ни ее не используют - Проведем тесты на реальных примерах данных - Разберем проблему межпрофессионального разрыва компетенций между дата инженерами и аналитикамиПочему инженеру данных стоит использовать статистику?Разберем, какой базовый набор проверок/валидаций использует типочный дата инженер, да и аналитик тоже:Типичный чек-лист на проде: - NOT NULL - UNIQUE - REFERENTIAL INTEGRITY - row_count_today >= row_count_yesterday - max(updated_at) >= now() – 1h - revenue > 0Это бинарные правила, либо сломалось, либо нет. Те же, кто работает с качеством данных, ежедневно сталкивается с проблемой, когда бинарные проверки не показывают проблем, но аналитики и заказчик прибегают с горящими глазами и кричат, что все сломано.А статистика — это вероятностное мышление, статистика всегда покажет проблему и покажет ее первой, если данная проблема имеет место быть.Почему инженеры не используют статистику в валидации данных?Статистика «не орёт», когда что-то пошло не так Пример: - COUNT(*) = 0 АЛЕРТ - mean + 3σ уехало «Ну… вроде странно, но не факт» - В прод-эксплуатации любят чёткие сигналы, а не «подозрения». Читать далее