Почему ваши 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σ уехало «Ну… вроде странно, но не факт»
- В прод-эксплуатации любят чёткие сигналы, а не «подозрения».