GH GambleHub

Architecture de flux de données

1) Désignation et principes

Objectifs : Fournir des données correctes, opportunes et cohérentes pour l'analyse, le reporting, l'antifrod, la personnalisation et le ML.

Principes :
  • Data as a Product : propriétaires clairs, contrats, SLO et versioning.
  • Schema-first : les schémas sont obligatoires ; évolution selon les règles.
  • Privacy-by-Design : minimisation des PII, pseudonymisation, contrôle d'accès.
  • Observability-by-Default : traces, métriques, lineage, profils de qualité.
  • Cost-aware : tiered-storage, échantillonnage d'événements bruyants, compression.

2) Paysage des sources et des événements

Transactionnel : dépôts/retraits, paris/paiements, bonus, chargeback.
Personnalisé : sessions, clics, conversions, limites RG, statuts KYC.
Opérations : logs d'application, métriques de performance, alertes.
Fournisseurs : PSP/KYC/sanctions/studios de jeux (agrégateurs).
Références : catalogues de jeux, annuaires pays/devises, tarifs/taxes.

Typage des événements (exemple) :
json
{
"event_time":"2025-10-31T19:20:11Z",
"event_type":"payment. deposit",
"schema_version":"1. 3. 0",
"user":{"id":"U-123","country":"EE","age_band":"18-24"},
"payment":{"amount":200. 00,"currency":"EUR","method":"card","psp_ref":"PSP-222"},
"ctx":{"ip":"198. 51. 100. 10","session_id":"s-2233","trace_id":"f4c2..."}
}

3) Architecture de référence (haut niveau)

1. Couche Ingest

Passerelles (HTTP/gRPC), connecteurs CDC (OLTP), files d'attente/bus (Kafka/Redpanda), collecteurs de télémétrie.
Validation, normalisation, édition PII à l'entrée, contract enforcement.

2. Couche Streaming

Jobs de streaming (Flink/Spark Structured Streaming/Beam) avec déduplication, watermark, stateful agrégats.
Fan-out dans les entrepôts et les services en ligne (fichestor, antifrod).

3. Couche Batch

Orchestration (Airflow/Dagster), téléchargements incrémentiels, bascules et retro-processus, types SCD.

4. Stockage (Lakehouse)

Bronze : événements bruts (append-only, immutable).
Silver : tables nettoyées, conformées avec qualité et déduplication.
Gold : vitrines/marts pour des cas spécifiques (BI/régulateur/ML).
Formats tabulaires avec ACID (Delta/Iceberg/Hudi), diversité par couches chaudes/chaudes/froides.

5. Serving et accès

BI/SQL (Trino/Presto/DuckDB), couche sémantique (metrics layer), API/GraphQL, Feature Store pour la cohérence en ligne/hors ligne.

6. Howernance et sécurité

Catalogue/ligne, règles DQ, moteur d'accès politique (RBAC/ABAC), masquage/tokenization, archives WORM pour les rapports.

4) Contrats et régimes

Contrats de données : OpenAPI/AsyncAPI/JSON Schema/Avro.
Évolution : versions sémantiques ; Modification backward-compatible - ajout de champs nullables ; breaking est uniquement avec '/v2 'et double entrée pour la période de migration.
Registres : Schema Registry, annuaire des domaines (Payments, Gameplay, Marketing).

5) Modèles d'intégration

CDC (Change Data Capture) : de l'OLTP au bus (Debezium), le lot par clé de domaine.
Outbox/Inbox : livraison garantie des événements de logique de domaine.
Exactly-Once/Effectively-Once : transactions en stand, sink idempotent et, clés de déduplication.
Late Data & Watermarks : traitement des événements en retard ; fenêtres avec lateness allowed.
Reprocessing : piplines idempotentes, temps-voyage, corrections snapshot.

6) Modèle Lakehouse : bronze/argent/or

Bronze (raw):
  • Lots selon le temps (event_date) et le marché (jurisdiction).
  • Uniquement l'ajout ; stockage du payload d'origine pour le forensica.
Silver (clean):
  • Types normalisés, manuels, déduplication par '(event_id, event_time)'.
  • Vérification FK, standardisation des devises/temporisation, enrichissement.
