Data quality monitoring (schema, nulls, drift)

Автоматизация непрерывно контролирует качество данных в data warehouse и выявляет отклонения до того, как они попадут в отчёты и дашборды. Проверки запускаются по расписанию или по событию загрузки, а результаты оформляются как алерты с детализацией — какая таблица и какое правило нарушились.

Что происходит в процессе

1. Инвентаризация критичных таблиц. Команда описывает, какие датасеты в warehouse критичны для отчётности и операционных решений, фиксирует владельцев данных.
2. Формализация ожиданий. Для каждой таблицы записываются три группы правил: ожидаемая схема (список колонок и их типы), допустимая доля NULL по колонкам, диапазон значений ключевых метрик.
3. Снятие исторического baseline. Для drift-проверок система рассчитывает статистические характеристики (среднее, медиана, доли категорий) на окне последних N дней.
4. Проверка при каждой новой загрузке. При появлении инкремента данных запускается набор тестов: схема не изменилась, NULL в рамках порога, распределение значений не ушло относительно baseline.
5. Алертинг с контекстом. При срабатывании правила в Slack или email уходит сообщение с названием таблицы, колонкой, нарушенным правилом, фактическим значением и ссылкой на runbook.
6. Логирование истории. Все запуски и результаты сохраняются в отдельной таблице для ретроспективы и отчётности по data-health.

Чего автоматизация не делает

1. Не исправляет данные автоматически. Система фиксирует факт отклонения, но ремедиацией (fix в ETL, откат загрузки, ручная правка) занимается data-инженер или владелец таблицы.
2. Не заменяет unit-тесты пайплайнов. Монитор работает по результату — с данными, которые уже оказались в warehouse. Логика трансформаций тестируется отдельно в CI/CD.
3. Не формирует бизнес-правила сама. Пороги NULL, допустимые диапазоны, чувствительность к дрейфу определяет команда — автоматизация исполняет эти правила, не решая, какими они должны быть.

Технически решение состоит из четырёх слоёв: хранилище правил, раннер проверок, интеграция с data warehouse и канал алертов. Реализация — custom-code (Python + SQL), без привязки к конкретному SaaS-инструменту.

Архитектура

1. Правила в коде или YAML. Каждое правило описывается декларативно: таблица, колонка, тип проверки (schema / null / drift), параметры (порог, окно baseline). Правила хранятся в git — изменения проходят через обычный code review.
2. Раннер проверок. Планировщик (cron, Airflow, Dagster, dbt — по выбору команды) запускает раннер после каждой загрузки или по расписанию. Раннер читает правила, формирует SQL-запросы к warehouse, сравнивает результат с ожиданиями.
3. Подключение к warehouse. Раннер ходит в data warehouse через нативный SQL-коннектор и выполняет агрегации на стороне БД — чтобы не выкачивать миллионы строк в приложение.
4. Алерты и дашборд. Нарушения отправляются в Slack или email. История запусков пишется в отдельную таблицу warehouse, поверх которой строится дашборд data-health.

Типичные варианты настройки

Шаги внедрения

1. Аудит критичных датасетов (1 неделя). С аналитиками и data-инженерами фиксируется список таблиц, от которых зависят ключевые дашборды и метрики.
2. Описание правил для первой волны (1–2 недели). Для 5–10 самых важных таблиц формализуются schema, NULL-пороги и drift-чеки. Начинается с консервативных порогов.
3. Настройка раннера и интеграций (1–2 недели). Раннер разворачивается в существующем оркестраторе, подключается к warehouse и к каналу алертов.
4. Baseline и калибровка (1–2 недели). Система работает в «тихом» режиме: фиксирует срабатывания, но не шлёт алерты. Команда корректирует пороги на основе фактических данных, чтобы исключить ложные срабатывания.
5. Перевод в продакшен. Алерты включаются, к каждому типу проверки добавляется runbook, фиксируются владельцы таблиц.

Альтернативные подходы

Вместо custom-code доступны готовые инструменты — Great Expectations, Soda Core, dbt tests, а также коммерческие observability-платформы. Custom-code оправдан, когда важны контроль над логикой правил, отсутствие vendor lock-in и интеграция с уже существующим оркестратором. Готовые решения быстрее стартуют, но добавляют стоимость и ограничения по кастомизации.

Безопасность и compliance

Раннер работает с service-аккаунтом warehouse на read-only правах — мониторинг не модифицирует данные. Правила в git проходят code review как любой другой код. Результаты проверок содержат только агрегированные значения (счётчики, средние), без выборок сырых строк — что снижает риски при работе с чувствительными датасетами.

Для запуска мониторинга нужны три вещи: доступ к data warehouse, базовая оркестрация и список критичных таблиц с владельцами.

Данные и доступы

• Data warehouse (Snowflake, BigQuery, Redshift, PostgreSQL или аналог) с возможностью выполнять SQL-агрегации на стороне БД.
• Service-аккаунт с read-only правами на целевые таблицы и write-правами на служебную схему для истории запусков.
• Канал алертов: Slack-workspace с возможностью создать incoming webhook либо SMTP-доступ для email.

Инфраструктура

• Оркестратор, в котором будут запускаться проверки: Airflow, Dagster, dbt Cloud/Core, GitHub Actions или cron на выделенной машине.
• Git-репозиторий для хранения правил и кода раннера.
• CI/CD-процесс для деплоя изменений в правилах.

Готовность команды

• Data-инженер или аналитик, способный писать SQL и работать с Python.
• Владельцы данных (data owners) по ключевым доменам — люди, которые принимают алерты и отвечают за ремедиацию.
• Согласованный формат алертов и канал их доставки.

Организационные предпосылки

• Список первых 5–10 критичных таблиц для мониторинга — разумно начать с узкого scope и расширять.
• Runbook-шаблон: что делать при каждом типе срабатывания (schema change, рост NULL, drift).

Сроки

Полное внедрение занимает 6–10 недель для medium-complexity кейса: 1–2 недели на аудит и согласование scope, 2–3 недели на настройку и первую волну правил, ещё 2–3 недели на калибровку baseline и переход в продакшен. Точный срок зависит от зрелости data-платформы и количества таблиц на первой итерации.