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) |
|---|---|---|
| Owner | Команда-владелец | CRM Domain Team |
| On-call | Дежурный инженер | @aivanov (ротация еженедельно) |
| SLA | Максимально допустимый downtime | 4 часа для customer_sync |
| Downstream | Потребители данных | ClickHouse marts, Metabase dashboards |
| Schedule | Расписание запуска | Ежедневно 02:00 UTC |
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
| Аспект | ETL Governance | ELT Governance |
|---|---|---|
| Фокус | Логика трансформации до загрузки | Доступ к raw-данным после загрузки |
| Quality gate | Перед Load (данные валидируются до попадания в target) | После Load (raw-данные уже в target, quality при трансформации) |
| PII risk | Можно маскировать при Transform | Raw PII попадает в target — требуется RBAC на raw layer |
| Audit trail | Трансформации — чёрный ящик без документации | Все шаги в SQL (dbt) — полный audit trail |
| Change management | PR review для ETL-кода | PR review для dbt models + schema migration |
DataTech использует ELT (dbt + ClickHouse). Ключевой governance risk: raw PII (email, phone) загружается в ClickHouse staging без маскирования. Решение: dbt macro для автоматического хэширования PII при переходе из staging в marts (связь с уроком 03: column-level lineage для PII).
Testing Standards
Governance-требования к pipeline testing:
- Input validation — проверка schema источника перед extract (schema drift detection)
- Output assertion — проверка row count, null ratio, uniqueness после transform
- Idempotency test — повторный запуск DAG не создаёт дубликатов
- Change management — PR review для изменений DAG, staging environment для тестирования
Пример Airflow DAG governance metadata:
dag = DAG(
dag_id="customer_sync",
description="Sync customers from PostgreSQL to ClickHouse",
tags=["domain:crm", "owner:crm-team", "sla:4h", "pii:true"],
# ...
)Tags обеспечивают discoverability и автоматическую классификацию DAGs по domain, owner, SLA и PII exposure.
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 определяет: кто устанавливает лимиты? Как запросить увеличение? Кто одобряет исключения?
| Tier | Лимит | Кто получает | Approval |
|---|---|---|---|
| Tier 1 (default) | 100 req/min | Все внутренние потребители | Автоматически |
| Tier 2 (elevated) | 1,000 req/min | Команды с обоснованием | Team Lead |
| Tier 3 (unlimited) | 10,000 req/min | Критические production pipelines | VP Engineering |
Schema Registry Governance
В event-driven архитектуре (Kafka, RabbitMQ) schema registry управляет контрактами между producer и consumer.
Schema Evolution Rules
Schema compatibility определяет, какие изменения producer может вносить без breakage consumers:
Добавление опционального поля (14%) | Удаление поля (21%) | Изменение типа поля (21%) | Добавление required поля (14%) | Гибкость producer (7%) | Защита consumer (21%) | Итого | |
|---|---|---|---|---|---|---|---|
| BACKWARD | 5 | 2 | 1 | 2 | 2 | 5 | 2.8 |
| FORWARD | 5 | 5 | 1 | 5 | 5 | 2 | 3.4 |
| FULL | 5 | 1 | 1 | 1 | 1 | 5 | 2.4 |
| NONE | 5 | 5 | 5 | 5 | 5 | 1 | 4.1 |
- BACKWARD — новая schema совместима со старыми consumers. Consumer может читать данные, написанные по старой И новой schema. Нельзя: удалять поля, менять типы, добавлять required поля.
- FORWARD — старая schema совместима с новыми данными. Producer может свободно менять schema, consumers адаптируются. Нельзя: менять типы.
- FULL — BACKWARD + FORWARD одновременно. Максимальная защита, минимальная гибкость.
- NONE — без проверок. FinSecure использовала NONE для 200+ topics — результат: 3 consumer crash за квартал.
Ownership и Approval Workflow
Каждый Kafka topic имеет:
- Schema owner — команда, которая определяет и эволюционирует schema
- Compatibility mode — устанавливается при создании topic, изменение требует approval от всех consumers
- Change workflow — PR с новой schema version -> CI проверяет compatibility -> consumer teams review -> merge
FinSecure: после 3 инцидентов перешли с NONE на BACKWARD для всех production topics. Исключение: FULL для regulatory topics (PCI DSS audit trail).
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:
- Format validation — encoding, delimiter, header check
- Schema validation — column names, types, required fields
- Quality validation — business rules (non-null patient_id, valid dates)
- Valid rows —> staging —> production
- Invalid rows —> quarantine table с конкретными violations
- Автоматическое уведомление vendor: “15 из 200 записей quarantined: 8 null patient_id, 7 invalid date format”
Data Sharing Agreements
Каждый B2B exchange требует формального соглашения:
| Элемент | Описание |
|---|---|
| Format | CSV/JSON/Parquet, encoding (UTF-8), delimiter |
| Schema | Column names, types, required fields (ODCS контракт) |
| Frequency | Ежедневно/еженедельно/по запросу |
| Quality SLA | Max % invalid records (< 5%), response time for fixes |
| Security | Encryption in transit (TLS), at rest, SFTP credentials rotation |
| Escalation | Контакт vendor при нарушениях, SLA для response |
Integration Pattern Selection
Выбор паттерна интеграции — архитектурное решение с governance-последствиями.
Ownership complexity (23%) | Latency requirements (15%) | Testing difficulty (15%) | Rollback capability (23%) | Schema governance (15%) | Monitoring maturity needed (8%) | Итого | |
|---|---|---|---|---|---|---|---|
| Batch ETL | 4 | 2 | 4 | 5 | 3 | 3 | 3.7 |
| Streaming CDC | 2 | 5 | 2 | 2 | 5 | 2 | 2.9 |
| API | 3 | 4 | 3 | 3 | 4 | 3 | 3.3 |
| File Exchange | 5 | 1 | 5 | 5 | 2 | 5 | 3.9 |
- 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:
- Pre-ingestion — schema validation (контракт определяет schema -> pipeline проверяет перед load)
- Post-transform — quality rules (контракт определяет mustBe: 0 nulls -> dbt test проверяет после transform)
- 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. В следующем модуле мы перейдём к Метаданным и Каталогам Данных — практическим инструментам реализации архитектурных принципов, описанных в этом модуле.