Data Mesh : modèle de données fédérées

(Section : Technologie et infrastructure)

Résumé succinct

Data Mesh est un modèle organisationnel et technique où les données sont considérées comme des produits d'équipes de domaine et où le rôle central de la plate-forme est de fournir le libre-service, les normes et la conformité. Pour iGaming, cela signifie : l'équipe Payments possède « Deposit Events » et « Net Deposits Mart », l'équipe Risk - « Fraud Signes », Games - « Bet Events » et « Leaders », et la plate-forme centrale donne un catalogue, des schémas-contrats, des accès, un suivi qualité, finops et outils de streaming/ELT.

1) Les principes de Data Mesh

1. Responsabilité de domaine : chaque domaine (Payments, Risk, Games, KYC/Conformité, CRM, Affiliate) possède ses ensembles de données et leur cycle de vie.
2. Les données sont comme un produit : chaque ensemble a un propriétaire, une description, un SLO, un accès SLA, une documentation, une version, une rétroaction et une feuille de route.
3. Plate-forme self-serve : pipline standard ingest/bou/serve, modèles, sécurité par défaut, catalogue et observabilité.
4. Gestion fédérée : normes communes de schémas, métriques, PII/localisation et qualité - au centre ; la réalisation et l'évolution sont dans les domaines.

2) Modèle d'exploitation et rôles

Domain Data Product Owner (DPO) : priorité, SLO, backlog d'amélioration des produits de données.
Domain Data Engineer/Analytics Engineer : schémas, piplines, tests DQ, versioning.
Domaine Steward : sémantique des champs, conformité au dictionnaire des métriques et à la classification PII.
Platform Team : catalogue, IAM/RBAC, Policy-as-Code, formats tabulaires (Delta/Iceberg/Hudi), orchestration, observabilité, fiançailles.
Federated Governance Board : approuve les normes (schémas, métriques, sécurité), résout les conflits de domaines croisés.

3) « Data Product » - passeport et artefacts

• Contrat (schéma, types, évolution, compatibilité).
• API d'accès (SQL/table, topic/stream, fichier/share).
• SLA/SLO (fraîcheur, disponibilité, qualité).
• Tests DQ (unicité, gammes, intégrité de référence).
• Documentation (description des champs, exemples de demandes, owner, contact).
• Versioning (système semantic versioning, politique de déprécation).
• Politiques (PII, localisation, rétention/TTL, droits).

Modèle de passeport (YAML, exemple)

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) Interopérabilité et normes

Schémas/contrats : Avro/Protobuf/JSON-Schema + Schema Registry ; la politique back-compat, l'interdiction des changements cassants sans nouvelle version majeure.
Couche sémantique : définitions uniques de GGR, NGR, Net Deposits, LTV, cohortes - comme code (dbt metrics/semantic layer).
Identifiants : global 'player _ id', 'tenant _ id', 'bet _ id', annuaires unifiés pays/devises/fournisseurs.
Métadonnées : colonnes obligatoires 'ingest _ ts',' schema _ version ',' trace _ id ',' source ',' region '.
Accès : SQL (lakehouse/OLAP), stream (Kafka/Pulsar), boule de tables/snapshots ; le format d'échange est Parquet/Delta/Iceberg.

5) Référence technologique (agnostique aux vendeurs)

Ingest: Outbox/CDC из OLTP → Kafka → Lakehouse (Bronze).
Transform: ELT/dbt в Silver/Gold; incrémental 'MERGE', SCD, vitrines matérielles.
Serve: OLAP (ClickHouse/BigQuery/Snowflake), RT-движки (Pinot/Druid) для near-real-time.
Catalogue/Lineage : catalogue unique, auto-documentation, graphique des dépendances.
Observabilité : métriques de fraîcheur/SLO, DQ-assert, lagunes de strim, coût.
Politiques : IAM/RBAC/ABAC, cryptage, localisation (routage de données par zone).

6) SLO/SLA pour les produits de données

• Freshness: Bets Events (p95) ≤ 5 мин; Fraud Signaux ≤ 30 secondes ; Net Deposits Mart ≤ 15 min.
• Availability: ≥ 99. 9 % pour les interfaces de lecture.
• Qualité : doublons ≤ 0. 01 %, proportion de champs obligatoires vides ≤ 0. 1 %, consistance des devises 100 %.
• Cost SLO : coût des scans de vitrine ≤ N $/jour, petits fichiers ratio <10 %.

7) Sécurité, PII et localisation

Classification : IPI/fin sensible/exploitation.
Techniques : cryptage at-rest/in-transit ; Tokénisation du PII ; masquage des colonnes ; filtres row-level par 'tenant _ id'.
Localisation : les produits de domaine sont publiés dans les régions autorisées (UE/TR/LATAM) ; boule transfrontalière - seulement les agrégats sans PII.
Vérification : qui a publié/lu ; la version du schéma ; demandes d'escalade des droits - par le biais de l'harmonisation.

8) FinOps et gestion des coûts

