Мониторинг и data quality на собеседовании Data Engineer

Зачем data quality на собесе DE

ETL работает → данные в DWH есть → менеджер видит дашборд. Но цифры на дашборде неправильные: трекинг сломался, fact-таблица пропустила 30% событий, схема изменилась. Senior DE на собесе должен показать, что мониторинг — часть архитектуры, а не отдельная задача.

На собесе Data Engineer data quality спрашивают через сценарии: «как заметишь, что данные сломаны». Слабый ответ — «PM скажет». Сильный — «freshness alerts, row count anomaly, schema drift, бизнес-метрики SLO».

Основные категории data quality

Стандарт 6 dimensions (DAMA):

Completeness — нет пропусков (null где не должны быть)
Uniqueness — нет дубликатов в PK
Validity — данные в правильном формате (email = email, не строка)
Accuracy — соответствие реальности (revenue в DWH = revenue в source)
Consistency — нет противоречий (sum по сегментам = total)
Timeliness — данные свежие (last load < SLA)

Каждое — отдельная проверка в pipeline.

Подробнее — как посчитать data completeness в SQL, как посчитать data uniqueness в SQL.

Freshness monitoring

Самая базовая проверка: данные свежие?

SELECT
    MAX(updated_at) AS last_update,
    NOW() - MAX(updated_at) AS staleness
FROM fact_orders;

Алерт: staleness > SLA (например, > 2 часа) → PagerDuty / Slack.

Best practices:

Per-table SLA
Сегментация: dashboard-critical таблицы → strict SLA (1h), nice-to-have → loose (24h)
Аномалия не только high, но и low (если pipeline остановился — нет updates)

Подробнее — как посчитать data staleness в SQL.

Volume / row count anomaly

Каждый день в fact_orders приходит ~10M строк. Сегодня пришло 1M — что-то сломалось.

SELECT
    DATE_TRUNC('day', created_at) AS day,
    COUNT(*) AS rows_inserted
FROM fact_orders
GROUP BY 1
ORDER BY 1 DESC;

Anomaly detection:

Z-score: > 3σ от rolling baseline → alert
Day-of-week adjustment (выходные ≠ будни)
Seasonal adjustment для retail / e-com

Подробнее — как посчитать data volume anomaly в SQL.

Schema drift

В source появилась новая колонка / тип изменился. Pipeline должен это заметить.

Tools:

dbt контрактует schema через version: 2 YAML
Great Expectations / Soda Core — checks на типы и кардинальность
Custom: hash от information_schema.columns сравнить вчерашний vs сегодняшний

Стратегия:

Detect → alert → halt pipeline → human review
Иногда auto-add column в DWH (для permissive datasets)

Great Expectations / Soda Core

Самые популярные frameworks для data quality.

Great Expectations:

Декларативные expectations: expect_column_values_to_not_be_null, expect_column_values_to_be_unique
Profiling: автоматическая инициация набора expectations
Data Docs: HTML-репорт о quality

Soda Core:

YAML-конфиг
SQL-based проверки
Integration с Slack, PagerDuty

dbt tests: простой baseline (см. dbt-i-modelirovanie).

Distribution drift

Не только schema, но и значения могут «дрейфовать».

Что трекать:

Среднее / медиана числовых колонок
Cardinality категориальных
% null
Top-N значений категориальных

Methods:

PSI (Population Stability Index)
KS-тест на распределения
Chi-square для категориальных

Подробнее — как посчитать distribution drift в SQL.

Бизнес-метрики SLO

Помимо технических проверок — бизнес-логические:

Sum revenue в fact_orders должен равняться sum revenue в source
Total user count должен расти, не падать
Day-over-day conversion не должен прыгать на 50%

Подход:

Список «golden metrics» — критичные бизнес-показатели
Alerts на anomaly в этих метриках, не только в источниках

Observability платформы

Monte Carlo: end-to-end data observability. Auto-discovery, lineage, anomaly detection. Платная.

Datafold: data diff между прод и dev таблицами. Также lineage.

OpenLineage: open standard для lineage. Интеграция с Airflow, dbt, Spark.

Marquez: OpenLineage reference implementation.

Типичные вопросы

«Pipeline crash → alert. Что делаешь?»

Триаж: какие таблицы affected, downstream impact (BI / ML).
Уведомить stakeholders (заранее, чтобы менеджер не строил решения на пропущенных данных).
Root cause: source изменился? Pipeline error? Schema drift?
Fix → backfill (если данные потерялись).
Post-mortem: что добавим в мониторинг, чтобы не повторилось.

«Как настраиваешь SLA?»

Per-table, на основе downstream consumers. Dashboard-critical → 1h. Ad-hoc analytics → 24h. ML re-training → weekly. SLA — это контракт с consumers.

«Откуда узнать, что трекинг сломан?»

Volume anomaly (event count резко упал), distribution drift (доли event_types изменились), foreign key violations (user_id из event не существует в users). Триггеры в Looker/Tableau на ключевые метрики.

«dbt tests vs Great Expectations?»

dbt — простые проверки внутри SQL-моделей. Great Expectations — внешний layer, более expressive. На современном стеке часто оба.

Частые ошибки

Только manual checks. «Я смотрю дашборд раз в неделю» — не работает на масштабе
Alerts без SLA. «Если ETL упадёт — PagerDuty» — слишком грубо. Нужны levels
Игнор schema drift. Source-команда добавила колонку → pipeline ломается через неделю
Без бизнес-проверок. Технически OK, бизнес-метрики разваливаются — провал
Все таблицы — один SLA. Critical и nice-to-have смешаны → alert fatigue

FAQ

Кто настраивает мониторинг — DE или Analytics?

DE отвечает за инфраструктуру, analytics — за бизнес-метрики. Совместная работа.

Open-source или платные tools?

Small/medium scale — open-source (Great Expectations + Airflow). Enterprise → Monte Carlo, Anomalo, BigEye.

dbt тестов достаточно?

Для базовых — да. Для distribution drift / бизнес-anomaly — нужны дополнительные tools.

Anomaly detection на DWH таблицах?

Custom SQL + cron, или specialized tool (Monte Carlo). В small команде — SQL + Airflow alerts.

Что в post-mortem?

Что упало, blast radius, root cause, what's added к мониторингу, action items с owners.

Смотрите также

Тренироваться в Telegram