Gold (serve):
  • Vitrines dénormalisées (GGR, RG-scoring, LTV, tables de cohorte).
  • SLA pour mise à jour, agrégats sous BI et rapports.

7) Qualité des données (Data Quality)

Règles : Validation schématique, gammes, unicité, exhaustivité, integrity referential.
Profilage : distributions, cardinalité, « dérive » des signes.
Surveillance : p50/p95 retard pipline, drop-rate, error budget.
Degradation policy : folleback automatique (dernier snapshot), alertes et t-tests de métriques.

Exemple de contrat DQ (YAML) :
yaml table: silver. payments rules:
- name: amount_positive type: range column: amount min: 0. 01
- name: currency_valid type: in_set column: currency set: [EUR,USD,GBP,TRY,BRL]
- name: unique_tx type: unique columns: [transaction_id]
slo:
freshness_minutes: 15 completeness_percent: 99. 5

8) Vie privée et conformité

Minimisation et masquage des PII : Stockez le pseudo-ID, séparez les mappings look-up.
Régionalisation : baquets/catalogues géo-locaux (EEE/UK/BR), « data residency ».
Opérations légales : DSAR/RTBF (projections déduites et édition sélective), Legal Hold, archives de rapports immuables.
Loging d'accès : audit des lectures des tables « sensibles », break-glass et JIT.

9) Observation et gestion

Linedge : Trace automatique des dépendances de la source à la vitrine.
Métriques de pipline : throughput, lag, failure-rate, cost/GB, cost/query.
Trace (OTel) : 'trace _ id'à partir d'applications se propage en événements → construit un chemin de requête de bout en bout.
Alert : Budgets SLO, anomalies de fraîcheur/volume/cardinalité.

10) Accès et modèle de sécurité

Catégories de données : public/internal/confidentiel/restreint.
Politiques : sécurité row/column-level ; masquage dynamique (PAN/IBAN/email).
Gestion des clés : KMS/CMK, cryptage at-rest/in-transit, rotation.
Ségrégation des responsabilités : rôles distincts de prod/analyste/admin/revueur.

11) Data Mesh et approche produit

Домены: Payments, Gameplay, Marketing, Risk, Compliance.
Produit de données : propriétaire, SLA de fraîcheur, dictionnaire de champs, tests, versions, métrique de consommation.
Contrats entre domaines : versionable, avec compatibilité backward, tests consommateurs (consumer-driven).

12) Fichestor et les flux ML

Feature registry : description des caractéristiques, des sources, des transformations, SLO.
Cohérence en ligne/hors ligne : code de transformation unique, délai de matérialisation en ligne ≤ 200-500 ms.
Surveillance de la dérive : PSI/KS, autopartage et retour en arrière des modèles, contrôle PII.
Journal des expériences : métadonnées, versions, reproducibility, cartes modèles.

13) Finmodel et cost-optimisation

Lot et Z-order/Cluster selon les prédicats fréquents.
Stockage à froid et TTL pour les tables inutilisées, VACUUM.
Vues materialized uniquement sous les modèles de requêtes stables.
Quotas et budgets pour les jobs lourds ; chargeback par équipe.

14) Topologie régionale et multi-tenants

Multi-région active-active : réplication de thèmes et de tables, périmètres de pipeline indépendants.
Failover/DR : Cible RPO/RTO, métadonnées de l'orchestrateur, vérification de récupération.
Multitenance : Isolation des catalogues/clés/quotas, marquage des tenant_id.

15) Processus et RACI (en résumé)

R : Data Platform (ingest, stockage, orchestration), Data Engineering (transformation).
A: Head of Data / Chief Data Officer.
C : Conformité/Juridique/DPO, Architecture, SRE.
I : BI/Analyse, Produit, Marketing, Finance.

16) SLO/SLI pour les flux

Fraîcheur (freshness) : p95 retard Argent ≤ 15 min, Gold (daily) prêt ≤ 06:00 lok. du temps.
Exhaustivité : ≥ 99. 5 % des événements par la fenêtre T.
Validité : error-rate des vérifications DQ <0. 5 % du volume.
Disponibilité du Serving : ≥ 99. 9 % pour l'API BI/Feature.