Budgets par domaine : limites de calcul, alertes de dépassement.
Stockage : classes de stockage + TTL (Bronze court, Argent moyen, Or long/agrégats).
Optimisation des requêtes : lots/clusters, vues matérialisées, cache de résultats BI.
Petits fichiers : compaction/OPTIMIZE des politiques ; taille de fichier cible 128-1024 Mo.

9) Cycle de vie et évolution

Versioning : 'domain. product. v{major}`; les champs mineurs sont back-compat.
Deprecate : avis aux consommateurs, période « double rail », alertes automatiques sur les anciennes versions.
Modifications de schémas : Pull Request dans le référentiel de contrats ; Les tests de compatibilité CI ; auto-publication dans le catalogue.
Feedback : canal du produit (issue tracker), NPS des consommateurs, temps de réponse aux incidents.

10) Spécification pour iGaming - carte des domaines et des produits

Payments

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

`mart_net_deposits_daily. v1 '(SQL) - SLO de fraîcheur ≤ 15 min ; PII-free

Games

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

`mart_ggr_daily. v1 '(SQL/MV) - agrégats par pays/jeux

Risk/Anti-fraud

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

`risk. case_mgmt. v1 '(SQL) - SCD2 de l'historique des enquêtes

CRM/Personalization

`crm. triggers. v1 '(stream) - déclencheurs de segments

`profile. features. online. v1 '(KV/SQL) - fiches en ligne (TTL)

KYC/Compliance

`kyc. status. v1 '(SQL) - PII protégé, row-level polices

`responsible_gaming. events. v1 '(stream) - limites/signaux

11) Processus et artefacts de la plateforme

Catalogue : recherche par domaine/champs/étiquettes PII, anticipation de schémas et d'exemples.
Générateurs de modèles : Cookiecutter pour un nouveau produit (passeport, CI, tests DQ, SLO).
Policy-as-Code : règles d'exportation, PII, sharing entre les régions.
Observabilité : Dashboards prêts à l'emploi : Freshness, erreurs DQ, Cost, Lineage, Stream lag.
Runbooks : incidents de fraîcheur/DQ/schémas, déprécation d'urgence, version de retour.

12) Migration vers Data Mesh (feuille de route)

1. Inventaire des datacets actuels → regroupement par domaine.
2. Pilote de domaine 2-3 (Payments, Games, Risk) - décerner comme des produits avec des passeports.
3. Catalogue et normes : schémas, métriques, PII/localisation, DQ.
4. Self-serve : modèles de pipelines, CI/CD, surveillance SLO.
5. Découper des vitrines monolithiques sur des domaines ; support « double rail » des anciennes interfaces.
6. Le Conseil Fédéral - les sessions régulières, rongeant le contrat de changement.
7. Mise à l'échelle sur CRM/Affiliations/Marketing, puis sur les partenaires.

13) Chèque de mise en œuvre

Les domaines sont définis ; les propriétaires et les canaux de communication sont désignés.
Le catalogue a démarré ; le passeport de chaque produit est publié.
Schémas - dans le référentiel de contrats ; CI teste la compatibilité/DQ.
Les SLO/SLA sont déclarés ; Dashboards Freshness/DQ/Cost disponibles.
Politiques PII/localisation - code ; l'audit est inclus.
FinOps : budgets, alertes, rapport « coût par domaine ».
Processus de versioning/déportation - documenté et automatisé.
Runbooks Incidents - disponibles et décongelés (game-day).

14) Anti-modèles

« Renommé Data Mesh, mais tout à travers l'équipe centrale de données » - le col étroit n'est pas éliminé.
L'absence d'un seul dictionnaire de métriques → GGR/NGR diffère d'un domaine à l'autre.
Schémas sans contrats et tests de compatibilité → versions « cassantes ».
Pas de Self-serve → chaque table est créée manuellement, haut time-to-data.
Ignorer le PII/la localisation dans la boule croisée régionale.
Microproduits sans propriétaires/SLO - données « abandonnées ».

15) KPI de succès Data Mesh

Time-to-Data : de l'idée au produit de données disponible (médiane de l' ↓).
Réutilisation : nombre de domaines consommateurs par produit.
Qualité : proportion de contrôles DQ réussis, défauts sur des millions d'événements.
Fiabilité : Conformité SLO de fraîcheur/disponibilité.
Coût : $/demande/utilisateur, part des petits fichiers, recyclage compute.
Taux de changement : sorties de circuits/vitrines par semaine.

Résultats

Data Mesh est non seulement une technologie, mais aussi une fédération gérée de domaines où les données sont des produits avec leurs propriétaires, SLO, contrats et métriques de qualité. Dans iGaming, cette approche enlève les gorges étroites, accélère les intégrations (antifrod, paiements, CRM), améliore la transparence des métriques (GGR/NGR/LTV) et contrôle les coûts. Construisez une plate-forme de self-serve forte, entrez les normes fédérées et la culture « données comme produit », et votre écosystème analytique s'adapte à l'entreprise - sans perte de qualité, de vitesse et de complication.