Plasă de date: model de date federalizat

(Secțiunea: Tehnologie și infrastructură)

Scurt rezumat

Data Mesh este un model organizațional și tehnic în care datele sunt tratate ca produse ale echipelor de domeniu, iar rolul central al platformei este de a oferi self-service, standarde și conformitate. Pentru iGaming, aceasta înseamnă: echipa de plăți deține "Evenimente de depozit" și "Depozite nete Mart', echipa de risc deține" Semnale de fraudă ", Jocuri deține" Evenimente de pariere "și" Clasamente ", iar platforma centrală oferă un catalog, scheme de contracte, accesări, monitorizare a calității, finalizări și instrumente de streaming/ELT.

1) Principiile Mesh de date

1. Responsabilitatea domeniului: fiecare domeniu (Plăți, Risc, Jocuri, KYC/Conformitate, CRM, Afiliat) deține seturile sale de date și ciclul lor de viață.
2. Date ca produs: fiecare set are un proprietar, descriere, SLO, acces SLA, documentație, versiune, feedback și foaie de parcurs.
3. Platformă self-serve: conductele standard ingerează/transformă/servesc, șabloane, securitate implicită, director și observabilitate.
4. Management federal: standarde comune de scheme, metrica, PII/localizare si calitate - in centru; implementare si evolutie - in domenii.

2) Modelul și rolurile de operare

Domain Data Product Owner (DPO): prioritizare, SLO, restanțe ale îmbunătățirilor produselor de date.
Inginer de date Domeniu/Analytics Inginer: scheme, conducte, teste DQ, versioning.
Domain Steward: semantica de câmp, corespondența cu dicționarul de metrică și clasificarea PII.
Echipa platformei: catalog, IAM/RBAC, Policy-as-Code, formate de masă (Delta/Iceberg/Hudi), orchestrație, observabilitate, finops.
Federated Governance Board: aprobă standarde (scheme, metrici, securitate), rezolvă dispute între domenii.

3) „Produs de date” - pașaport și artefacte

• Contract (schemă, tipuri, evoluție, compatibilitate).
• Accesați API (SQL/tabel, subiect/flux, fișier/share).
• SLA/SLO (prospețime, disponibilitate, calitate).
• Teste DQ (unicitate, intervale, integritate referențială).
• Documentație (descrierea câmpurilor, exemple de cereri, proprietar, contact).
• Versioning (scheme de versiuni semantice, politica de depreciere).
• Politici (PII, localizare, retenție/TTL, drepturi).

Șablon de pașaport (YAML, exemplu)

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) Interoperabilitate și standarde

Scheme/contracte: Avro/Protobuf/JSON-Schema + Schema Registry; politica de back-compat, fără modificări de rupere fără o nouă versiune majoră.
Strat semantic: definiții unificate ale GGR, NGR, Net Deposits, LTV, cohorte - ca cod (dbt metrics/semantic layer).
Identificatori: global 'player _ id',' tenant _ id', 'bet _ id', directoare unificate de țară/monedă/furnizor.
Metadate: coloanele necesare 'inger _ ts',' schema _ version ',' trace _ id', 'source', 'region'.
Acces: SQL (lakehouse/OLAP), stream (Kafka/Pulsar), tabel/partajare instantanee; formatul de schimb este Parchet/Delta/Iceberg.

5) Procesul de referință standard (agnostic la furnizori)

Ingest: Outbox/CDC из OLTP → Kafka → Lakehouse (bronz).
Transformă: ELT/dbt в Silver/Gold; incremental „MERGE”, SCD, cazuri de afișare materiale.
Serviți: OLAP (ClickHouse/BigQuery/Fulg de zăpadă), RT- движки (Pinot/Druid) для aproape în timp real.
Catalog/Lineage: un singur catalog, auto-documentare, grafic de dependență.
Observabilitate: prospeţime/SLO metrics, DQ-assert, stream lag-uri, cost.
Politici: IAM/RBAC/ABAC, criptare, localizare (rutarea datelor zonei).

6) SLO/SLA pentru produse de date

• Prospețime: Pariuri Evenimente (p95) ≤ 5 мин; Semnale de fraudă ≤ 30 sec; Depozite nete Mart ≤ 15 min.
• Disponibilitate: ≥ 99. 9% pentru interfețe de citire.
• Calitate: duplicate ≤ 0. 01%, cota de campuri goale obligatorii ≤ 0. 1%, consistența valutară 100%.
• Cost SLO: costul scanărilor de ferestre ≤ N $/zi, raportul fișierelor mici <10%.

7) Siguranță, PII și localizare

Clasificare: PII/sensibil financiar/operațional.
Măsuri tehnice: criptare în repaus/tranzit; Tokenizarea PII; mascarea coloanelor; filtre la nivel de rând prin 'chiriaș _ id'.
Localizare: produsele de domeniu sunt publicate in regiuni autorizate (EU/TR/LATAM); partajare transfrontalieră - numai unități fără PII.
Audit: cine a publicat/citit; Cererile de escaladare a drepturilor versiunii schemei - prin aprobare.

8) FinOps și managementul valorii

