Происхождение данных

Происхождение данных (Lineage)

1) Что такое lineage и зачем он нужен

Data Lineage — это формальная запись «откуда пришли данные, как они трансформировались, где и кем использовались». Результат — ориентированный граф зависимостей с атрибутами (время, версии, владельцы, трансформации, политики доступа, качество), который делает систему данных объяснимой и аудируемой.

• Прозрачность метрик (финансы, продукт, риск): «почему число X = 1 234?».
• Быстрый импакт-анализ изменений (схема/джоб): «что сломается, если…».
• Соответствие и аудит (GDPR/ISO/SOC): доказуемый путь поля.
• Ускорение онбординга и снижение toil (самообслуживание знаний).
• Улучшение качества: целевые проверки там, где риск выше.

2) Области покрытия и уровни детализации

Потоковый уровень (pipeline/job): какие джобы/оркестраторы породили датасеты.
Уровень датасета (table/view/topic/file): входы → выходы, версии/снапшоты.
Столбцовый уровень (column/feature-level): как вычислено каждое поле, из каких исходников.
Слой потребления: отчеты BI, API, модели ML, дашборды и оповещения.

Для критичных сущностей (деньги, регуляторика) — обязательна column-level детализация.

3) Модель данных lineage: ключевые сущности

Dataset: `{urn, type, schema, owners, pii_class, retention, tags}`

Job/Task: `{urn, code_ref, version, runtime, schedule, owners}`

Run/Execution: `{run_id, job_urn, start/end, status, inputs[], outputs[], code_sha, infra}`

Field: `{dataset_urn, name, type, derivation}` (деривация — выражение/AST/оператор).

Policy: `{dataset_urn/field, access_rules, masking, consent_scope}`

Quality Check: `{check_id, scope, rule, severity, result}`

4) Источники lineage: активная vs пассивная сборка

Активная (event-based): инструментируем оркестраторы/движки (Spark/DBT/SQL engines/Kafka) для эмиссии событий «job started/finished, inputs/outputs, column-mapping».

Плюсы: точность, актуальность, минимизация пост-парсинга.
Пассивная (inference): парсим DAG’и, SQL/DDL/лог-запросы, логи каталогов/хранилищ; строим зависимости ретроактивно.

Плюсы: быстрый охват наследия; минусы: ниже точность на column-level.

Обычно применяют гибрид: активные события там, где можно, и пассивный анализ как «сетка страховки».

5) Архитектура решения (эталон)

Producers (оркестраторы/движки) → Шина событий lineage → Нормализатор → Хранилище графа → Индекс/поиск → UI/API/алерты → Экспорт/каталог.

События: унифицированные (job/run/dataset/column-lineage), с идентификаторами URN и семантическими версиями.
Хранилище графа: column-level граф (например, на базе графовой БД или реляционное + inverted index).
UI: интерактивная визуализация кратчайших путей, импакт/корень-причина, «сигналы качества» на ребрах и узлах.
Интеграции: каталог данных, система качества (DQ), управление доступом (ABAC), аудит (append-only журналы).

6) Идентификаторы и версионирование

URN/Global ID для каждого датасета/джобы/поля: стабильные, человекочитаемые, включающие платформу/неймспейс/имя/версию.
Версии схем (SchemaVersion) и версии кода (code SHA, image digest).
Снимки графа по времени (time-travel lineage): воспроизводимость расследований.

7) Column-level lineage: как получить достоверно

SQL-парсинг с построением AST и нормализацией алиасов/CTE/вьюх.
Аннотации в коде трансформаций (DBT tests, комменты-примитивы, UDF-metadata).
События из движков: указание выражений «target.col = f(src.a, src.b)».
Семантические правила: UDF/опсы агрегирования помечаются как «lossy» (с потерей гранулярности) или «sensitive-preserving» (переносит PII-метки).

8) Связь lineage с приватностью и безопасностью

