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-платформи та кількості таблиць на першій ітерації.