Data Lake et stockage centralisé

(Section : Technologie et infrastructure)

Résumé succinct

Data Lake est la couche de base du stockage centralisé des matières premières et des datacets consolidés. Pour iGaming, il accepte les événements de paris/paiements/jeux, les téléchargements partenaires, les CDC de l'OLTP et les donne à l'analyse, l'antifrood, le CRM et la BI. Pratique moderne - Lakehouse : formats de colonne ouverts + couche de tableau ACID + répertoire unique + transactions/versions de données. La clé du succès est la discipline des schémas et des lots, la gestion des coûts, la sécurité PII et une culture opérationnelle rigoureuse (DQ, lineage, DR).

Rôle de Data Lake dans la plateforme iGaming

Un seul point de vérité pour l'analyse : le stockage des données brutes et nettoyées, quelle que soit la source et le format.
Flexibilité : support de batch et streaming (CDC/connecteurs, event-streams).
Évolution : des bruts Bronze aux conformés Silver et aux vitrines d'affaires Gold.
Partage des responsabilités : Les services pro écrivent dans le bus/stajing, analytique/ML consomme à partir des couches du lac.

Modèles architecturaux : Lake vs Lakehouse

Data Lake (S3/ADLS/GCS + Parquet/ORC) : schema-on-read, stockage bon marché, flexibilité des formats.
Lakehouse (Delta/Iceberg/Hudi en haut de Parquet) : transactions ACID, upsert/merge, temps-voyage, fichiers compacts, vide, indexation/clustering.
Pratique : Pour iGaming, Lakehouse est rentable en tant que couche principale et les OLAP externes (ClickHouse/BigQuery/Snowflake/Pinot) sont comme des vitrines et des moteurs spéciaux.

Modèle de calque médaillon

Bronze (Raw/Staging) : fichiers bruts provenant de sources (CDC, logdam, CSV, webhooks). Validation minimale, « telle quelle ».
Silver (Conformed) : nettoyage/déduplication, normalisation des monnaies/fuseaux horaires, mise en forme des types, mesures SCD, clés de cohérence.
Gold (Marts/Serving) : agrégats pour GGR/NGR/LTV/Retraite, vitrines matérialisées sous BI/CRM/antifrode.
TTL : agressif chez Bronze, modéré chez Silver, durable chez Gold.

Formats et calques tabulaires

Colonnes : Parquet (standard de facto), ORC.

• Delta Lake - transactions, 'MERGE', temps-voyage, optimisation/vide, Z-order.
• Apache Iceberg est une table avec des manifestes/snapshots, une partition cachée, 'MERGE/DELETE/UPDATE', time-travel.
• Apache Hudi - copy-on-write/merge-on-read, upsert-optimisation, extractions incrémentielles.
• Choisissez en fonction de l'écosystème et des exigences d'upsert/streaming/flexibilité de l'évolution des schémas.

Catalogue et métastore

Un répertoire unique (Hive Metastore/Unity/Glue/Platform Répertoires) stocke les schémas, les lots, les versions, les droits.
Exigences : cohérence transactionnelle avec la couche tabulaire, prise en charge de plusieurs moteurs (Spark, Trino/Presto, Flink, dbt), audit/lineage.

Schémas et évolution

Schema contract : fixez les champs obligatoires, les types, la sémantique ; Versioner les sources ('schema _ version').
Évolution : ajout de champs optionnels, interdiction des changements cassants sans migration ; circuits automatiques de contrôle en piplines.
Segmentation PII : champs sensibles - en colonnes/tables distinctes avec cryptage et droits distincts.

Lot et lay-out des données

Date/heure - clé de base pour les événements ; dop. champs : 'country', 'product', 'tenant _ id'.
Hive-style путь: `s3://lake/bronze/payments/source=pspA/dt=2025-11-05/hour=13/part-0001. parquet`.
Clustering/triage : Z-order/Sort keys par champs souvent filtrés (player_id, pays).
Taille du fichier : Visez 128-1024 Mo ; évitez les « petits fichiers » (voir ci-dessous).
Colonnes virtuelles (Iceberg/Delta) pour la partitionnement caché.

Le problème des petits fichiers et compacts

Les sources effacent les petites cuves → la dégradation des scans et des métadonnées.
Solution : optimisation périodique/compaction (coalesce), planificateur de compaction-tâche, batch-micro-bundle sur ingestion, 'autoOptimize' (si disponible).
La stratégie merge-on-read vs copy-on-write est l'équilibre entre la latence d'écriture et la vitesse de lecture.

Ingest : batch, stream, CDC

CDC de l'OLTP (Debezium/connecteurs) → Bronze (minute de fraîcheur).
Stream (Kafka/Flink/Spark Structured Streaming) → Silver/Gold incrémentalement (upsert/merge).
Batch (rapports partenaires/CSV/JSON) - via des « récepteurs » avec des manifestes, le contrôle des prises par checksum.
Idempotency : clés (idempotency_key), dedup par (key, ts), filigranes (watermarks) pour les enregistrements arrivant plus tard.

Qualité des données (DQ) et lignage

Chèques DQ : exhaustivité, unicité des clés, fourchettes, intégrité des références (listes pays/devises), règles commerciales (RGG ≥ 0).
Ligne : Graphique des dépendances du rapport à la source, version du code du modèle et du snapshot de la table.
Contrôle des schémas : tests automatiques back/forward-compat qui bloquent les changements « cassants ».
Vérification des téléchargements : qui/quand/combien, lots rejetés, retraits.

Serving et accès

