Походження та шлях даних

1) Що таке Data Lineage

• Звідки взялися цифри у звіті?
• Які таблиці/поля торкнеться зміна схеми?
• Чому KPI змінився вчора о 21:00?
• Які дані потрапили в конкретну модель і версію ML?

Для iGaming це критично через регуляторики, фінансової звітності (GGR/NET), антифроду, KYC/AML, відповідальної гри і високої швидкості продуктових змін.

2) Рівні та гранулярність лінійджа

1. Бізнес-лінійдж - зв'язок метрик і бізнес-термінів (з глосарію) з вітринами/формулами.
2. Технічний лінійдж (табличний) - зв'язки між таблицями/джобами/пакетами трансформацій.
3. Колонночний (field/column-level) - яка колонка джерела формує колонку призначення, з правилами.
4. Runtime-лінійдж (операційний) - фактичні прогони: часи, обсяги, версії коду/схем, хеш-артефакти.
5. End-to-end - наскрізний шлях від провайдера/PSP/CRM до звіту/дашборду/моделі.
6. Cross-domain/Mesh - зв'язки між доменними продуктами даних за контрактами.

3) Ключова цінність

Довіра та аудит: зрозумілість звітів і моделей, швидке розслідування інцидентів.
Імпакт-аналіз: безпечні зміни схем/логіки, передбачуваність релізів.
Швидкість онбордингу: нові аналітики та інженери швидше розуміють ландшафт.
Відповідність вимогам: простежуваність PII, Legal Hold, звітність регуляторам.
Оптимізація витрат: виявлення «мертвих» пайплайнів і дублюючих вітрин.

4) Об'єкти та артефакти

Сутності графа: Source (провайдер ігор, PSP, CRM), Topic/Stream, Raw/Staging, Bronze/Silver/Gold, DWH, ML-фічі, BI-модель, Дашборд.
Зв'язки: трансформації (SQL/ELT), джоби (Airflow/DBT/...), моделі (версія), контракти (Avro/Proto/JSON Schema).
Атрибути: власник, домен, класифікація, версія схеми, контроль якості, свіжість, SLO/SLI.

5) Джерела правди для лінійджа

Статичний: парсинг SQL/конфігів (dbt, ETL) → будуємо залежності.
Динамічний/Runtime: збір метаданих під час виконання (оператор в оркестраторі, query logs).
Подієвий: lineage-івенти при публікації/читанні повідомлень в шині (Kafka/Pulsar), валідація контрактів.
Ручний (мінімум): опис складної бізнес-логіки, яка не витягується автоматично.

6) Лінійдж і Data Contracts

Контракт фіксує схему, семантику і SLA.
Перевірка сумісності (семвер) і ідемпотентність - обов'язкові.
Лінійдж зберігає посилання на контракт/версію і факт проходження перевірки (CI/CD + runtime).

7) Лінійдж в iGaming: доменні приклади

Ігрові події → агрегати RTP, волатильність, утримання, вітрина «Game Performance Gold».
Платежі/висновки/чарджбеки → звіти GGR/NET, антифрод-сигнали.
KYC/AML → статуси, перевірки, алерти → вітрини комплаєнсу і звітність.
Responsible Gaming → ліміти/самовиключення → скоринг ризиків і тригери інтервенцій.
Маркетинг/CRM → кампанії, бонуси, відіграш → вплив на LTV/ARPPU.

8) Візуалізація графа

• Два режими: «карта ландшафту» (макро) і «наскрізний трек» (мікро) від поля до поля.
• Фільтри: за доменом, власником, класифікацією (PII), середовищем (prod/stage), часом.
• Оверлеї: свіжість, обсяги, помилки DQ, версії схем.
• Швидкі дії: "Показати залежні", "Хто споживає цей стовпець? ", "Шлях до дашборду KPI".

9) Імпакт-аналіз та управління змінами

Перед зміною схеми/логіки запускайте what-if: які джоби/вітрини/дашборди/моделі торкнеться.
Автогенерація тікетів власникам залежних артефактів.
Патерн dual-write/blue-green для вітрин: v2 наповнюється паралельно, порівняння метрик, перемикання.
Backfill-плейбуки: як і чим довантажувати історичні дані, як перевіряти консистентність.

10) Лінійдж і якість даних (DQ)

Зв'язуйте правила DQ з вузлами/полями графа: валідність, унікальність, узгодженість, своєчасність.
При порушеннях відображайте «червоні сегменти» на шляхах і піднімайте алерти власникам.
Зберігайте історію DQ-інцидентів та їх вплив на KPI.

11) Лінійдж для ML/AI

Простежуваність: dataset → features → training code → model (версия) → inference.
Фіксуйте коміти, параметри навчання, версії фреймворків, дані валідації.
Лінійдж допомагає розслідувати дрейф, регрес метрик і відтворювати результати.

12) Лінійдж і приватність/комплаєнс

