Можно бесконечно долго сожалеть о трех вещах: о сообщениях бывшим, о том что много выпила на тусе и о том, что вовремя не была настроена проверка качества данных.
Нет, конечно, про базовую проверку на типы данных/null/объем данных сложно забыть. Но вот с бизнес-смыслом иногда бывает косяк.
А теперь расскажу о том, как это выглядит на практике (по мотивам задачи у меня на работе).
Представьте ситуацию: ваша компания/команда занимается аналитикой данных. Вы высылаете требования заказчику о формате передаваемых вам данных, где четко прописано, что в необходимой выгрузке конкретно вот это поле должно отвечать за что-то. У вас при этом под эту логику заточен расчет какого-то агрегата.
И вот вы льете данные, доверяя заказчику (ну, вы же скинули требования, там все четко написано, какие проблемы могут быть).
Данные залиты, базовые дашборды с метриками подняты и вы довольные сидите
Проходит время, появляется потребность в создании нового дашборда с более детальной инфой. Начинаете делать, а там дичь какая-то на графиках. Аля суммы продаж на миллиарды в маленьком магазине в Урюпинске с населением в 100 человек, что явно вызывает подозрения.
И вот вы на батискафе (главное, чтобы это был не «Титан») совершаете погружение в пучину данных.
Начинаете проверять и понимаете, что в поле записано совершенно другое значение (не то, которое вы прописали в тербованиях заказчику). Неприятно очень знаете ли. Все это время и ваша команда, и заказчик смотрели на невалидные цифры.
В данных всегда больше ошибок, чем кажется. И последствия использования таких данных довольно печальные. Например, американские компании ежегодно терпят ущерб почти в 600 млн долларов. Так что, всегда лучше потратить больше времени на обвязку данных различными проверками на качество.
#трудовыебудни