Streaming Data Governance

Введение

В пакетном мире метаданные обновляются ежедневно. В streaming мире — ежесекундно.

Сценарий: FinSecure Bank (ФинСекьюр Банк)

FinSecure обрабатывает платежи через 200+ Kafka-топиков. 50+ consumer groups потребляют данные в реальном времени. На прошлой неделе producer-команда платежного шлюза изменила схему payment_events: поле amount стало строкой вместо числа. 12 consumer-сервисов упали с ошибками десериализации. Причина: никто не управлял совместимостью схем.

Streaming governance — это governance метаданных, качества и доступа в потоковых системах. В отличие от batch-governance, здесь всё происходит в реальном времени: схемы эволюционируют при каждом деплое, потребители подключаются динамически, lineage охватывает десятки микросервисов.

В этом уроке мы рассмотрим governance schema registry, streaming quality enforcement, topic governance, streaming lineage и CDC governance. Предварительно рекомендуем повторить урок 04 (Data Lineage) этого модуля.

Schema Registry Governance

Producer хочет изменить схему
  -> Pull Request в schema-repo
    -> Automated compatibility check (CI)
      -> Review: Schema Owner + affected consumers
        -> Merge -> Schema Registry update
          -> Consumer teams notified

Stream Quality Enforcement

В batch-системе качество проверяется после загрузки (dbt tests, Great Expectations). В streaming-системе качество должно проверяться на входе — до того, как невалидное событие попадёт в топик.

Три уровня валидации

# Трёхуровневая валидация streaming-событий
VALIDATION_LEVELS = {
    "schema": {
        "check": "Schema Registry валидация",
        "action": "Reject событие",
        "example": "Поле 'amount' отсутствует или неверный тип"
    },
    "business_rules": {
        "check": "Бизнес-правила на producer",
        "action": "Route в Dead Letter Queue (DLQ)",
        "example": "amount < 0, customer_id не найден в справочнике"
    },
    "statistical": {
        "check": "Anomaly detection на consumer",
        "action": "Алерт + logging",
        "example": "Среднее значение amount за 5 мин отклонилось на 3 sigma"
    }
}

Dead Letter Queue (DLQ) для quality failures

DLQ — специальный Kafka-топик для событий, не прошедших валидацию:

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

DataTech планирует streaming-архитектуру для e-commerce событий. Команда задаёт вопрос: как строить quality с нуля? Ответ: (1) Schema Registry с FULL compatibility, (2) Producer-side validation для бизнес-правил, (3) DLQ для quality failures с мониторингом, (4) Consumer-side statistical anomaly detection. Quality-first architecture дешевле, чем ретроактивное исправление.

Kafka Topic Governance

Naming Convention

Без naming convention 200 топиков превращаются в неуправляемый хаос. Governance-стандарт для Kafka-топиков:

{domain}.{entity}.{event_type}

Примеры:
  payments.transaction.created      -- новая транзакция
  payments.transaction.completed    -- завершённая транзакция
  customers.profile.updated         -- обновление профиля
  risk.scoring.calculated           -- расчёт скоринга
  audit.access.logged               -- запись audit log

Почему domain-based, а не team-based:

Partition Strategy Governance

Partition key определяет распределение данных по партициям. Неправильный ключ создаёт hotspots (одна партиция перегружена):

• customer_id — равномерно для FinSecure (1M+ клиентов)
• country_code — hotspot (90% трафика — Россия)
• timestamp — один partition получает весь текущий трафик

Governance-решение: Data Owner утверждает partition key при создании топика.

Topic ACL Governance

Принцип: produce — only owner, consume — by approval. Payment Gateway производит в payments.transaction.*, но не может читать risk.scoring.*. Audit Service читает всё (audit mandate).

Streaming Lineage

Отличие от Batch Lineage

Batch lineage — это снимок (snapshot): таблица A -> dbt model -> таблица B. Streaming lineage — это непрерывный поток с динамическими участниками:

Streaming Lineage Graph

Streaming lineage показывает: PostgreSQL -> Debezium CDC -> Kafka topic -> Enrichment -> Kafka topic -> 4 consumer groups. Изменение schema в cdc.transactions требует impact analysis на все downstream топики и consumer groups.

Для подробного разбора batch lineage и impact analysis повторите урок 04 этого модуля (Data Lineage и Impact Analysis).

Event-Driven Governance

Governance Events

Вместо периодического аудита (“раз в квартал проверяем соответствие”) — governance реагирует на события в реальном времени:

# Governance events и автоматические реакции
GOVERNANCE_EVENTS = {
    "topic_created": {
        "check": "Naming convention compliance",
        "action": "Block if non-compliant, alert Governance team"
    },
    "schema_changed": {
        "check": "Compatibility validation",
        "action": "Block if incompatible, notify consumer teams"
    },
    "consumer_added": {
        "check": "ACL verification",
        "action": "Verify consumer has approved access, audit log"
    },
    "dlq_threshold_exceeded": {
        "check": "DLQ rate > 1% of total",
        "action": "P2 incident, notify producer team"
    },
    "retention_expired": {
        "check": "Data past retention policy",
        "action": "Archive or dispose per policy"
    }
}

От периодического аудита к Real-Time Governance

CDC Governance

Итоги

• Schema Registry Governance: ownership (одна команда на схему), compatibility levels (FULL для production), deprecation process (90-day sunset)
• Stream Quality Enforcement: трёхуровневая валидация (schema, business rules, statistical), DLQ для quality failures
• Kafka Topic Governance: naming convention (domain.entity.event), partition strategy, ACL matrix
• Streaming Lineage: непрерывный (не snapshot), динамические потребители, schema-level tracking
• Event-Driven Governance: от периодического аудита к real-time реакции на governance events
• CDC Governance (Debezium): connector ownership, change event schema management, at-least-once delivery

Это завершает модуль M03: Метаданные и Каталоги Данных. Вы изучили: типы метаданных, бизнес-глоссарий, архитектуру каталога, Data Lineage, стандарты метаданных, автоматическую классификацию и streaming governance. В следующем модуле мы перейдём к M04: Качество Данных и Observability.