Как проверяешь качество поступающих данных?

Как проверяешь качество поступающих данных

Качество данных — это основа качества продукта. Плохие данные приводят к неправильным решениям, потере доверия пользователей и финансовым потерям. Вот комплексный подход к проверке качества данных.

Определение качества данных

Данные качественные, если они:

• Полные (completeness) — нет пропущенных значений в критичных полях
• Точные (accuracy) — соответствуют реальности
• Консистентные (consistency) — нет противоречий и дубликатов
• Актуальные (timeliness) — не устаревают и своевременно обновляются
• Действительные (validity) — соответствуют предусмотренному формату и диапазону
• Уникальные (uniqueness) — нет нежелательных дубликатов

Методы проверки на входе (Data Validation)

1. Уровень приложения

• Типизация данных: int, string, date, enum
• Диапазоны: число от 0 до 100, дата не раньше сегодня
• Форматы: email, phone, IP-адрес используют regex
• Обязательные поля: помечаются как required
• Нормализация: приведение к единому формату (trim, lowercase)

2. Уровень БД (constraints)

CREATE TABLE users (
    id UUID PRIMARY KEY,
    email VARCHAR(255) NOT NULL UNIQUE,
    age INT CHECK (age >= 18),
    created_at TIMESTAMP NOT NULL DEFAULT NOW(),
    status VARCHAR(20) CHECK (status IN ('active', 'inactive'))
);

3. Бизнес-логика (Business Rules)

• Возраст должен быть реалистичным (18-120 лет)
• Дата доставки не может быть раньше даты заказа
• Сумма скидок не может быть больше суммы заказа
• Пользователь не может быть в двух статусах одновременно

Проверка в процессе работы

1. Мониторинг и аналитика

• Сколько валидных записей входит в день?
• Какой процент от них имеет пропущенные поля?
• Какие поля чаще всего содержат ошибки?
• Есть ли аномалии в распределении значений?

2. Дашборды качества данных

• Процент полноты данных по полям
• Количество дубликатов
• Тренд ошибок по времени
• Источники некачественных данных

3. Алерты на аномалии

• Если в день пришло < 100 записей (вместо обычных 1000) — alert
• Если появилось > 10% записей с пропущенным email — alert
• Если возраст имеет значение 999 — alert

Проверка данных от внешних источников

Если данные приходят из внешних API, файлов, интеграций:

1. Тестирование на стейджинге

• Запустить интеграцию на песочнице
• Импортировать тестовый набор данных
• Проверить, как система обработает некорректные данные

2. Договориться о формате

• Документировать схему данных (JSON schema, XSD)
• Указать обязательные и опциональные поля
• Привести примеры корректных и некорректных значений

3. Согласование с источником

• Кто отвечает за качество на их стороне?
• Как часто они обновляют данные?
• Что делать при обнаружении ошибок?

Практический пример: интеграция с системой CRM

Приходят данные о клиентах:

name: "John Doe"
email: "invalid-email"
phone: "+1-234-567-8900"
age: "-5"
status: "VIP" (ожидаем только active/inactive)

Чтобы проверить:

1. На входе: валидация email, телефона, возраста
2. Обработка: нормализация телефона в единый формат
3. Логирование: записать в лог ошибки валидации
4. Действие: либо отклонить запись, либо указать на ошибку отправителю
5. Мониторинг: добавить алерт на такие ошибки

Инструменты для проверки качества

• Python: pandas (profiling), Great Expectations (data validation framework)
• SQL: запросы для поиска пропусков, дубликатов, аномалий
• BI инструменты: Tableau, Power BI (визуализация качества)
• Специализированные: Talend, Informatica (ETL с валидацией)
• Opensource: Apache Griffin, Apache NiFi

Работа с грязными данными (Data Cleaning)

Если данные уже испорчены:

1. Идентифицировать источник проблемы
2. Оценить масштаб (10 записей или 10 миллионов?)
3. Решить: удалить, исправить или заполнить значением по умолчанию
4. Написать миграцию для очистки
5. Добавить проверку, чтобы это не повторилось

Красные флаги при работе с данными

• Много пропусков (NULL значений) в критичных полях
• Одинаковые значения в большинстве записей (признак baggy data)
• Значения выходят за разумные границы
• Разные форматы одного типа данных (8/15/2023 и 08-15-23)
• Невозможно связать данные между таблицами (нарушена целостность)

Золотое правило: garbage in — garbage out. Если на входе грязные данные, никакой BA не спасёт результат. Поэтому контроль качества на входе — это инвестиция в качество всего продукта.