Data Lake und zentrale Speicherung

(Abschnitt: Technologie und Infrastruktur)

Kurze Zusammenfassung

Data Lake ist die Basisschicht der zentralen Lagerung von Rohstoffen und konsolidierten Datasets. Für iGaming akzeptiert es Wett-/Zahlungs-/Spielprotokolle, Affiliate-Uploads, CDCs von OLTPs und gibt sie Analytik, Anti-Fraud, CRM und BI. Moderne Praxis - Lakehouse: offene Säulenformate + ACID-Tabellenschicht + einheitliches Verzeichnis + Transaktionen/Datenversionen. Der Schlüssel zum Erfolg ist die Disziplin der Schemata und Partitionierung, Wertmanagement, PII-Sicherheit und eine strenge Betriebskultur (DQ, Lineage, DR).

Die Rolle von Data Lake in der iGaming-Plattform

Single Point of Truth für Analytics: Speichern Sie rohe und gereinigte Daten unabhängig von Quelle und Format.
Flexibilität: Unterstützung von Batch und Streaming (CDC/Connectors, Event-Streams).
Evolution: Von rohen Bronzen zu konformen Silber- und Gold-Geschäftsvitrinen.
Verantwortungsteilung: Prod-Services schreiben in Bus/Staging, Analytics/ML verbraucht aus Lake-Schichten.

Architekturmodelle: Lake vs Lakehouse

Data Lake (S3/ADLS/GCS + Parkett/ORC): Schema-on-read, kostengünstiger Speicher, Formatflexibilität.
Lakehouse (Delta/Iceberg/Hudi over Parket): ACID-Transaktionen, upsert/merge, time-travel, compact files, vacuum, indexing/clustering.
Praxis: Für iGaming ist Lakehouse als Hauptschicht und externe OLAPs (ClickHouse/BigQuery/Snowflake/Pinot) als Schaufenster und spezielle Engines von Vorteil.

Medaillonschichtmodell

Bronze (Raw/Staging): Rohdateien aus Quellen (CDC, Log-Dumps, CSV-Partner, Webhooks). Minimale Validierung, „wie es ist“.
Silber (Conformed): Reinigung/Dedup, Normalisierung von Währungen/Zeitzonen, Typanpassung, SCD-Messungen, konsistente Schlüssel.
Gold (Marts/Serving): Aggregate für GGR/NGR/LTV/Retention, materialisierte Vitrinen unter BI/CRM/Anti-Fraud.
TTL: aggressiv bei Bronze, moderat bei Silber, langfristig bei Gold-Aggregaten.

Formate und Tabellenebenen

Säulenweise: Parkett (de facto Standard), ORC.

• Delta Lake - Transaktionen, 'MERGE', Zeitreisen, Optimierung/Vakuum, Z-Order.
• Apache Iceberg - Tabellen mit Manifesten/Schnappschüssen, versteckte Partizipation, 'MERGE/DELETE/UPDATE', Zeitreisen.
• Apache Hudi - copy-on-write/merge-on-read, upsert-Optimierung, inkrementelle Extraktionen.
• Wählen Sie je nach Ökosystem und Upsert/Streaming/Flexibilität der Schaltungsentwicklung.

Katalog und Metastasen

Der einheitliche Katalog (Hive Metastore/Unity/Glue/платформенные die Kataloge) bewahrt die Schemen, partizii, die Version, des Rechtes.
Anforderungen: Transaktionskonsistenz mit Tabellenebene, Unterstützung mehrerer Engines (Spark, Trino/Presto, Flink, dbt), audit/lineage.

Diagramme und Entwicklung

Schema-Vertrag: Fixieren Sie Pflichtfelder, Typen, Semantik; versionieren ('schema _ version').
Evolution: optionale Felder hinzufügen, brechende Änderungen ohne Migrationen verbieten; automatische Scheckschaltungen in Pipelines.
PII-Segmentierung: Sensible Felder - in separate Spalten/Tabellen mit Verschlüsselung und separaten Rechten.