Privacy by Design: метки полей `pii_class`, `consent_scope`, `retention`. При пропаганде колонок метки передаются по правилам (например, `email → hash_email` остается PII-derived).
Токенизация PII: lineage хранит факт токенизации/детокенизации и узлы токен-сервиса; любая детокенизация — событие с аудитом.
Шифрование: для полей AEAD/FPE lineage фиксирует «крипто-состояние» и ключевую область (tenant/scope) — без раскрытия ключей.
Аудит и WORM: события lineage и изменения политик хранятся в неизменяемом журнале (append-only с хэш-цепями).

9) Качество данных и SLO на базе lineage

Чеки на ребрах: свежесть (freshness), полнота (completeness), уникальность/ключи, дрейф распределений.
SLO/SLI: «95% джоб, питающих метрики финотчета, завершены ≤ 06:00 UTC».
Root-cause: граф + времена выполнения дают быстрое определение «первого сломавшегося узла».

10) Импакт-анализ и управление изменениями

При плановом изменении схемы/логики: по графу вниз по потоку (downstream) — список затрагиваемых отчетов/моделей/клиентов API.
Политика «breaking changes»: обязательное уведомление владельцев downstream-артефактов, grace-период, параллельные версии (`v1`/`v2`) и флаг «sunset-date».
Автоматические PR/тикеты с перечнем потребителей и чек-листом миграции.

11) Интеграция с оркестраторами и движками

Orchestrators: перед/после job эмитируются события `RunStarted/RunCompleted` с inputs/outputs.
SQL/ELT: коннекторы к движкам (warehouse, lakehouse) для получения фактического плана выполнения и маппинга столбцов.
Stream-processing: lineage сообщений (topic→topic, key/headers), схемы Avro/Protobuf, эволюция схем через registry.
ML: lineage фичей/датасетов, версий модели, артефактов тренировки, источников признаков.

12) Моделирование правил пропагации меток (data contracts)

Контракт набора данных: схема + семантика полей (ключи, PII, агрегируемость, лицензии/правовые основания, retention).

• `SELECT a,b FROM T` → перенести метки `a,b`.
• `hash(email)` → метка `PII-derived (pseudonymized)` с запретом детокенизации.
• `SUM(amount)` → потеря индивидуальности; запрещены join’ы на поле результата.
• Контракты валидируются в CI (blocker при несоответствии), а нарушения — события в аудит.

13) Производительность и масштаб

Инкрементальная инжестия событий lineage; дедупликация по `(run_id, job_urn)`.
Хранение графа: разделение горячего индекса (последние 30–90 дней) и архива; снапшоты.
Кэширование путей для частых запросов (короткие пути к «золотым» метрикам).
Шардинг по неймспейсам/арендаторам; защита от «узлов-монстров» (ограничение фан-аута).

14) Визуализация и UX

• Path to metric: «из чего собрана метрика».
• Impact from source: «кого затронет изменение».
• Field lineage: «как вычислено поле».
• Оверлеи: статусы джоб, качество, PII-метки, ретенции, владельцы.
• Действия: открыть контракт, создать тикет на миграцию, подписаться на алерты изменения.

15) Безопасность доступа к графу

ABAC: видимость узлов/ребер ограничена арендаторами/ролями.
Redaction: скрытие имен чувствительных полей (или их псевдонимизация) в UI для неподготовленных ролей.
mTLS/OIDC для API; события lineage подписываются сервисными идентичностями.
WORM и контроль чтений: чтение критичных сегментов графа тоже журналируется.

16) Эксплуатация: SLO, мониторинг, алерты

SLO графа: задержка появления события < 5 мин; полнота покрытия > 98% критичных пайплайнов; 100% «золотых метрик» имеют column-level lineage.
Алерты: разрыв цепочки, run без событий завершения, несогласованность схем, «осиротевшие» датасеты, рост фан-аута/циклы.
Отчеты: еженедельный «state of lineage coverage», топ-10 рисковых узлов.

