Происхождение и путь данных

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-линейджа (данные→фичи→модель→инференс).
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, скорости экспериментов и зрелого комплаенса.