Походження даних

Походження даних (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 і нормалізацією аліасів/СТЕ/в'юх.
Анотації в коді трансформацій (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»
• «Управління ключами та ротація»