Data Mesh: федеративна модель даних

(Розділ: Технології та Інфраструктура)

Коротке резюме

Data Mesh - це організаційна і технічна модель, де дані розглядаються як продукти доменних команд, а центральна роль платформи - забезпечити самообслуговування, стандарти і комплаєнс. Для iGaming це означає: команда Payments володіє «Deposit Events» і «Net Deposits Mart», команда Risk - «Fraud Signals», Games - «Bet Events» і «Leaderboards», а центральна платформа дає каталог, схем-контракти, доступи, моніторинг якості, фінопс та інструменти стрімінгу/ELT.

1) Принципи Data Mesh

1. Доменна відповідальність: кожен домен (Payments, Risk, Games, KYC/Compliance, CRM, Affiliate) володіє своїми наборами даних і їх життєвим циклом.
2. Дані як продукт: у кожного набору є власник, опис, SLO, SLA доступу, документація, версія, зворотний зв'язок і дорожня карта.
3. Self-serve платформа: стандартні пайплайни ingest/transform/serve, шаблони, безпека за замовчуванням, каталог і спостережуваність.
4. Федеративне управління: загальні стандарти схем, метрик, PII/локалізації та якості - в центрі; реалізація та еволюція - в доменах.

2) Операційна модель і ролі

Domain Data Product Owner (DPO): пріоритизація, SLO, беклог поліпшень продукту даних.
Domain Data Engineer/Analytics Engineer: схеми, пайплайни, тести DQ, версіонування.
Domain Steward: семантика полів, відповідність словнику метрик і PII-класифікації.
Platform Team: каталог, IAM/RBAC, Policy-as-Code, табличні формати (Delta/Iceberg/Hudi), оркестрація, спостережуваність, фінопс.
Federated Governance Board: затверджує стандарти (схеми, метрики, безпека), вирішує крос-доменні суперечки.

3) «Data Product» - паспорт та артефакти

• Contract (схема, типи, еволюція, сумісність).
• API доступу (SQL/таблиця, topic/stream, файл/шер).
• SLA/SLO (свіжість, доступність, якість).
• DQ-тести (унікальність, діапазони, посилальна цілісність).
• Документація (опис полів, приклади запитів, owner, контакт).
• Версіонування (semantic versioning схеми, політика депрекейту).
• Політики (PII, локалізація, retention/TTL, права).

Шаблон паспорта (YAML, приклад)

yaml name: bets. events. v1 domain: games owner: games-data@company interface:
sql: lakehouse. silver. bets_events stream: kafka://bets. events. v1 share: read-only (EU only)
schema_version: 1. 3. 0 slo:
freshness: "<= 5 min (p95)"
availability: ">= 99. 9%"
dq:
- unique: bet_id
- valid_values: currency in [EUR, USD, TRY, BRL]
- non_negative: [stake, payout]
security:
pii: false region: EU retention: 365d lineage:
sources: [game_engine. outbox, payments. psp. webhooks]
consumers: [crm. triggers, risk. realtime, dwh. fact_bets]
versioning:
compat: backward deprecation_policy: "60 days"

4) Інтероперабельність і стандарти

Схеми/контракти: Avro/Protobuf/JSON-Schema + Schema Registry; політика back-compat, заборона ламаючих змін без нової мажорної версії.
Семантичний шар: єдині визначення GGR, NGR, Net Deposits, LTV, когорти - як код (dbt metrics/semantic layer).
Ідентифікатори: глобальні'player _ id','tenant _ id','bet _ id', уніфіковані довідники країн/валют/провайдерів.
Метадані: обов'язкові колонки'ingest _ ts','schema _ version','trace _ id','source','region'.
Доступ: SQL (lakehouse/OLAP), стрім (Kafka/Pulsar), шарінг таблиць/снапшотів; формат обміну - Parquet/Delta/Iceberg.

5) Технологічний еталон (агностично до вендорів)

Ingest: Outbox/CDC из OLTP → Kafka → Lakehouse (Bronze).
Transform: ELT/dbt в Silver/Gold; інкрементальні'MERGE', SCD, матеріальні вітрини.
Serve: OLAP (ClickHouse/BigQuery/Snowflake), RT-движки (Pinot/Druid) для near-real-time.
Каталог/Lineage: єдиний каталог, авто-документація, граф залежностей.
Спостережуваність: метрики свіжості/SLO, DQ-асерт, лаги стріму, вартість.
Політики: IAM/RBAC/ABAC, шифрування, локалізація (зонна маршрутизація даних).

6) SLO/SLA для продуктів даних

• Freshness: Bets Events (p95) ≤ 5 хв; Fraud Signals ≤ 30 сек; Net Deposits Mart ≤ 15 хв.
• Availability: ≥ 99. 9% для інтерфейсів читання.
• Quality: дублікати ≤ 0. 01%, частка порожніх обов'язкових полів ≤ 0. 1%, консистентність валют 100%.
• Cost SLO: вартість сканів вітрини ≤ N $/день, small files ratio <10%.

7) Безпека, PII і локалізація