Partitionierung und Lay-Out von Daten

Datum/Stunde - Basisschlüssel für Ereignisse; zusätzliche Felder: „country“, „product“, „tenant _ id“.
Hive-style путь: `s3://lake/bronze/payments/source=pspA/dt=2025-11-05/hour=13/part-0001. parquet`.
Clustering/Sortierung: Z-Order/Sort Keys nach häufig gefilterten Feldern (player_id, Land).
Dateigröße: Ziel 128-1024 MB; Vermeiden Sie „kleine Dateien“ (siehe unten).
Virtuelle Lautsprecher (Iceberg/Delta) zur verdeckten Partizipation.

Problem mit kleinen Dateien und Komprimierung

Quellen streamen kleine Chunks → Abbau von Scans und Metadaten.
Die Lösung: periodisch optimize/compaction (coalesce), compaction task scheduler, batch-micro-bundle auf ingestion, 'autoOptimize' (falls vorhanden).
Merge-on-read vs copy-on-write policy - Balance zwischen Schreiblatenz und Lesegeschwindigkeit.

Injection: Batch, Stream, CDC

CDC von OLTP (Debezium/Connectors) → Bronze (minutenlange Frische).
Stream (Kafka/Flink/Spark Structured Streaming) → Silber/Gold inkrementell (upsert/merge).
Batch (Partnerberichte/CSV/JSON) - über „Receiver“ mit Manifesten, Kontrolle der Takes durch checksum.
Idempotency: Schlüssel (idempotency_key), dedup durch (key, ts), „Wasserzeichen“ (watermarks) für später ankommende Datensätze.

Datenqualität (DQ) und Lineage

DQ-Schecks: Vollständigkeit, Eindeutigkeit der Schlüssel, Bereiche, referenzielle Integrität (Länder-/Währungslisten), Geschäftsregeln (GGR ≥ 0).
Liniedge: Graph der Abhängigkeiten vom Bericht zur Quelle, Version des Modellcodes und des Tabellen-Schnappschusses.
Schaltungssteuerung: Automatische Back-/Forward-Compat-Tests, die „brechende“ Änderungen blockieren.
Download-Audit: wer/wann/wie viele, abgelehnte Chargen, Retrays.

Serving und Zugriff

SQL-Engines: Spark/Trino/Presto für Ad-hoc und Transformationen; dbt für ELT-Modelle.
Echtzeit/near-real-time: Pinot/Druid/ClickHouse als Schaufenster; Lakehouse ist eine Quelle durch inkrementelle Sink.
Data Sharing: Sharing von Tabellen/Snapshots an externe Befehle ohne Kopien (sofern vom Format unterstützt).

Sicherheit, PII und Multi-Tenant

Verschlüsselung: at-rest (KMS) und in-transit (TLS).
IAM/RBAC/ABAC: Rollen auf Verzeichnis-/Tabellen-/Spalten-/Zeilenebene (Masking, dynamische Richtlinien).
Segmentierung nach Regionen (Lokalisierung EU/Türkei/LatAm): Isolierung von Baketten und Rechenpools.
Multi-Tenant: Namespace/Verzeichnisse und Pfadpräfixe, Filter nach 'tenant _ id', optional - row-level policies.
Zugriffsprüfung: Metadaten-Lese-/Änderungsprotokolle, Retention und nicht modifizierbare Protokolle.

Kostenverwaltung

Speicherklassen: heiß (oft gelesen) in der Standardklasse, Archiv - in kalten/Glacier-Klassen mit TTL-Richtlinien.
Partitionierung/Cluster reduzieren Scans → weniger als $ $.
Materialisierte Vitrinen für teure Berichte; BI-Ergebnis-Cache.
Kompression und „richtige Dateigröße“ - weniger Metadaten und I/O.
Kontingente und Budgetierung: Grenzen für Compute-Cluster/Jobs, Kostenberichte pro Dataset/Team.
Müllentsorgung: 'VACUUM/REWRITE' in Tabellenformaten, TTL Bronze.

