2022-08-29 15:59:12
У ребят из Datafold еще в июле вышла прекрасная статья - https://is.gd/l4oNaY. Основной фокус в статье можно описать одним предложением:
*Rather than building systems that detect and alert on breakages, build systems that don’t break.*Observability это хорошо, очень хорошо. Но если вы в день видите 24 уведомления о том, что у вас кривые данные, весь ваш день будет потрачен на то, чтобы эти кривые данные поправить. Так может стоит инвестировать в то, чтобы строить то, что не ломается? Например, тесты, data lineage, data diff. Про это в статье как раз речь.
Мы имеем свойство переоценивать количество проблем с данными, которые приходят снаружи, и существенно недооцениваем количество наших собственных косяков. Основные драйверы этой проблемы
1.
Данные это сложно – чтобы писать нормальный код, нужно знать очень многое про модель и про то, какие данные туда приходят, как они туда приходят, какое распределение у них и так далее.
2.
Нам еще и бизнес-логики туда накрутили - SQL в тыщу строк? Легко!
3.
Поставщики данных не спят и развиваются - платформы данных должны успевать за всеми изменениями поставщиков данных, а их много и они развиваются с огромной скоростью. Нас ждать не будут.
4.
Быстрее, быстрее, быстрее! - стейкхолдеры ждут свои дашборды, чтобы принимать решения. Тут все старо как мир.
Статью советую взглянуть, вещи хоть и относительно простые и очевидные написаны, но очень важные.
P.S.
Datafold делает тулзу для DQ и опытный человек мог заметить UTM-ссылку, можно сказать, что я аффилирован! Опять же, мне никто за это не платит, с ребятами я знаком давно и лично, когда-то, даже, когда их было всего 5-7 человек, мы с ними поработали вместе несколько месяцев. Мне нравится, что и как они делают. Глеб, привет!
@ohmydataengineer
406 viewsDenis Afanasev, 12:59
К