Класифікація: PII/чутливі фіндані/операційні.
Техмери: шифрування at-rest/in-transit; токенізація PII; маскування колонок; row-level фільтри по'tenant _ id'.
Локалізація: доменні продукти публікуються в дозволених регіонах (EU/TR/LATAM); транскордонний шарінг - тільки агрегати без PII.
Аудит: хто публікував/читав; версія схеми; запити на ескалацію прав - через узгодження.

8) ФінОпс та управління вартістю

Бюджети по доменах: ліміти compute, алерти перевитрати.
Сховище: класи зберігання + TTL (Bronze короткий, Silver середній, Gold довгий/агрегати).
Оптимізація запитів: партії/кластеризація, матеріалізовані уявлення, кеш результатів BI.
Small files: compaction/OPTIMIZE політики; цільовий розмір файлу 128-1024 МБ.

9) Життєвий цикл і еволюція

Версіонування: `domain. product. v{major}`; мінорні поля - back-compat.
Депрекейт: повідомлення споживачів, «дворельсовий» період, автоматичні алерти на старі версії.
Зміни схем: Pull Request в репозиторій контрактів; CI-тести сумісності; автопублікація в каталог.
Зворотній зв'язок: канал продукту (issue tracker), NPS споживачів, час відповіді на інциденти.

10) Конкретизація для iGaming - карта доменів і продуктів

Payments

`payments. psp. webhooks. v1` (stream)

`mart_net_deposits_daily. v1'( SQL) - SLO свіжості ≤ 15 хв; PII-free

Games

`bets. events. v1'( stream/SQL) - p95 ≤ 5 хв

`mart_ggr_daily. v1'( SQL/MV) - агрегати по країнам/іграм

Risk/Anti-fraud

`risk. signals. v1'( stream) - p95 ≤ 30 сек

`risk. case_mgmt. v1'( SQL) - SCD2 історії розслідувань

CRM/Personalization

`crm. triggers. v1'( stream) - сегментні тригери

`profile. features. online. v1'( KV/SQL) - онлайн-фічі (TTL)

KYC/Compliance

`kyc. status. v1'( SQL) - PII захищено, row-level policies

`responsible_gaming. events. v1'( stream) - ліміти/сигнали

11) Процеси та артефакти платформи

Каталог: пошук по домену/полях/PII мітках, передогляд схем і прикладів.
Генератори шаблонів: cookiecutter для нового продукту (паспорт, CI, DQ-тести, дашборд SLO).
Policy-as-Code: правила експорту, PII, шарінгу між регіонами.
Спостережуваність: готові дашборди: Freshness, DQ-помилки, Cost, Lineage, Stream lag.
Runbooks: інциденти свіжості/DQ/схем, аварійний депрекейт, відкат версій.

12) Міграція до Data Mesh (дорожня карта)

1. Інвентаризація поточних датасетів → угруповання по доменах.
2. Пілот 2-3 домену (Payments, Games, Risk) - оформити як продукти з паспортами.
3. Каталог і стандарти: схеми, метрики, PII/локалізація, DQ.
4. Self-serve: шаблони пайплайнів, CI/CD, моніторинг SLO.
5. Різання монолітних вітрин на доменні; «дворельсова» підтримка старих інтерфейсів.
6. Федеративна рада - регулярні сесії, рев'ю контракту змін.
7. Масштабування на CRM/Афіліати/Маркетинг, потім - на партнерські шери.

13) Чек-лист впровадження

Домени визначені; власники і канали зв'язку призначені.
Каталог запущено; паспорт кожного продукту опублікований.
Схеми - в репозиторії контрактів; CI тестує сумісність/DQ.
SLO/SLA задекларовані; дашборди Freshness/DQ/Cost доступні.
Політики PII/локалізації - кодом; аудит включено.
ФінОпс: бюджети, алерти, звіт «вартість по доменах».
Процес версіонування/депрекейту - документований і автоматизований.
Runbooks інцидентів - доступні і відтреновані (game-day).

14) Антипатерни

«Перейменували в Data Mesh, але все через центральну команду даних» - вузьке горлечко не усувається.
Відсутність єдиного словника метрик → GGR/NGR розрізняються між доменами.
Схеми без контрактів і тестів сумісності → «ламаючі» релізи.
Немає Self-serve → кожна таблиця створюється вручну, високий time-to-data.
Ігнорування PII/локалізації при крос-регіональному шарінгу.
Мікропродукти без власників/SLO - «занедбані» дані.

15) KPI успіху Data Mesh

Time-to-Data: від ідеї до доступного продукту даних (медіана ↓).
Повторне використання: число доменів-споживачів на продукт.
Якість: частка успішних DQ-перевірок, дефекти на млн подій.
Надійність: відповідність SLO свіжості/доступності.
Вартість: $/запит/користувач, частка small files, утилізація compute.
Швидкість змін: релізи схем/вітрин на тиждень.

Підсумки

Data Mesh - це не тільки технологія, але і керована федерація доменів, де дані - продукти зі своїми власниками, SLO, контрактами і метриками якості. У iGaming такий підхід знімає вузькі горлечка, прискорює інтеграції (антифрод, платежі, CRM), покращує прозорість метрик (GGR/NGR/LTV) і контролює вартість. Побудуйте сильну self-serve платформу, введіть федеративні стандарти і культуру «дані як продукт», і ваша аналітична екосистема масштабується разом з бізнесом - без втрати якості, швидкості і комплаєнсу.