О качестве данных говорят все, но на вопрос «насколько хороши ваши данные?» редко отвечают цифрами. Пока качество не измеряется, улучшать его можно только на ощущениях, а ошибки обнаруживаются уже в отчётах, у клиентов или на совещаниях.
Какие бывают измерения качества
| Измерение | О чём оно | Пример проверки |
|---|---|---|
| Полнота | Заполнены ли обязательные поля | В каждой записи клиента есть контакт |
| Уникальность | Нет ли дублей | Один контрагент не встречается дважды с разными названиями |
| Согласованность | Совпадают ли данные в разных системах | Остатки на складе в учётной системе и в отчёте равны |
| Актуальность | Насколько свежие данные | Загрузка прошла сегодня до заданного времени |
| Валидность | Подходят ли значения под правила | Дата отгрузки не раньше даты заказа, сумма не отрицательная |
| Точность | Соответствуют ли данные реальности | Выборочная сверка с первичными документами |
Как измерять
Для каждого критичного набора данных задаются правила и пороги. Например: «доля записей без контакта не больше допустимого значения» или «загрузка завершается не позже 7 утра». Результаты проверок собираются на панели: видно, какие правила нарушены, как давно и как изменилась ситуация.
Где проверять
- На входе. При загрузке из источника: данные не принимаются или помечаются, если нарушены базовые правила.
- При обработке. После преобразований: проверяется, что итоги сходятся с исходными данными.
- На выходе. В витринах и отчётах: ключевые показатели сопоставляются с эталонными значениями.
Разовая чистка и постоянный процесс
Типичная ошибка: один раз почистить данные и считать вопрос закрытым. Через несколько месяцев те же ошибки возвращаются, потому что причины остались: ввод вручную, изменения в источниках, сбои загрузок. Рабочий подход состоит из трёх частей: правила и проверки, ответственные за данные и процесс исправления причин, а не только последствий.
Data Observability: контроль здоровья данных
Качество содержимого это одна часть, а состояние самих потоков данных другая. Её называют Data Observability. Она отвечает на вопросы:
- Пришли ли данные вовремя?
- Не изменился ли объём загрузки резко?
- Не поменялась ли структура источника?
- Нет ли аномалий в значениях?
- Откуда пришёл показатель и через какие преобразования прошёл?
Цель в том, чтобы о проблеме узнавал ответственный, а не пользователь отчёта.
Что делать при обнаружении ошибки
- Зафиксировать. Что произошло, где и когда обнаружено.
- Оценить влияние. Какие отчёты и решения затронуты.
- Предупредить пользователей. Чтобы они не принимали решения по неверным цифрам.
- Исправить причину в источнике. Не «подправить в отчёте», а убрать причину ошибки.
- Пересчитать данные. Восстановить корректную историю.
- Усилить проверку. Добавить правило, которое поймает такую ошибку в будущем.
Типичные ошибки
- Исправлять данные в отчётах вместо источников.
- Не назначить владельца: проблему видят все, а решает никто.
- Писать слишком много правил: часть из них игнорируется, и важные оповещения тонут.
- Не показывать пользователям состояние данных: им приходится верить на слово.
Частые вопросы
С чего начать, если данных много? С нескольких критичных наборов, от которых зависят управленческие решения. Для них задайте правила, настройте проверки и покажите результаты на панели.
Нужна ли для этого отдельная система? Начать можно в существующих инструментах загрузки и BI. Специализированные системы нужны, когда масштаб вырос.
Как понять, что качество стало лучше? По динамике показателей на панели: доля данных, прошедших проверки, число инцидентов, время на их исправление.
Что дальше
Как мы выстраиваем контроль качества и наблюдаемость данных, описано на странице Управление данными и качество, а загрузку с проверками и оповещениями мы строим в рамках Инжиниринга данных. Расскажите о своей задаче, если хотите обсудить качество данных в вашей компании.