17) Modèles de tables et de lots

sql
-- Bronze: Deposit events
CREATE TABLE bronze. payment_deposits (
event_time TIMESTAMP,
event_id STRING,
user_pseudo_id STRING,
amount DECIMAL(18,2),
currency STRING,
psp_ref STRING,
payload VARIANT
)
PARTITION BY DATE(event_time)
CLUSTER BY (currency);

-- Silver: normalized model
CREATE TABLE silver. payments AS
SELECT event_id,
CAST(event_time AS TIMESTAMP) AS ts,
user_pseudo_id,
amount,
currency,
psp_ref
FROM bronze. payment_deposits
QUALIFY ROW_NUMBER() OVER (PARTITION BY event_id ORDER BY ts) = 1;

18) Orchestration et DevX

Infra-as-Code : référentiels de pipelines, tests, revues, GitOps.
Data Contracts CI : linters de circuits, tests DQ jusqu'au déploi.
Backfill-framework : Retro sécurisés avec limitation R/W et idempotency.
Catalogues et modèles : générateurs de pipline (cookie-cutter), meilleures pratiques.

19) Feuille de route pour la mise en œuvre

MVP (4-6 semaines) :

1. Bus d'événements + ingest de 2 à 3 sources clés (OLTP CDC, passerelle API).

2. Lakehouse Bronze/Silver, format avec ACID, catalogue et règles DQ de base.

3. 1-2 vitrines d'or (GGR quotidien et entonnoir de conversion).

4. Métriques lag/completeness, lineage de base, RBAC et masque PII.

Phase 2 (6-12 semaines) :
  • Streaming-agrégats (p95 latency ≤ 5 min), Feature Store, RG/AML vitrines.
  • Une couche de métriques sémantiques, SLA de reporting ; cost-dashboards.
  • Régionalisation (EEE/Royaume-Uni), procédures DSAR/RTBF, Legal Hold pour les artefacts.
Phase 3 (12 + semaines) :
  • Data Mesh : domaines de produits, contrats de consommation.
  • Opérations ML avec surveillance de la dérive, accord automatique en ligne/hors ligne.
  • Simulations automatiques des changements de schémas (impact analysis) et « what-if » au coût.

20) Erreurs fréquentes et comment les éviter

Payload's crus sans schémas : mettre en place un schema-first, un registre et une validation CI.
Pas de déduplication : clés d'événements et idempotent-sink dans Silver.
Mélange de PII avec l'analyse : séparer les mappings et masquer les champs.
Gold sans propriétaire : assigner owner, SLO et métriques de consommation.
Pas de stratégie reprocessing : time-travel, versioning logique, controle « double comptage ».
Coût non gérable : lots, compression, TTL, observabilité du coût.

21) Glossaire (bref)

CDC - Capture des changements de l'OLTP.
Outbox - nous publions les événements de domaine de manière transactionnelle.
Watermark - évaluation de l'exhaustivité du flux pour les fenêtres.
Lakehouse - data lake + tables ACID.
Data Product est une unité de données avec propriétaire et SLO.
Feature Store - Distribution convenue des caractéristiques ML.

22) Résultat

L'architecture du flux de données est un système d'arrangements gérables : contrats clairs, observabilité, sécurité et coût sous contrôle. En suivant les schémas décrits (schema-first, bronze/silver/gold, CDC + Outbox, DQ et lineage, privacy-by-design), la plateforme fournit de manière fiable des données d'entreprise, de conformité et ML de qualité avec des SLO prévisibles et un coût de possession compréhensible.

Contact

Prendre contact

Contactez-nous pour toute question ou demande d’assistance.Nous sommes toujours prêts à vous aider !

Telegram
@Gamble_GC
Commencer l’intégration

L’Email est obligatoire. Telegram ou WhatsApp — optionnels.

Votre nom optionnel
Email optionnel
Objet optionnel
Message optionnel
Telegram optionnel
@
Si vous indiquez Telegram — nous vous répondrons aussi là-bas.
WhatsApp optionnel
Format : +code pays et numéro (ex. +33XXXXXXXXX).

En cliquant sur ce bouton, vous acceptez le traitement de vos données.