Freshness и Data Observability

Введение

Все предыдущие уроки модуля решали задачу “данные корректны?”. Но есть ещё один критический вопрос: “данные актуальны?”. Data Observability (наблюдаемость данных) — это способность в реальном времени понимать состояние данных и data pipeline. В этом уроке мы разберём freshness SLA, пять столпов observability, incident response и связь с CDC-системами.

Freshness: актуальность данных

Timeliness (своевременность) — одно из шести измерений качества. Freshness — его операционная метрика: сколько времени прошло с момента последнего обновления данных.

from datetime import datetime, timezone

def check_freshness(table_name, last_updated, sla_hours, reference_time):
    """Проверить freshness таблицы против SLA."""
    age = reference_time - last_updated
    age_hours = age.total_seconds() / 3600
    sla_ratio = age_hours / sla_hours

    if sla_ratio <= 1.0:
        status = "fresh"
    elif sla_ratio <= 2.0:
        status = "stale"
    else:
        status = "critical"

    return {
        "table": table_name,
        "status": status,
        "age_hours": round(age_hours, 1),
        "sla_hours": sla_hours,
        "sla_ratio": round(sla_ratio, 2)
    }

Пять столпов Data Observability

По аналогии с observability в DevOps (logs, metrics, traces), Data Observability определяет пять столпов:

# Мониторинг volume anomalies
def check_volume(table_name, current_count, expected_range):
    """Проверить, что количество записей в ожидаемом диапазоне."""
    min_expected, max_expected = expected_range
    if current_count < min_expected:
        return {"table": table_name, "status": "anomaly_low", "count": current_count}
    elif current_count > max_expected:
        return {"table": table_name, "status": "anomaly_high", "count": current_count}
    return {"table": table_name, "status": "normal", "count": current_count}

Hands-On Lab: Quality Lab

Practice these concepts with an intentionally dirty dataset and Great Expectations:

cd labs/quality && cp .env.example .env && docker compose up -d --build

Open JupyterLab at http://localhost:28888 and complete Notebook 04: Data Docs and Remediation — generate GE Data Docs, analyze validation results, and practice data remediation strategies.

Requirements: Docker Desktop with 4+ GB RAM allocated. See labs/quality/README.md for full setup.

Data Observability Dashboard

Incident Response Playbook

Когда observability обнаруживает проблему, нужен playbook — пошаговый план реагирования:

Уровни severity

Playbook для P1 Freshness Incident

1. DETECT  -- алерт из observability системы
2. TRIAGE  -- определить scope: какие downstream дашборды/модели затронуты
3. DIAGNOSE -- проверить pipeline:
   - Airflow DAG status (success/fail/running?)
   - Source system availability (PostgreSQL up?)
   - ETL logs (error messages?)
4. RESOLVE  -- исправить причину:
   - Retry failed DAG run
   - Fix connection issue
   - Manual data backfill if needed
5. VERIFY  -- подтвердить восстановление:
   - Freshness SLA restored
   - Volume within expected range
   - Downstream models updated
6. POSTMORTEM -- после инцидента:
   - Root cause analysis
   - Preventive measures
   - Update monitoring thresholds

Связь с CDC и Debezium

Традиционный ETL обновляет данные батчами (раз в сутки), что создаёт inherent freshness lag. CDC (Change Data Capture) решает эту проблему, доставляя изменения в near-real-time.

Debezium CDC позволяет мониторить freshness в реальном времени: каждое изменение в PostgreSQL мгновенно отправляется в Kafka, и downstream системы обновляются в течение секунд, а не часов. Подробнее о streaming data quality patterns: Мониторинг качества потоковых данных

С CDC freshness SLA для критических таблиц можно снизить с 24 часов до минут — но это создаёт новые observability-вызовы: мониторинг consumer lag, connector health, schema evolution.

Сценарий: ДатаТех и БиоГенезис

Сценарий: DataTech Solutions (ДатаТех Солюшенз)

Понедельник утром: VP Sales открывает дашборд Revenue и видит данные за пятницу. ClickHouse не обновлялся 48 часов — Airflow DAG упал в субботу, алерта никто не получил.

Root cause: DAG load_orders_to_clickhouse зависит от PostgreSQL connection, которая была прервана из-за maintenance window (суббота 03:00). DAG retry policy: 0 retries (по умолчанию). Нет мониторинга freshness.

Preventive measures:

1. Добавить freshness SLA: orders не более 4 часов, customers не более 24 часов
2. DAG retry policy: 3 retries с exponential backoff
3. Slack-алерт при нарушении SLA
4. Рассмотреть CDC (Debezium) для near-real-time обновлений

Для сравнения: BioGenesis Lab (БиоГенезис Лаб)

Freshness для клинических данных — вопрос безопасности пациентов. Если результаты анализа крови доставляются с задержкой более 4 часов, врач может назначить неактуальное лечение. BioGenesis определяет SLA: clinical_results не более 2 часов, genomic_data не более 24 часов, research_data не более 72 часов. Нарушение SLA для clinical_results — P1 incident с немедленной эскалацией.

Итоги

• Freshness — операционная метрика Timeliness: время с последнего обновления vs SLA
• Data Observability — пять столпов: freshness, volume, schema, distribution, lineage
• Incident Response Playbook — пошаговый план: detect, triage, diagnose, resolve, verify, postmortem
• CDC (Debezium) снижает freshness lag с часов до секунд, но создаёт новые observability-вызовы
• Severity уровни (P1-P4) определяют response time и процедуру эскалации
• BioGenesis: freshness SLA для clinical data — вопрос безопасности пациентов

Freshness monitoring обнаруживает, когда данные устаревают. Но что происходит, когда данные больше не нужны? Retention (хранение), Archiving (архивирование) и Disposal (уничтожение) — три этапа жизненного цикла данных после их активного использования. FinSecure обязан хранить финансовые данные 7 лет, но GDPR требует удаления персональных данных по запросу. В следующем уроке мы изучим governance этих процессов: от проектирования retention-политик до безопасного уничтожения данных.

Этот урок завершает основную часть модуля Data Quality & Observability. Вы изучили все шесть измерений качества, научились обнаруживать и устранять нарушения, автоматизировать тесты с dbt и Great Expectations, и построить систему observability для непрерывного мониторинга здоровья данных. Далее — retention, archiving и disposal, а затем мы перейдём к M05: Приватность и Compliance.