17) Приватность и комплаенс (связки)

GDPR/PbD: хранить основания обработки и ретенции как теги; lineage обеспечивает быстрый DSAR-поиск путей и «право на удаление» через каскадное крипто-удаление соответствующих сегментов.
Менеджмент секретов: источники доступа к сырью никогда не попадают в lineage как открытые креды; хранится только ссылка на роль/политику.
Аудит/неизменяемые журналы: все события lineage подписаны и закреплены в append-only хранилище (см. соответствующую статью).

18) Чек-листы

• Определены URN-соглашения для datasets/jobs/fields.
• Включена эмиссия событий lineage из оркестраторов и движков.
• Работает парсер SQL/DDL и нормализатор схем.
• Утверждены data-contracts и правила пропагации PII/ретенций.
• Настроен WORM-журнал событий и резервные копии графа.
• BI/ML подключены как потребители lineage (отчеты, модели, фичи).

• Покрытие lineage по критичным доменам ≥ 98%, column-level по «деньгам» = 100%.
• Алерты на разрывы, «осиротевшие» датасеты, дрейф схем включены.
• Ежеквартальный аудит меток PII и контрактов.
• Документооборот изменений (breaking) и рассылка потребителям.

19) Мини-рецепты

json
{
"event": "RunCompleted",
"run": {
"id": "run_2025-10-31T14:20:00Z_42",
"job": "urn:job:etl:finance:close_books_v3",
"status": "SUCCESS",
"code_sha": "b3f9…",
"started_at": "2025-10-31T14:05:00Z",
"ended_at": "2025-10-31T14:19:52Z"
},
"inputs": [
"urn:dataset:lake:bank_txn_v2",
"urn:dataset:warehouse:fx_rates_d+1"
],
"outputs": [
"urn:dataset:warehouse:pnl_daily_v3"
],
"column_lineage": [
{
"output": "pnl_daily_v3. pnl_usd",
"expr": "SUM(txn. amount_local fx. rate)",
"inputs": ["bank_txn_v2. amount_local", "fx_rates_d+1. rate"],
"lossy": true
}
]
}

if input. field. pii in {email, phone, id} and transform in {hash, tokenize}:
output. field. pii = "pseudonymized"
elif transform in {aggregate, anonymize_k}:
output. field. pii = "anonymous"
else:
output. field. pii = input. field. pii

affected = downstream(urn:"urn:dataset:warehouse:users_v4", depth=4)
filter affected where kind in {"dashboard","model","api"} and owner not in {"team-exp"}

20) Частые ошибки и как их избежать

Lineage «по картинке» без формальной модели. Нужны события/схемы/URN, иначе граф не масштабируется.
Нет column-level там, где «деньги». Без столбцового уровня нельзя объяснять расчеты.
Неполные события (без code_sha/версии схем). Невозможна воспроизводимость.
Игнор приватности. Метки PII должны жить и переноситься вместе с полями.
Одна большая графовая БД без шардинга. Делите по неймспейсам, храните снапшоты.
Слепая вера парсерам. В спорных случаях — активные события из движков.

21) Runbook’и

Инцидент: метрика «прыгнула».

1. Открыть «Path to metric» → проверить последние `Run` узлов по пути.
2. Сверить версии кода/схем, статус DQ чеков на ребрах.
3. Если найдено сломанное звено — создать тикет владельцу, включить временный «hold» публикации метрики.
4. После фикса — отметить RCA и связать с узлами графа.

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

1. Запросить импакт downstream.
2. Разослать уведомления владельцам, создать PR’ы миграции.
3. Поднять параллельную `v_next`, держать обе версии до sunset-даты.
4. Закрыть `v_prev`, обновить контракты и lineage-граф.

• «Privacy by Design (GDPR)»
• «Токенизация PII-данных»
• «Менеджмент секретов»
• «Аудит и неизменяемые журналы»
• «Шифрование At Rest / In Transit»
• «Управление ключами и ротация»