
Комментарии 3
чтобы не остаться на уровне валидаций данных 2010 года
Не совсем понятно, что в итоге предлагается. Заменить стандартные проверки на более "продвинутые" или дополнить мониторинг этими статистическими проверками? Если второе, то что делать с ложными срабатываниями?
Видим, что разница между средним и медианой в нашем случае огромна. Я бы не стал отдавать такие данные заказчику как минимум, а перепроверил бы слой raw.
Глазами видите. А проверка какая в итоге будет? И насколько универсальна и/или чувствительна будет такая проверка?
На мой взгляд в любом случае тема затронута очень интересная, поэтому спасибо за статью!
Да согласен, тема не раскрыта, буду делать более пояснительные статьи. Что касается статистики - этот инструмент гораздо глубже и полезнее для инженерии данных, чем кажется. Статистика - это одновременно и радар дальнего действия, который говорит, у тебя что то не так с данными прежде, чем сработает бинарная проверка и в тоже время статистика покажет проблему (если она есть), даже если все бинарные проверки отработали на ок. Что предлагается - использовать статистические методы вкупе с бинарными проверками (Эти методы не противники, они дополняют и усиливают друг друга). Что касается ложных срабатывали - существуют стат методы, которые очень трудно обмануть ложными срабатываниями, так как статистику вы используете на исторической агрегации, а не построчно.
Интересно. Даже хорошо, что начали с простейшего - есть возможность быстро оценить, а не высчитывать тонкие различия, а излишняя математичность часто отпугивает.
Почему ваши dbt-тесты врут, или Зачем дата-инженеру статистика