Моніторинг якості даних (схема, нульові значення, дрейф)

Автоматизація безперервно контролює якість даних у сховищі даних і виявляє відхилення до того, як вони потраплять у звіти та дашборди.

Перевірки запускаються за розкладом або за подією завантаження, а результати оформлюються як алерти з деталізацією — яка таблиця та яке правило порушилися.

Що відбувається в процесі

1. Інвентаризація критичних таблиць. Команда описує, які набори даних у сховищі критичні для звітності та операційних рішень, фіксує власників даних.
2. Формалізація очікувань. Для кожної таблиці записуються три групи правил: очікувана схема (список колонок та їхні типи), допустима частка NULL по колонках, діапазон значень ключових метрик.
3. Зняття історичної базової лінії. Для перевірок дрейфу система розраховує статистичні характеристики (середнє, медіана, частки категорій) на вікні останніх N днів.
4. Перевірка при кожному новому завантаженні. При появі інкременту даних запускається набір тестів: схема не змінилася, NULL у межах порогу, розподіл значень не відійшов відносно базової лінії.
5. Алертинг з контекстом. При спрацьовуванні правила у Slack або email надсилається повідомлення з назвою таблиці, колонкою, порушеним правилом, фактичним значенням та посиланням на сценарій реагування.
6. Логування історії. Всі запуски та результати зберігаються в окремій таблиці для ретроспективи та звітності щодо якості даних.

Чого автоматизація не робить

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

Технічно рішення складається з чотирьох шарів: сховище правил, раннер перевірок, інтеграція зі сховищем даних і канал алертів. Реалізація — власний код (Python + SQL), без прив'язки до конкретного SaaS-інструменту.

Архітектура

1. Правила в коді або YAML. Кожне правило описується декларативно: таблиця, колонка, тип перевірки (схема / null / дрейф), параметри (поріг, вікно базової лінії). Правила зберігаються в git — зміни проходять через звичайне рев'ю коду.
2. Раннер перевірок. Планувальник (cron, Airflow, Dagster, dbt — за вибором команди) запускає раннер після кожного завантаження або за розкладом. Раннер читає правила, формує SQL-запити до сховища, порівнює результат з очікуваннями.
3. Підключення до сховища даних. Раннер звертається до сховища даних через нативний SQL-конектор і виконує агрегації на стороні БД — щоб не викачувати мільйони рядків у застосунок.
4. Алерти та дашборд. Порушення надсилаються в Slack або email. Історія запусків записується в окрему таблицю сховища, поверх якої будується дашборд якості даних.

Типові варіанти налаштування

Кроки впровадження

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

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

Замість власного коду доступні готові інструменти — Great Expectations, Soda Core, dbt tests, а також комерційні платформи спостережуваності. Власний код виправданий, коли важливі контроль над логікою правил, відсутність прив'язки до постачальника та інтеграція з уже існуючим оркестратором. Готові рішення стартують швидше, але додають вартість і обмеження щодо кастомізації.

Безпека та відповідність вимогам

Раннер працює з сервісним акаунтом сховища з правами лише для читання — моніторинг не модифікує дані. Правила в git проходять рев'ю коду як будь-який інший код. Результати перевірок містять лише агреговані значення (лічильники, середні), без вибірок сирих рядків — що знижує ризики при роботі з чутливими датасетами.

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

Дані та доступи

• Сховище даних (Snowflake, BigQuery, Redshift, PostgreSQL або аналог) з можливістю виконувати SQL-агрегації на стороні БД.
• Сервісний акаунт з правами лише для читання на цільові таблиці та правами запису на службову схему для історії запусків.
• Канал алертів: Slack-workspace з можливістю створити вхідний вебхук або SMTP-доступ для email.

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

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

Готовність команди

• Дата-інженер або аналітик, здатний писати SQL та працювати з Python.
• Власники даних за ключовими доменами — люди, які приймають алерти та відповідають за ремедіацію.
• Узгоджений формат алертів та канал їх доставки.

Організаційні передумови

• Список перших 5–10 критичних таблиць для моніторингу — розумно почати з вузького обсягу і розширювати.
• Шаблон сценарію реагування: що робити при кожному типі спрацювання (зміна схеми, зростання NULL, дрейф).

Терміни

Повне впровадження займає 6–10 тижнів для кейсів середньої складності: 1–2 тижні на аудит та узгодження обсягу, 2–3 тижні на налаштування та першу хвилю правил, ще 2–3 тижні на калібрування базової лінії і перехід у продакшн. Точний термін залежить від зрілості дата-платформи та кількості таблиць на першій ітерації.