Data Integration Governance

Введение

У DataTech 45 Airflow DAGs. Ни один не документирован. В субботу DAG customer_sync падает — данные из PostgreSQL не доходят до ClickHouse. Дашборды показывают устаревшие данные 48 часов. Три вопроса без ответа: кто владелец DAG? Какие данные он перемещает? Кто downstream-потребитель?

Это симптом отсутствия Data Integration Governance (управление интеграцией данных) — DMBOK2 Knowledge Area 8. В уроке 03 мы изучили Data Flow и Lineage: откуда данные приходят и куда уходят. В уроке 06 мы определили ODCS контракты: ЧТО именно producer обязан предоставить consumer. Теперь мы определим КАК — governance-практики для физического перемещения данных между системами.

ETL/ELT Governance

ETL (Extract-Transform-Load) и ELT (Extract-Load-Transform) — два основных паттерна интеграции. Governance для них различается принципиально.

Pipeline Ownership

Каждый pipeline должен иметь:

DataTech: из 45 DAGs только 12 имеют description в Airflow. Ни один не имеет определённого owner. Первый шаг — Pipeline Ownership Registry: маппинг DAG -> owner с on-call rotation.

Transformation Documentation

Каждая трансформация в pipeline должна быть документирована: входные данные, бизнес-логика, выходные данные, quality assertions. Для dbt-моделей это schema.yml с descriptions и tests. Для Airflow DAGs — docstring + metadata tags.

ETL vs ELT: различия governance

DataTech использует ELT (dbt + ClickHouse). Ключевой governance risk: raw PII (email, phone) загружается в ClickHouse staging без маскирования. Решение: dbt macro для автоматического хэширования PII при переходе из staging в marts (связь с уроком 03: column-level lineage для PII).

Testing Standards

dag = DAG(
    dag_id="customer_sync",
    description="Sync customers from PostgreSQL to ClickHouse",
    tags=["domain:crm", "owner:crm-team", "sla:4h", "pii:true"],
    # ...
)

API Governance

Внутренние и внешние API — второй ключевой паттерн интеграции. DataTech имеет 8 внутренних API. FinSecure — 12. Ни один не имеет формальной версионной политики.

Versioning Strategy

Семантическое версионирование для API: v{major}.{minor} в URL path.

• Major (/api/v1/ -> /api/v2/): breaking change — удаление поля, изменение типа, переименование endpoint
• Minor: non-breaking additive change — новое опциональное поле, новый endpoint

URL path versioning (/api/v1/customers) предпочтительнее header versioning (Accept: application/vnd.api+v1): проще для discovery, debugging, документации.

Deprecation Policy

Rate Limiting Governance

Rate limits защищают API от перегрузки, но governance определяет: кто устанавливает лимиты? Как запросить увеличение? Кто одобряет исключения?

Schema Registry Governance

В event-driven архитектуре (Kafka, RabbitMQ) schema registry управляет контрактами между producer и consumer.

B2B Data Exchange

Внешний обмен данными — третий паттерн интеграции с уникальными governance-вызовами: вы не контролируете отправителя.

Сценарий: BioGenesis

BioGenesis получает еженедельные CSV файлы от 5 внешних лабораторий. 12% записей fail quality validation: null patient_id, invalid date formats (DD/MM/YYYY вместо ISO 8601), encoding issues (Windows-1251 вместо UTF-8). Текущий процесс: reject entire file, request resend. Средняя задержка: 5 рабочих дней.

Governance для внешних данных

Row-level quarantine вместо full-file rejection:

1. Format validation — encoding, delimiter, header check
2. Schema validation — column names, types, required fields
3. Quality validation — business rules (non-null patient_id, valid dates)
4. Valid rows —> staging —> production
5. Invalid rows —> quarantine table с конкретными violations
6. Автоматическое уведомление vendor: “15 из 200 записей quarantined: 8 null patient_id, 7 invalid date format”

Data Sharing Agreements

Каждый B2B exchange требует формального соглашения:

Integration Pattern Selection

Выбор паттерна интеграции — архитектурное решение с governance-последствиями.

• Batch ETL (Airflow DAGs): простой ownership (DAG = owner), лёгкий rollback (перезапуск), но высокая latency. Подходит DataTech (Level 1).
• Streaming CDC (Debezium, Kafka): сложный ownership (topic = producer + N consumers), трудный rollback, но near-realtime. Требует Level 3+ governance. Подробнее — в курсе Debezium.
• API: средняя сложность, хороший контроль через versioning и rate limiting. DataTech: 8 APIs.
• File Exchange: простейший governance (файл = snapshot), но нет schema enforcement. BioGenesis B2B exchange.

Data Contract Enforcement

ODCS контракты (урок 06) определяют обязательства. Integration governance определяет enforcement — как проверить соблюдение контракта в runtime.

Contract Checks в Pipeline

Встраивание contract validation в integration pipeline:

1. Pre-ingestion — schema validation (контракт определяет schema -> pipeline проверяет перед load)
2. Post-transform — quality rules (контракт определяет mustBe: 0 nulls -> dbt test проверяет после transform)
3. SLA monitoring — latency check (контракт определяет latency: 1d -> monitoring alert при нарушении)

Связь с ODCS

ODCS quality section -> dbt tests (автоматическая генерация) ODCS slaProperties section -> monitoring alerts (Prometheus/Grafana) ODCS schema section -> schema registry compatibility check ODCS team section -> on-call rotation для incident response

Контракт без enforcement — документация. Контракт с enforcement — governance.

Итоги

• ETL/ELT Governance — pipeline ownership registry, transformation documentation, testing standards, change management через PR review
• API Governance — semantic versioning в URL path, 90-дневная deprecation policy, tiered rate limiting, parallel version support
• Schema Registry — BACKWARD/FORWARD/FULL/NONE compatibility modes; BACKWARD рекомендуется для production (защита consumers)
• B2B Data Exchange — row-level quarantine вместо full-file rejection, формальные Data Sharing Agreements
• Integration Pattern Selection — Batch ETL (простой governance, высокая latency) vs Streaming CDC (сложный governance, low latency) vs API (средний баланс) vs File Exchange (простейший, без schema enforcement)
• Contract Enforcement — ODCS контракты + pipeline validation = governance в runtime

Это завершающий урок модуля “Архитектура и Моделирование Данных”. Мы прошли путь от архитектурных принципов (урок 01) через моделирование (02), lineage (03), naming (04), data mesh и contracts (05-06) до интеграционного governance. В следующем модуле мы перейдём к Метаданным и Каталогам Данных — практическим инструментам реализации архитектурных принципов, описанных в этом модуле.