Lacs de données et agrégation des flux

1) Destination et valeur

• Les flux des produits/jeux/paiements atterrissent dans Bronze « tel quel ».
• Silver normalise et enrichit en fournissant des clés cohérentes et de qualité.
• Gold - vitrines agrégées (y compris real-/near-real-time) pour BI, régulateur, antifrode/RG.

L'agrégation des flux à Lakehouse donne : faible latence des rapports, coût prévisible, reproductibilité et forensisme.

2) Architecture de référence

1. Ingest/Edge: HTTP/gRPC, OTel, batch endpoints → шина (Kafka/Redpanda).
2. Bronze (append-only) : stockage objet + tables ACID (Delta/Iceberg/Hudi), lots par date/market/tenant ; stocker le payload d'origine.
3. Stream Compute : Flink/Spark/Beam - unités de fenêtre, CEP, dedup, online-lookups.
4. Silver (clean/confort) : normalisation des monnaies/temporisation, FK/handbook, SCD pour les mesures.
5. Serving/OLAP : ClickHouse/Pinot/Druid sont des unités de minutes/secondes matérialisées pour les panneaux.
6. Gold (serve) : vitrines diurnes/horaires, tranches réglementaires, paquets d'exportation immuables (WORM).
7. Contours de contrôle : Schema Registry, DQ-as-code, lineage, catalogues, secrets/KMS, RBAC/ABAC.

3) Contrats et régimes

Schema-first: JSON/Avro/Protobuf; champs obligatoires : 'event _ time (UTC)', 'event _ id', 'trace _ id', 'user _ pseudo _ id', 'market', 'schema _ version'.
Évolution : back-compatible → ajouter nullable ; breaking → '/v2 '+ double enregistrement.
Catalogue : description du domaine, propriétaire, SLA de fraîcheur, règles DQ, lignage.

4) Atterrissage des débits dans le lac

Exactly-once au fond : publication at-least-once + sink idempotent (MERGE/upsert par 'event _ id').
Dedup : stateful en stream + singularité en Silver.
Compaction de fichiers : petits fichiers → régulier OPTIMIZE/VACUUM pour la lecture et le coût.
Temps-voyage : comprend le débogage, le repli et l'audit.

sql
CREATE TABLE bronze. payment_events (
event_id STRING, user_pseudo_id STRING, currency STRING,
amount DECIMAL(18,2), market STRING, event_time TIMESTAMP, payload STRING
)
PARTITIONED BY (days(event_time), market);

5) Agrégation de flux : fenêtres et watermarks

• Tumbling - fixe (par exemple 1 min/5 min) pour les panneaux stables.
• Hopping : Chevauchement (étape
• Session - ruptures de comportement par inactivité.
• Watermarks : contrôle des données late (généralement 2-5 minutes), règles de pré-émission/correction.

sql
SELECT market,
TUMBLE_START(event_time, INTERVAL '1' MINUTE) AS ts_min,
COUNT() AS deposits_1m,
SUM(amount_base) AS sum_1m
FROM silver. payments
GROUP BY market, TUMBLE(event_time, INTERVAL '1' MINUTE);

6) Matérialisation des agrégats

Moteur OLAP (ClickHouse/Pinot/Druid) : stocke des unités minutes/secondes pour les dashboards et les analyses opérationnelles.
Lakehouse Gold : stocke les tranches journalières/horaires pour le signalement et la sverok (reproductibilité).

sql
CREATE MATERIALIZED VIEW mv_ggr_1m
ENGINE = AggregatingMergeTree()
PARTITION BY toDate(event_time)
ORDER BY (toStartOfMinute(event_time), market, provider_id) AS
SELECT toStartOfMinute(event_time) AS ts_min,
market,
provider_id,
sumState(stake_base) AS s_stake,
sumState(payout_base) AS s_payout
FROM stream. game_events
GROUP BY ts_min, market, provider_id;

sql
CREATE OR REPLACE VIEW gold. ggr_daily AS
SELECT
DATE(event_time) AS event_date,
market, provider_id,
SUM(stake_base) AS stakes_eur,
SUM(payout_base) AS payouts_eur,
SUM(stake_base) - SUM(payout_base) AS ggr_eur
FROM silver. fact_game_financials
GROUP BY 1,2,3;

7) Argent : Normalisation et alignement

Heure et devise : 'event _ time (UTC)', 'amount _ base', 'fx _ rate _ used', 'fx _ source'.
Clés/guides : 'user _ pseudo _ id', 'game _ id', 'provider _ id', 'market'.
SCD II : historique des mesures (users/games/providers/RG/KYC).
Règles DQ : unicité des clés, références, fourchettes de montants, validation temporelle.

8) Registre des agrégats et définitions « correctes »

Semantic Layer : formule unique GGR/NGR, paris/gains, conversion, ARPPU, latitude p95.
Versioner les métriques : 'metric _ version' et 'as-of' calcul.
Cartes de dock : owner, formule, sources, SLA prêt.

9) Exactly-once/idempotence et ordre

Bus : at-least-once + partitionnement (ordre local).
Traitement : dedup par 'event _ id' (TTL 24-72h), opérateurs de fenêtre/CER avec réglages.
Sink : commits transactionnels ou idempotent upsert/merge.
Outbox/Inbox : publication d'événements de domaine à partir d'OLTP avec garantie.

10) Données latines et ajustements

Allowed lateness : 2-5 min pour les vitrines opérationnelles ; Transbordement journalier pour Gold.
Corrections : pré-émissions en OLAP et en or (idempotent).
Indicateurs : 'late = true', 'correction _ of = <event _ id>' pour l'audit.

11) Observabilité et DQ

