'/%3e%3cpath%20d='M83.8172%20112C100.688%20112%20111.886%2098.2694%20112%2083.8882H44.0245C25.8409%2083.8882%2016.001%2094.3169%2016.001%20112H83.8172Z'%20fill='url(%23paint1_linear_101_577)'/%3e%3cpath%20d='M44.1725%2044.1138H16.0008C15.9465%2051.0963%2018.504%2058.2306%2024.2977%2064.0225L44.1706%2083.8881L52.8986%2075.3569L61.7636%2066.7019C63.2767%2065.2244%2063.2786%2062.7888%2061.7636%2061.3094L44.1725%2044.1138Z'%20fill='%233A5FFF'/%3e%3cpath%20d='M83.8248%2083.8862H111.996C112.051%2076.9037%20109.493%2069.7693%20103.7%2063.9774L83.8267%2044.1118L75.0986%2052.6431L66.2337%2061.2981C64.7206%2062.7756%2064.7187%2065.2112%2066.2337%2066.6906L83.8248%2083.8862Z'%20fill='%233A5FFF'/%3e%3cdefs%3e%3clinearGradient%20id='paint0_linear_101_577'%20x1='16.001'%20y1='30.055'%20x2='111.998'%20y2='30.055'%20gradientUnits='userSpaceOnUse'%3e%3cstop%20stop-color='%2370ADFE'/%3e%3cstop%20offset='0.62'%20stop-color='%233A5FFF'/%3e%3c/linearGradient%3e%3clinearGradient%20id='paint1_linear_101_577'%20x1='111.998'%20y1='97.9451'%20x2='16.001'%20y2='97.9451'%20gradientUnits='userSpaceOnUse'%3e%3cstop%20stop-color='%2370ADFE'/%3e%3cstop%20offset='0.62'%20stop-color='%233A5FFF'/%3e%3c/linearGradient%3e%3c/defs%3e%3c/svg%3e)
Качество данных
Большая часть проблем в аналитике и ML на самом деле — проблемы данных. Модели и дашборды лишь усиливают то, что приходит на вход.
Ключевые свойства
- Полнота — нет пропущенных полей и записей, которые должны были быть.
- Точность — значения соответствуют реальности.
- Актуальность — данные обновляются с нужной частотой.
- Согласованность — одни и те же сущности одинаково описаны в разных системах.
- Уникальность — нет дубликатов, размывающих агрегаты.
- Валидность — данные соответствуют формату и допустимым значениям.
Где обычно ломается
- Изменения в продуктовой схеме без уведомления аналитиков.
- Ручной ввод и опечатки в важных полях.
- Расхождение часовых поясов и форматов дат.
- Скрытые удаления и обновления, которые не попадают в аналитический пайплайн.
Когда применять и когда нет
Применять
- Перед запуском новой витрины или модели
- В регулярных проверках в пайплайнах данных
- При расследовании расхождений между отчётами разных команд
Не применять
- Не существует — игнорирование качества данных всегда оборачивается дороже, чем работа над ним
Примеры применения
Финансовый отчёт показывает странное падение выручки. Через час расследования выясняется, что новый разработчик переименовал поле в продуктовой базе, и пайплайн загрузки тихо начал писать в него NULL. Тесты на полноту в загрузках поймали бы это в момент запуска, но их не было. После инцидента команда добавила автоматические проверки уровня «доля NULL не выше X», и подобный сценарий теперь обнаруживается за минуты, а не за часы.
Часто задаваемые вопросы
В идеале — общая модель: продуктовые команды отвечают за качество своих источников, дата-инженеры — за качество пайплайнов, аналитики — за качество витрин и отчётов. В реальности часто всё это сваливается на одну команду, и это плохо масштабируется. Лучше разделять ответственность письменно и публично.
Это направление инструментов и практик, которое автоматизирует мониторинг качества данных: следит за свежестью таблиц, объёмами, схемой, статистическими распределениями. Известные продукты в этой области — Monte Carlo, Bigeye, открытый Soda и другие. По смыслу это «мониторинг для данных», аналог observability в инфраструктуре.