Modello di dati federato Data Mesh

(Sezione Tecnologia e infrastruttura)

Breve riepilogo

Data Mesh è un modello organizzativo e tecnico in cui i dati vengono considerati come prodotti di dominio e il ruolo centrale della piattaforma è quello di garantire l'autosufficienza, gli standard e la compilazione. Questo significa che il team Payments possiede Deposit Events e Net Deposits Mart, il team Risk - Fraud Signals, Games - Bet Events e Leader, mentre la piattaforma centrale fornisce catalogo, schemi-contratti, disponibilità, monitoraggio della qualità, finocchi e schemi strumenti di streaming/ELT.

1) Principi di Data Mesh

1. Responsabilità di dominio: ogni dominio (Payments, Risk, Games, KYC/Compliance, CRM, Affiliate) possiede i suoi set di dati e il loro ciclo di vita.
2. Dati come prodotto: ogni set ha proprietario, descrizione, accesso SLO, accesso SLA, documentazione, versione, feedback e road map.
3. Piattaforma Self-serve: pipline standard ingest/transfer/serve, modelli, protezione predefinita, directory e osservabilità.
4. Gestione federale: standard comuni di diagrammi, metriche, PII/localizzazione e qualità - al centro; implementazione e evoluzione nei domini.

2) Modello operativo e ruoli

Domain Data Product Owner (DPO) - Priorità, SLO, backlog di miglioramento del prodotto dati.
Domain Data Engineer/Analytics Engineer: schemi, pipline, test DQ, versioning.
Domain Steward: semantica dei campi, corrispondenza tra il dizionario delle metriche e la classificazione PII.
Platform Team: catalogo, IAM/RBAC, Policy-as-Code, formati tabellari (Delta/Iceberg/Hudi), orchestrazione, osservazione, finopoli.
Federated Governance Board: approva gli standard (schemi, metriche, sicurezza) e risolve le controversie di dominio crociato.

3) «Data Product» - passaporto e manufatti

• Contract (schema, tipi, evoluzione, compatibilità).
• API di accesso (SQL/tabella, topic/stream, file/share).
• SLA/SLO (freschezza, disponibilità, qualità).
• Test DQ (unicità, intervalli, integrità di riferimento).
• Documentazione (descrizione dei campi, esempi di query, owner, contatto).
• Versioning (semantic versioning schema, criterio di deprecazione).
• Criteri (PII, localizzazione, retrazione/TTL, diritti).

Modello passaporto (YAML, esempio)

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) Interoperabilità e standard

Schemi/contratti: Avro/Protobuf/JSON-Schema + Schema Registry; il criterio back-compat, che impedisce modifiche interrotte senza una nuova versione maggiore.
Livello semantico: definizioni uniche GGR, NGR, Net Deposits, LTV, coorti - come codice (dbt metrics/semantic layer).
Identificatori: globali «player _ id», «tenant _ id», «bet _ id», guide unificate di paesi/valute/provider.
Metadati: colonne obbligatorie «ingest _ ts», «schema _ variante», «trace _ id», «source», «region».
Accesso: SQL (lakehouse/OLAP), strame (Kafka/Pulsar), sharing di tabelle/snapshot; il formato di scambio è Parquet/Delta/Iceberg.

5) Riferimento tecnologico (agnostico ai venditori)

Ingest: Outbox/CDC из OLTP → Kafka → Lakehouse (Bronze).
Transform: ELT/dbt в Silver/Gold; «MERGE», SCD, vetrine materiali incrementali.
Serve: OLAP (ClickHouse/BigQuery/Snowflake), RT-движки (Pinot/Druid) для near-real-time.
Catalogo/Lineage: un unico catalogo, documentazione automatica, grafico delle dipendenze.
Osservabilità: metriche di freschezza/SLO, assert DQ, laghi di strima, costo.
Criteri: IAM/RBAC/ABAC, crittografia, localizzazione (routing di zona).

6) SLO/SLA per i prodotti dati

• Freshness: Bets Events (p95) ≤ 5 мин; Fraud Signals da 30 secondi; Net Deposits Mart 15 min.
• Availability: ≥ 99. 9% per le interfacce di lettura.
• Quality: duplicati da 0. 01%, la percentuale di campi obbligatori vuoti è 0. 1%, consistenza delle valute 100%.
• Cost SLO - Il costo delle vetrine della vetrina N $/giorno, small files ratio <10%.

7) Sicurezza, PII e localizzazione

Classificazione PII/sensibili find/operativi.
Tecnologie: crittografia at-rest/in-transit; Tornizzazione PII maschera delle colonne filtro row-level per «tenant _ id».
Localizzazione: i prodotti di dominio sono pubblicati nelle regioni autorizzate (EU/TR/LATAM); sharing transfrontaliero - solo aggregazioni senza PII.
Controllo: chi ha pubblicato/letto; Versione dello schema richieste di abilitazione tramite negoziazione.

8) FinOps e gestione del costo

