15 апреля 2026 г.

Качество данных для аналитика

Что такое Data Quality

Data Quality (качество данных) — совокупность характеристик, определяющих пригодность данных для задачи.

«Плохие данные» → «плохие решения». Для аналитика качество данных — критически важно.

Шесть измерений качества

1. Completeness (полнота)

Все ли данные присутствуют?

SELECT COUNT(*) FILTER (WHERE email IS NULL) * 100.0 / COUNT(*) FROM users;

2. Accuracy (точность)

Соответствуют реальности?

Пример: если revenue в БД не сходится с банковской выпиской — accuracy проблема.

3. Consistency (консистентность)

Данные в разных местах согласованы?

  • orders.user_id ссылается на существующего users.user_id?
  • Сумма в dashboard = сумма в raw events?

4. Timeliness (своевременность)

Данные свежие?

  • ETL обновляется вовремя?
  • Last timestamp недавний?

5. Validity (валидность)

Значения в допустимом формате?

  • Email — валидный?
  • Amount — положительный?
  • Status — из списка?

6. Uniqueness (уникальность)

Нет дубликатов там, где не должно быть?

  • PK уникален?
  • Нет duplicate events?

Метрики качества данных

Null Rate

SELECT column_name, null_rate FROM (
    SELECT 'email' AS column_name,
           COUNT(*) FILTER (WHERE email IS NULL) * 100.0 / COUNT(*) AS null_rate
    FROM users
);

Мониторьте каждую важную колонку.

Duplicate Rate

SELECT COUNT(*) - COUNT(DISTINCT email) AS dups FROM users;

Freshness

SELECT EXTRACT(EPOCH FROM (NOW() - MAX(created_at))) / 3600 AS hours_lag
FROM events;

Schema conformance

# Проверка типов
assert df['amount'].dtype == 'float64'
assert df['created_at'].dtype.name.startswith('datetime')

Попробовать силы на подобных вопросах проще всего в тренажёре Карьерник — прямо в Telegram, без регистрации через сайт.

Причины плохих данных

1. Трекинг сломан

Релиз приложения удалил event, pipeline ничего не логирует.

Решение: мониторинг event counts, алерты при резком изменении.

2. ETL глючит

Джоба упала, данные не обновились.

Решение: alerting в Airflow, retry logic.

3. Изменение источника

Добавилась колонка, изменился формат.

Решение: schema contracts, dbt tests.

4. Human error

Кто-то вручную изменил данные в production.

Решение: audit logs, read-only доступ к raw data.

5. Bots / spam

Накрутка событий ботами.

Решение: фильтрация, rate limiting, bot detection.

Best Practices

1. Принцип «Shift Left»

Проверяйте качество как можно раньше — на этапе ETL, а не когда уже в dashboard.

2. Documented schema

Каждая таблица должна иметь:

  • Описание.
  • Назначение каждой колонки.
  • Ожидаемые типы и диапазоны.
  • Primary Key, Foreign Keys.

3. Automated tests

-- dbt test
- unique
- not_null
- accepted_values
- relationships

Запускать при каждом pipeline run.

4. Observability

Dashboard «Health of Data»:

  • % NULL по колонкам.
  • Lag по таблицам.
  • Duplicate rate.
  • Volume (total rows per day).

5. Alerts

Slack/email при:

  • NULL rate > threshold.
  • Lag > expected.
  • Сильный скачок / падение volume.

6. Data Contracts

Formal договор между data producer (backend team) и consumer (analytics):

  • Schema не меняется без notification.
  • SLA latency.
  • Тесты валидности.

Roles и ownership

Data Engineer

Pipeline, ETL, infrastructure.

Analytics Engineer

dbt models, tests, documentation.

Analyst

Business logic, specific metrics validation.

Data Steward

Governance, policies.

В маленьких компаниях все эти роли смешиваются.

Инструменты

Testing

  • dbt tests — в рамках dbt pipeline.
  • Great Expectations — standalone.
  • Soda Core — yaml-based.
  • Deequ (Amazon) — Spark-based.

Monitoring

  • Monte Carlo — commercial, data observability.
  • Datafold — data diff для review PR.
  • Custom Grafana dashboards — на своих данных.

Catalogs

  • Atlan / Alation — enterprise catalog.
  • DataHub (LinkedIn) — open-source.
  • Amundsen (Lyft) — open-source.

Пройти 30–50 задач по теме за вечер можно в Telegram-тренажёре. Это то, что отличает «знаю» от «уверенно отвечу на собесе».

Metric для дашборда Data Quality

Data Health Score = weighted sum of:
  - 30% Null rate acceptance
  - 20% Freshness (lag < expected)
  - 20% Duplicate rate
  - 15% Schema conformance
  - 15% Business rules validity

Стремимся к 95%+ каждый день.

Что делать при обнаружении проблемы

Immediate

  1. Alert в Slack.
  2. Отметить в dashboard, что данные подозрительны.
  3. Не использовать для критичных решений.

Investigation

  1. Откуда проблема? (источник, ETL, pipeline).
  2. Насколько распространена? (одна колонка или все).
  3. С какого времени?

Fix

  1. Исправить источник проблемы.
  2. Backfill корректных данных.
  3. Notify stakeholders (что и когда исправили).

Post-mortem

  1. Почему не поймали раньше?
  2. Какие проверки добавить?
  3. Update runbook.

Читайте также

FAQ

Сколько времени уходит на data quality?

20–30% времени аналитика. В больших компаниях есть отдельные команды.

Кто отвечает?

Совместная ответственность: DE за pipeline, аналитик — за бизнес-правила.

Как убедить бизнес инвестировать в DQ?

Показать цену инцидентов: сколько было ошибочных решений из-за bad data. Один big wrong decision > год работы DQ-команды.

Что важнее — DQ или speed?

В стартапе speed > DQ. В enterprise DQ > speed. Баланс зависит от ценой ошибок.

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