• p95 ingest→1 -min vitrine ≤ 2-5 c ; Gold Daily est prêt avant 06:00 lok.
• Completeness ≥ 99. 5%; Schema validity ≥ 99. 9%; Trace coverage ≥ 98%.
• Mesures des piplines : lag/throughput/busy time/state size, late-ratio, dup-rate.
• DQ-dashboards : Freshness/Completeness/Validity, entonnoir de perte, carte de clés « chaudes ».
• Lineage : route de Bronze à Gold/Export ; analyse d'impact en cas de changement.

12) Vie privée, résidence, sécurité

Minimisation des PII : pseudonyme, mapping sécurisé séparé.
Résidence : EEA/UK/BR - répertoires séparés et clés de cryptage ; interdiction des join's cross-régionaux sans raison.
Cryptage : TLS en transit ; KMS/CMK at-rest; signatures d'exportation + WORM dans le cadre de la réglementation.
DSAR/RTBF/Legal Hold : édition sélective, gel des suppressions, accès audités.

13) Productivité et coût

Lot : par date/marché/tenant ; clustering/Z-order sur des attributs souvent filtrables.
Compaction : élimination des petits fichiers, OPTIMIZE/VACUUM régulier.
Matérialisation : minutes/secondes - en OLAP ; 24/heures - en or.
Tiered storage : hot/warm/cold, SLA de récupération, chargeback par commande (cost/GB, cost/query).
Préagrégation/sketch : HyperLogLog/approx-distinct si acceptable.

14) Exemples (fragments)

python if count_deposits(window=10MIN) >= 3 \
and sum_deposits(window=10MIN) > THRESH \
and all(d. amount < REPORTING_LIMIT for d in window_events):
emit_alert("AML_STRUCTURING", user_id, snapshot())

sql
CREATE TABLE silver. payments AS
SELECT EXCEPT(rn) FROM (
SELECT p., ROW_NUMBER() OVER (PARTITION BY event_id ORDER BY event_time) rn
FROM bronze. payment_events p
) WHERE rn = 1;

sql
MERGE INTO silver. fact_bets s
USING stage. fact_bets_delta d
ON s. bet_id = d. bet_id
WHEN MATCHED THEN UPDATE SET
WHEN NOT MATCHED THEN INSERT;

15) Processus et RACI

• Data Platform (Lakehouse/catalogue/ACID, compaction),
• Streaming (agrégats/CEP/dedup),
• Domain Analytics (métriques/Or).
• A (Accountable): Head of Data/CDO.
• C (Consulted): Compliance/Legal/DPO (PII/residency/Legal Hold), Finance (FX/GGR), SRE (SLO/стоимость), Security.
• I (Informed) : BI/Produit/Commercialisation/Opérations.

16) Feuille de route pour la mise en œuvre

1. Lakehouse Bronze/Silver (tables ACID), ingest de Kafka, registry schémas.

2. Unités de base (1-5 min) en OLAP ; la vitrine Gold. ggr_daily (D + 1 à 06:00).

3. DQ-as-code pour Payments/Gameplay, dashboards Freshness/Completeness.

4. Compaction/OPTIMIZE, métriques cost minimales et alerts lag/late/dup.

• Extension Silver (SCD II pour users/games/providers), lineage et analyse d'impact.
• Lookups asynchrones (RG/KYC/ASN/BIN), contrôle late-correction.
• Couche sémantique de métriques, règlement d'exportation (WORM/signatures).

• Multi-région, DR/replay simulateur, auto-tuning fenêtres et watermarks.
• Cost-dashboards, chargeback/quotas, stockage tiered et archivage.
• Autogénération de la documentation des vitrines et des cartes métriques.

17) Chèque-liste avant la vente

• Régimes et contrats inscrits au registre ; les tests back-compat sont verts.
• Inclus : dedup, watermark/allowed lateness, DLQ.
• Compaction/OPTIMIZE/VACUUM sont configurés comme prévu.
• SLO: p95 ingest→minute-view, Gold до 06:00; alerte lag/late/dup/state size.
• Les règles DQ sont actives ; lineage visible de Bronze aux exportations.
• RBAC/ABAC и KMS; résidence et DSAR/RTBF/Legal Hold testés.
• Coût sous contrôle (cost/GB, cost/query, part cold), limites de relais.

18) Anti-modèles et risques

Mélange des données brutes et des données de rapport dans un seul tableau : perturbe la préducibilité.
Manque de compaction : explosion de petits fichiers → demandes coûteuses.
Calcul FX « rétroactif » : brise l'historique et les rapports.
Pas de watermarks/late-policy : les vitrines et les alertes « flottent ».
Reload complet sans besoin : utilisez des incréments/MERGE et des ajustements.
PII dans l'analyse : garder les mappings séparés, inclure CLS/RLS.

19) Glossaire (bref)

Lakehouse - data lake + tables ACID et moteur SQL.
Bronze/Argent/Or - nappes brutes/normalisées/servinières.
Watermark est la limite de disponibilité des fenêtres par event-time.
Materialized View est une vitrine préfabriquée pour une lecture rapide.
Time-travel - lecture des versions historiques des tables.
WORM est le stockage immuable des artefacts d'exportation.

20) Résultat

Le lac de données avec l'agrégation de stream correcte est une discipline de couches et de contrats : Bronze « tel quel », Argent pour la normalisation et la qualité, OLAP pour les panneaux de minutes, Or pour les rapports reproductibles. En gérant les fenêtres et watermarks, le dédoublement et la compacte, la vie privée et le coût, vous obtenez des vitrines rapides, vérifiables et compressibles pour le produit, la compacte et la gestion opérationnelle.