Bugete pe domenii: limite de calcul, alerte exagerate.
Depozitare: clase de stocare + TTL (scurt bronz, mediu argint, aur lung/agregate).
Optimizare interogare: partiții/clustering, vizualizări materializate, cache rezultate BI.
Fișiere mici: politici de compactare/optimizare; Dimensiunea fișierului țintă este 128-1024 MB.

9) Ciclul de viață și evoluția

Versioning: 'domeniu. produs. v {major} '; câmpuri minore - back-compat.
Depreciați: notificarea consumatorilor, perioada „bidirecțională”, alerte automate la versiunile mai vechi.
Schema se modifică: Pull Request to contract repository; teste de compatibilitate CI; AutoPublish to Catalog.
Feedback: canal de produs (emitere tracker), NPS de consum, timp de răspuns incident.

10) Concretizarea pentru iGaming - domeniu și harta produsului

Plăți

'plăţi. psp. cârlige web. v1 '(flux)

'art _ net _ deposits _ daily. v1 '(SQL) - prospețime SLO ≤ 15 minute; Fără PII

Jocuri

'pariuri. evenimente. v1 '(stream/SQL) - p95 ≤ 5 min

'art _ ggr _ daily. v1 '(SQL/MV) - agregate după țară/joc

Risc/Antifraudă

'risc. semnale. v1 '(flux) - p95 ≤ 30 sec

"risk. case_mgmt. v1 '(SQL) - Istoria investigațiilor SCD2

CRM/Personalizare

'crm. declanșatoare. v1 '(flux) - declanșatoare de segment

'profile. caracteristici. online. v1 '(KV/SQL) - caracteristici online (TTL)

KYC/Conformitate

'kyc. status. v1 '(SQL) - politici protejate prin PII, la nivel de rând

"responsable _ gaming. evenimente. v1 '(flux) - limite/semnale

11) Procesele și artefactele platformei

Director: căutare după domenii/câmpuri/etichete PII, previzualizare diagrame și exemple.
Generatoare de șabloane: tăietor de bucate pentru un produs nou (pașaport, CI, teste DQ, tablou de bord SLO).
Politica-ca-cod: norme de export, PII, partajarea între regiuni.
Observabilitate: tablouri de bord gata făcute: Prospețime, erori DQ, Cost, Lineage, Stream lag.
Runbooks: incidente de prospețime/DQ/scheme, depreciere de urgență, rollback de versiuni.

12) Migrarea la plasă de date (foaie de parcurs)

1. Inventarul seturilor de date curente → gruparea pe domenii.
2. Pilot 2-3 domenii (Plăți, Jocuri, Risc) - eliberarea ca produse cu pașapoarte.
3. Catalog și standarde: scheme, metrici, PII/localizare, DQ.
4. Self-service: șabloane de conducte, CI/CD, monitorizare SLO.
5. Tăierea vitrinelor monolitice în cuptorul de explozie; suport „cu două căi ferate” pentru interfețele vechi.
6. Consiliul Federal - sesiuni regulate, revizuirea modificărilor contractului.
7. Scalați la CRM/Afiliați/Marketing, apoi Partner Share.

13) Lista de verificare a implementării

Domenii definite; proprietarii și canalele de comunicare sunt atribuite.
Directorul a început; pașaportul fiecărui produs este publicat.
Scheme - în depozitul de contracte; CI testează compatibilitatea/DQ.
SLO/SLA declarate; Sunt disponibile tablouri de bord pentru prospețime/DQ/cost.
Politici PII/localizare - cod; audit activat.
FinOps: bugete, alerte, cost prin raport de domeniu.
Procesul de versionare/depunere - documentat și automatizat.
Runbooks de incidente - disponibile și instruite (joc-zi).

14) Antipattern

„Redenumit Data Mesh, dar toate prin comanda centrală de date” - gâtul îngust nu este eliminat.
Lipsa unui singur dicționar de valori → GGR/NGR diferă între domenii.
Scheme fără contracte și teste de compatibilitate → versiuni „de rupere”.
Nici un Self-serve → fiecare tabel este creat manual, de mare timp-la-date.
Ignorarea PII/localizare în partajarea transregională.
Micro produse fără proprietari/SLO - date „abandonate”.

15) KPI de succes cu plasă de date

Timp până la date: de la idee la produsul cu date disponibile (↓ mediană).
Reutilizare: numărul de domenii de consum per produs.
Calitate: ponderea controalelor DQ de succes, defecte la un milion de evenimente.
Fiabilitate: respectarea SLO cu prospețime/disponibilitate.
Cost: $/cerere/utilizator, partajarea fișierelor mici, eliminarea calculelor.
Rata de schimbare: circuit/storefront lansări pe săptămână.

Rezumat

Data Mesh nu este doar o tehnologie, ci și o federație de domeniu gestionată, unde datele sunt produse cu proprietarii săi, SLO, contracte și valori de calitate. În iGaming, această abordare îndepărtează gâturile înguste, accelerează integrarea (anti-fraudă, plăți, CRM), îmbunătățește transparența metricii (GGR/NGR/LTV) și controlează costurile. Construiți o platformă puternică de auto-servire, introduceți standarde federate și o cultură a datelor ca produs, iar ecosistemul de analiză scalează cu afacerea - fără a pierde calitatea, viteza sau conformitatea.