Budget per domini: limiti di compute, alert di sovrapprezzo.
Storage: classe di storage + TTL (Bronze breve, Silver medio, Gold lungo/aggregato).
Ottimizzazione delle richieste: partiture/clustering, viste materializzate, cache dei risultati BI.
Small files: compettion/PERSONIZE CRITERI; Dimensioni target del file 128-1024 MB.

9) Ciclo di vita e evoluzione

Versioning: 'domain. product. v{major}`; i campi minori sono back-compat.
Deprekate: notifica dei consumatori, periodo a due binari, alert automatici sulle versioni precedenti.
Modifiche agli schemi: Pull Richiest nel repository dei contratti Test di compatibilità CI la pubblicazione automatica nella directory.
Feedback: canale prodotto (issue tracker), NPS consumatori, ora di risposta agli incidenti.

10) Precisione per i prodotti - mappa dei domini e dei prodotti

Payments

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

`mart_net_deposits_daily. v1 (SQL) - SLO di freschezza di 15 min; PII-free

Games

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

`mart_ggr_daily. v1 '(SQL/MV) - aggregazioni per paese/gioco

Risk/Anti-fraud

`risk. signals. v1 '(stream) - p95 ≤ 30 secondi

`risk. case_mgmt. v1 (SQL) - SCD2 cronologia investigativa

CRM/Personalization

`crm. triggers. v1 '(stream) - trigger segmentati

`profile. features. online. v1 '(KV/SQL) - fici online (TTL)

KYC/Compliance

`kyc. status. v1 '(SQL) - PII protetto, row-level policies

`responsible_gaming. events. v1 '(stream) - limiti/segnali

11) Processi e manufatti della piattaforma

Directory: ricerca del dominio/campo/etichette PII, anteprima di diagrammi e esempi.
Generatori di modelli: cookiecutter per il nuovo prodotto (passaporto, CI, test DQ, dashboard SLO).
Policy-as-Code: regole per l'esportazione, PII, sharing tra le regioni.
Osservabilità: Freshness, DQ, Cost, Lineage, Stream lag.
Runbooks: incidenti di freschezza/DQ/schemi, deprecato di emergenza, reimpostazione delle versioni.

12) Migrazione a Data Mesh (road map)

1. L'inventario dei dataset correnti viene raggruppato per dominio.
2. Pilota 2-3 domini (Payments, Games, Risk) - come prodotti con passaporti.
3. Catalogo e standard: diagrammi, metriche, PII/localizzazione, DQ.
4. Self-serve: modelli di pipline, CI/CD, monitoraggio SLO.
5. Taglio delle vetrine monolitiche per domini; Supporto a due binari per le interfacce precedenti.
6. Il Consiglio Federale - sessioni regolari, ringiovanendo il contratto di cambiamento.
7. Scalabilità su CRM/Affiliati/Marketing, poi su partnership.

13) Assegno-foglio di implementazione

Domini definiti; proprietari e canali di comunicazione assegnati.
Directory avviata; passaporto di ogni prodotto pubblicato.
Schemi - nel repository dei contratti CI sta testando compatibilità/DQ.
SLO/SLA dichiarati; i dashboard Freshness/DQ/Cost sono disponibili.
Criteri PII/Localizzazione - Codice; controllo attivato.
FinOps: budget, alert, rapporto «costi per domini».
Processo di versioning/deprecato - documentato e automatizzato.
Incidenti Runbooks - disponibili e addestrati (game-day).

14) Antipattern

Rinominato come Data Mesh, ma tutto tramite il comando dati centrale - la gola stretta non viene eliminata.
L'assenza di un unico dizionario di metriche GGR/NGR differisce tra domini.
Schemi privi di contratti e test di compatibilità .
Nessun Self-serve: ogni tabella viene creata manualmente, ad alto tempo-to-data.
Ignora PII/localizzazione durante la sharing crociata-regionale.
I microfrutti senza proprietari/SLO sono dati «abbandonati».

15) KPI di successo Data Mesh

Time-to-Data: dall'idea al prodotto dati disponibile (mediana).
Riutilizzo: numero di domini consumer per prodotto.
Qualità: percentuale di controlli DQ di successo, difetti per milioni di eventi.
Affidabilità: conformità SLO di freschezza/disponibilità.
Costo: $/richiesta/utente, quota di small files, smaltimento compute.
Velocità di modifica: rilasci diagrammi/vetrine a settimana.

Riepilogo

Data Mesh non è solo una tecnologia, ma anche una federazione di domini gestita, dove i dati sono prodotti con proprietari, SLO, contratti e metriche di qualità. Nel iGaming, questo approccio allevia le gole strette, accelera le integrazioni (antifrode, pagamenti, CRM), migliora la trasparenza delle metriche (GGR/NGR/LTV) e controlla i costi. Costruite una piattaforma forte self-serve, immettete standard federali e una cultura dei dati come prodotto, e il vostro ecosistema analitico è scalabile con il business - senza perdita di qualità, velocità e compliance.