Moteurs SQL : Spark/Trino/Presto pour ad hoc et transformations ; dbt pour les modèles ELT.
Real-time/near-real-time : Pinot/Druid/ClickHouse comme vitrines ; Lakehouse est une source à travers le sink incrémental.
Partage de données : boule de table/snapshot pour les commandes externes sans copie (si prise en charge par le format).

Sécurité, PII et multi-ténacité

Cryptage : at-rest (KMS) et in-transit (TLS).
IAM/RBAC/ABAC : rôles au niveau du catalogue/table/colonne/ligne (masquage, politiques dynamiques).
Segmentation par région (localisation UE/Turquie/LatAm) : isolation des réservoirs et des pools informatiques.
Multi-tenance : nomespace/répertoires et préfixes de chemin, filtres par 'tenant _ id', en option - politiques row-level.
Audit d'accès : logs de lecture/modifications de métadonnées, rétentions et journaux non modifiables.

Gestion des coûts

Classes de stockage : chaud (souvent lu) dans la classe standard, archive - dans les classes froides/Glacier avec des politiques TTL.
Les lots/clusters réduisent les scans → moins de $ $ $.
Vitrines matérialisées pour les rapports coûteux ; cache des résultats BI.
Compaxn et « taille de fichier correcte » - moins de métadonnées et I/O.
Quotas et budgétisation : limites par grappes compute/jobs, rapports de valeur par datacet/commande.
Élimination des débris : 'VACUUM/REWRITE' en formats tabulaires, TTL Bronze.

DR et reproductibilité

Versioner les tables (time-travel) et les snapshots du catalogue.
Réplication croisée régionale des réservoirs et des métadonnées.
PITR : stockage des journaux de transaction des tables (Delta/Iceberg/Hudi) et des logs de pipline.
Game-day : exercices réguliers de récupération et de changement de région.

Observabilité et SLO

SLO de fraîcheur : Bronze ≤ 5 min, Argent ≤ 15-30 min, Or ≤ 60 min (exemple).
Métriques : volume/colle dans les fichiers, taille moyenne du fichier de parquet, temps de balayage, proportion de lots manqués, taux de compaction, coût/datacet, erreurs DQ, données tardives.
Alert : sursaut de petits fichiers, augmentation des coûts, dégradation de p95/p99, violation de DQ/schémas, retard de stream-sink.

Conventions de neuming et de cheminement (modèle)

s3://<lake>/<layer>/<domain>/<dataset>/
source=<sys>/      # для Bronze dt=YYYY-MM-DD/
hour=HH/
country=XX/

Noms des datacets : 'bets _ raw', 'payments _ cdc',' players _ silver ',' mart _ ggr _ daily '.
Colonnes de métadonnées : 'ingest _ ts',' source ',' schema _ version ',' trace _ id ',' tenant _ id '.

Exemples (généralisés)

1) Iceberg : table Silver avec lot caché par date

sql
CREATE TABLE silver. bets (
bet_id    BIGINT,
player_id   BIGINT,
country    STRING,
stake     DECIMAL(18,2),
win      DECIMAL(18,2),
event_ts   TIMESTAMP,
ingest_ts   TIMESTAMP,
schema_version INT
)
PARTITIONED BY (days(event_ts))
TBLPROPERTIES ('format-version'='2');

2) Delta : upsert incrémental de CDC

sql
MERGE INTO silver. players t
USING bronze. players_cdc s
ON t. player_id = s. player_id
WHEN MATCHED THEN UPDATE SET
WHEN NOT MATCHED THEN INSERT;

3) Politique TTL pour Bronze (idée)

bronze/: keep 30 days silver/: keep 365 days (non-PII), 90 days (PII masked)
gold/marts/: keep 2–3 years (aggregated)

Chèque d'implémentation

1. Sélectionnez un format de tableau (Delta/Iceberg/Hudi) et un catalogue ; s'aligner sur les moteurs (Spark/Trino/Flink/dbt).
2. Identifiez les médailles, les règles TTL et la responsabilité des équipes.
3. Fixez les contrats schema, le contrôle de l'évolution, la segmentation PII et le cryptage.
4. Concevoir lay-out : lots, clés de qualité, taille de fichier cible ; activez la compaction.
5. Configurez ingest (CDC/stream/batch) avec idempotence et déduplication.
6. Incluez le DQ/lineage, le répertoire de métadonnées et l'audit.
7. Identifiez les SLO de fraîcheur/coût, les métriques de dashboard et les alertes.
8. Organiser DR : snapshots/réplication/récupération + exercices réguliers.
9. Normaliser les neurones et les chemins, les métacolons ('ingest _ ts', 'source', 'schema _ version').
10. Mettez les vitrines Gold et le serving real-time dans les moteurs OLAP/RT appropriés.

Anti-modèles

Un « sac » commun sans couches et TTL → le chaos et l'explosion du coût.
Le lot est seulement dans le temps, sans tenir compte du pays/produit → des scans lourds.
Threads produisant des milliers de petits fichiers/heure, sans compaction.
L'absence de contrôle des schémas et du QD → les changements « cassants » et la méfiance à l'égard des rapports.
Mélange de PII avec des vitrines Gold sans masquage/séparation des droits.
Hardcode des droits d'accès au niveau des bacs au lieu du catalogue et des politiques tabulaires.

Résultats

Le lac de données moderne pour iGaming est un Lakehouse avec un format de tableau ouvert, un catalogue unique et un modèle de médaillon. La discipline des schémas/lots, la compaction contre les petits fichiers, DQ/lineage, la sécurité PII et l'hygiène de valeur transforment la couche de yutlake en une base durable : bon marché pour le stockage, rapide pour la lecture, prévisible par SLO et prêt pour le DR. Une telle base est mise à l'échelle pour les pics de tournoi et soutient à la fois l'analyse de batch, et vitrines near-real-time.