Маркуйте PII/фінансові поля, країни, закон (GDPR/локальні), підстава обробки.
Позначайте вузли, де застосовується маскування/псевдонімізація/анонімізація.
Для DSAR/Right to be forgotten трекайте, в яких вітринах/бекапах присутній суб'єкт.

13) Метрики (SLO/SLI) для лінійджа

Coverage: % таблиць/полів з колонковим лінійджем.
Freshness SLI: частка вузлів, що вкладаються в SLA оновлення.
DQ pass-rate: частка успішних перевірок по критичних шляхах.
MTTD/MTTR для інцидентів даних.
Change lead time: середній час узгодження і безпечного релізу схеми.
Dead assets: частка незатребуваних вітрин/джоб.

14) Інструменти (категорії)

Catalog/Glossary/Lineage: єдиний граф метаданих, імпорт з SQL/оркестраторів/шини.
Orchestration: збір runtime-метаданих, статуси завдань, SLA.
Schema Registry/Contracts: перевірки сумісності, політики версій.
DQ/Observability: правила, аномалії, свіжість, обсяги.
Sec/Access: мітки PII, RBAC/ABAC, аудит.
ML Registry: версія моделей, артефактів і датасетів.

15) Шаблони (готово до використання)

15. 1 Паспорт вузла лінійджа

• Класифікація: Public/Internal/Confidential/Restricted (PII)
• Джерело/Входи: таблиці/топіки + версії контрактів
• Трансформація: SQL/джоб/репо + коміт
• Виходи/Споживачі: вітрини/дашборди/моделі

• Сигнали спостережуваності: свіжість, обсяг, аномалії

• Історія інцидентів: посилання на тікети/пост-мортем

15. 2 Картка зв'язку (column-level)

З поля: schema. table. col (тип, nullable)

У полі: schema. table. col (тип, nullable)

Правило трансформації: вираз/функція/словник

Контекст якості: перевірки, діапазони, референси

15. 3 Плейбук розслідування інциденту

1. Визначити порушений KPI/дашборд → 2) Простежити шлях вгору (Upstream) до джерела →

2. Перевірити свіжість/обсяги/DQ на кожному вузлі → 4) Знайти останню зміну коду/схеми →

3. Порівняти прод/стейдж/вчора → 6) Призначити фіксацію і backfill → 7) Пост-мортем і правило на майбутнє.

16) Процеси та інтеграції

On-change: кожен merge в репо, що змінює схему/SQL, запускає перезбірку лінійджа і імпакт-аналіз.
On-run: кожен успішний/провалений джоб пише runtime-метадані в граф.
Access-hooks: запити на доступ показують шлях до PII і відповідальних власників.
Governance-ритуали: щотижневий огляд критичних шляхів, щомісячний звіт по SLO.

17) Дорожня карта впровадження

0-30 днів (MVP)

1. Визначити критичні KPI/дашборди та їх end-to-end шляхи.
2. Підключити парсинг SQL/джобів для табличного лінійджа.
3. Завести паспорт вузла/зв'язку і мінімальні метрики свіжості.
4. Описати PII-мітки в ключових шляхах (KYC, платежі).

60-90 днів

1. Перейти до column-level для топ-вітрин.
2. Інтегрувати runtime-метадані оркестратора (час, об'єм, статуси).
3. Зв'язати DQ-правила з графом, включити алерти.
4. Візуалізація: фільтри по доменах/власникам/PII, оверлеї свіжості.

3-6 місяців

1. Контракти та реєстр схем на подієвій шині (ігрові/платіжні фіди).
2. Повний трек ML-лінійджа (dannyye→fichi→model→inferens).
3. Імпакт-аналіз в CI → автоматичні тікети власникам залежностей.
4. Покриття column-level ≥70% активних вітрин; звітність по SLO.

18) Патерни і анти-патерни

• Graph-first: єдиний граф метаданих як «компас» змін.
• Contract-aware лінійдж: зв'язок з версіями схем і результатами валідації.
• Observability overlay: свіжість/обсяги/DQ поверх графа.
• Product-thinking: власники доменів публікують сертифіковані «продукти даних».

• «Картинка заради картинки» без автоматичного збору і підтримки.
• Ручні майнд-мепи замість парсингу і runtime-істини.
• Відсутність колонкової деталізації в критичних шляхах KPI.
• Лінійдж без зв'язки з доступами/PII і процесами DSAR/Legal Hold.

19) Практичні чек-листи

Перед релізом зміни даних

• Контракт оновлено, перевірка сумісності пройдена
• Імпакт-аналіз залежностей виконано
• v2-вітрина зібрана паралельно, порівняння метрик ок
• План backfill і відкату задокументований

Щотижневий огляд

• Критичні шляхи зелені по свіжості
• Немає «осиротілих» джоб/вітрин
• DQ-інциденти закриті і задокументовані
• Покриття column-level> цільового порогу

Підсумок

Лінійдж перетворює хаотичні потоки даних в керовану карту місцевості: видно, звідки що взялося, хто відповідає, які ризики і як безпечно міняти. Для iGaming це база довіри до KPI, швидкості експериментів і зрілого комплаєнсу.