Сообщить об ошибкеКороткий ответ
Минимум два типа проверок — свежесть (данные за вчерашний день реально загружены к ожидаемому времени) и полнота (объём загруженных строк не аномально отличается от обычного объёма за день), с алертом в Slack/почту при нарушении порога.
Как это работает подробнее
Проверка свежести сравнивает MAX(loaded_at) или наличие строк с вчерашней датой с текущим временем и ожидаемым SLA пайплайна (например, «данные за вчера должны быть к 8:00»); проверка полноты сравнивает COUNT(*) за последний день с историческим средним/медианой за последние N дней с допустимым отклонением (например, ±30%).
Пример кода
example.sql
WITH daily_counts AS (
SELECT order_date, COUNT(*) AS cnt
FROM fact_orders
WHERE order_date >= CURRENT_DATE - 30
GROUP BY order_date
),
stats AS (
SELECT AVG(cnt) AS avg_cnt, STDDEV(cnt) AS sd_cnt
FROM daily_counts WHERE order_date < CURRENT_DATE - 1
)
SELECT d.order_date, d.cnt, s.avg_cnt
FROM daily_counts d, stats s
WHERE d.order_date = CURRENT_DATE - 1
AND ABS(d.cnt - s.avg_cnt) > 2 * s.sd_cnt;Что использовать на практике
- На практике. Пороги отклонения лучше не брать «с потолка», а откалибровать по историческому разбросу объёма данных (учитывая день недели — выходные обычно отличаются от будней), и разделять алерты на «warning» (небольшое отклонение, можно разобраться в рабочее время) и «critical» (данных нет вообще, нужно реагировать немедленно).
- Проверка. запрос, возвращающий строки, сигнализирует об аномальном объёме за вчера (более 2 стандартных отклонений от среднего) — это и есть условие срабатывания алерта.
Подводные камни
- Частые ошибки. Ставят фиксированный порог без учёта сезонности/дня недели, из-за чего мониторинг постоянно шумит в понедельник или перед праздниками и команда начинает его игнорировать; либо мониторят только факт запуска пайплайна («джоб завершился успешно»), не проверяя фактический объём и качество загруженных данных.