DR und Reproduzierbarkeit

Versionierung von Tischen (Zeitreisen) und Katalog-Snapshots.
Regionale Replikation von Backets und Metadaten.
PITR: Speicherung von Tabellen-Transaktionsprotokollen (Delta/Iceberg/Hudi) und Pipelineprotokollen.
Spieltag: regelmäßige Übungen zur Bergung und Umschaltung von Regionen.

Beobachtbarkeit und SLO

Frische SLO: Bronze ≤ 5 min, Silber ≤ 15-30 min, Gold ≤ 60 min (Beispiel).
Metriken: Volumen/Anzahl der Dateien, durchschnittliche Größe der Parkettdatei, Scan-Zeit, Anteil der fehlenden Parties, Kompositionsrate, Kosten/Dataset, DQ-Fehler, verspätete Daten.
Alerts: Anstieg der kleinen Dateien, Kostensteigerungen, p95/p99-Degradation, DQ/Schemas-Verletzung, Stream-Sync-Rückstand.

Namenskonventionen und Pfade (Vorlage)

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

Die Namen der Datasets lauten: 'bets _ raw', 'payments _ cdc', 'players _ silver', 'mart _ ggr _ daily'.
Spalten-Metadaten: 'ingest _ ts', 'source', 'schema _ version', 'trace _ id', 'tenant _ id'.

Beispiele (zusammengefasst)

1) Iceberg: Silbertisch mit versteckter Party nach Datum

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: inkrementelles Upsert von 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) TTL-Politik für Bronze (Idee)

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

Checkliste für die Implementierung

1. Wählen Sie das Tabellenformat (Delta/Iceberg/Hudi) und das Verzeichnis; Stimmen Sie mit den Engines (Spark/Trino/Flink/dbt) überein.
2. Definieren Sie die Medaillonschichten, die TTL-Regeln und die Verantwortung der Teams.
3. Fixieren Sie Schema-Verträge, Evolutionskontrolle, PII-Segmentierung und Verschlüsselung.
4. Lay-out entwerfen: Partitionen, Sortenschlüssel, Zieldateigröße; compaction aktivieren.
5. Konfigurieren Sie ingest (CDC/stream/batch) mit Idempotenz und Deduplizierung.
6. Aktivieren Sie DQ/Lineage, Metadatenkatalog und Audit.
7. Definieren Sie Frische/Kosten SLOs, Metrik Dashboards und Alerts.
8. Organisieren Sie DR: die snapschoty/Replikation/Wiederherstellung + das regelmäßige Lernen.
9. Standardisieren Sie Namensgebung und Pfade, Metacolons ('ingest _ ts', 'source', 'schema _ version').
10. Bringen Sie Gold-Vitrinen und Echtzeit-Serving in geeignete OLAP/RT-Engines.

Antimuster

Eine gemeinsame „Tasche“ ohne Schichten und TTL → Chaos und Kostenexplosion.
Partitionierung nur zeitlich ohne Berücksichtigung des Landes/Produkts → schwere Scans.
Streams, die Tausende von kleinen Dateien/Stunde erzeugen, ohne Compaction.
Fehlende Kontrolle über Schemata und DQs → „brechende“ Änderungen und Misstrauen gegenüber Berichten.
Mischen von PII mit Gold-Vitrinen ohne Maskierung/Rechteteilung.
Hardcode von Zugriffsrechten auf Baket-Ebene anstelle von Verzeichnis- und Tabellenrichtlinien.

Ergebnisse

Der moderne Data Lake für iGaming ist ein Lakehouse mit offenem Tabellenformat, einheitlichem Katalog und Medaillonmodell. Die Disziplin der Schemata/Parties, Compaction versus Small Files, DQ/Lineage, PII-Sicherheit und Kostenhygiene verwandeln die Lake-Schicht in ein nachhaltiges Fundament: günstig für die Lagerung, schnell für die Lektüre, vorhersehbar durch SLO und DR- bereit Zeitfenster.