Data Lake und DWH für Casino: Diagramme, SLA-Downloads

Vollständiger Artikel

💡 18+. Technisches Material für Plattformen/Betreiber, Studios und Analyseteams. Kein Aufruf zum Spiel. Unter der Plattform verstehen wir PAM/Wallet/Cash/Boni/RG, unter den Anbietern - RGS/live/Jackpots/Zahlungsintegrationen.

1) Warum Data Lake Casino und DWH

Berichterstattung und Compliance: regulatorische Entladungen (GGR/NGR, KYC/AML, RG), Geldprüfung.

Produkt/Marketing: LTV/Retention, Segmentierung, A/B, Empfehlungen.

Operationen: Überwachung der Anbieter, PSP, SLA Live-Spiele und Kassen.

Lösungen auf Daten: Schnelle Vitrinen (DWH) über billige Langzeitlagerung (Lake).

Das Ergebnis: Lake speichert rohe und gereinigte Schichten, DWH gibt schnelle Anfragen und überschaubare Modelle.

2) Referenzarchitektur (lakehouse)


Sources (OLTP, Kafka, Webhooks, CDC)
│
├─Bronze (raw, append-only; Parquet/Delta/Iceberg)
│   ingestion_time, source_metadata, no schema changes in place
├─Silver (cleaned, conformed; dedup, PII masking, SCD2)
│   business keys, constraints, quality checks
└─Gold (marts; star/snowflake; cube tables, aggregates)
└─DWH/Query Engines (Snowflake/BigQuery/Trino/Spark SQL)

Форматы: Delta Lake / Apache Iceberg / Hudi (ACID в lake, time travel, MERGE).

Dateien: Parkett + ZSTD/Snappy, Ziel ~ 128-512 MB; Kompression von „kleinen Dateien“.

Katalog: Hive/Unity/Iceberg Katalog; Zonen „Bronze/Silber/Gold“ auf den Tanks pro Region/Tenant.

3) Domänenschemata (konzeptionell)

3. 1 Geldbeutel/Buchhaltung

`wallet_entry`: `entry_id`, `account_id`, `direction (debit	credit)`, `amount_minor`, `currency`, `reason`, `reference_id`, `occurred_at`, `region`, `tenant_id`, `trace_id`, `idempotency_key`.
Invariant: Summe auf dem Konto = Saldo (über Snapshot + Änderungsprotokoll).

3. 2 Wetten/Platzierung (RGS/live)

`bet`: `bet_id`, `round_id`, `player_id`, `game_id`, `stake_minor`, `currency`, `placed_at`, `brand/region`, `provider_id`, `in_bonus`.

`settlement`: `settlement_id`, `bet_id`, `round_id`, `win_minor`, `settled_at`, `jackpot_hit`, `bonus_state`.

3. 3 Zahlungen (Kasse/PSP/Krypto)

`payment_intent`: `intent_id`, `player_id`, `method`, `status`, `amount`, `currency`, `psp`, `created_at`.

'capture/refund/chargeback': separate Tabellen mit Verweisen auf 'intent _ id', 'psp _ ref', Ursachencodes.

Крипто: `txid`, `network`, `confirmations`, `finalized_at`.

3. 4 Boni/Vager/Jackpots

`bonus_grant`, `bonus_progress (wager)`, `jackpot_contribution`, `jackpot_payout`.

3. 5 Referenzen und Messungen

'dim _ player' (Pseudo-ID, Geo, Kanäle, RG-Status - ohne PII in der Analytik), 'dim _ game', 'dim _ provider', 'dim _ psp', 'dim _ brand', 'dim _ region', Kalendermessungen.

Schlüssel und Kompatibilität: Bei den Silver/Gold-Modellen gibt es stabile Geschäftsschlüssel ('bet _ id', 'round _ id', 'payout _ id', 'intent _ id') und die Semantik von „idempotenten“ Ereignissen.

4) Download-Streams: Streaming + Microbatches

Streaming (Kafka/Pulsar → Bronze): OLTP-Ereignisse und Webhooks, Outbox/CDC, Garantie „mindestens einmal“ mit Deduplizierung in Silber.

CDC (Debezium/Replication Log): Änderung der OLTP-Tabellen (Wallet/Payments) → Bronze.

Microbatches: PSP/Bank/Depot-Berichte (SFTP/API) → Bronze Raw Files → Normalisierung.

MERGE in Silver: Dedup durch 'idempotency _ key/event _ id', Beseitigung von Nachzüglern ('watermark'), SCD2 auf Messungen.

5) SLA-Downloads und Verspätungsfenster (Wasserzeichen)

5. 1 Typische SLAs (Benchmarks)

Wallet/Ledger Events: Bronze ≤ 1-2 min, Silber ≤ 5-10 min, Gold Marts ≤ 15 min.

Bets/settlements: Bronze ≤ 1-2 min, Silber ≤ 10 min, Gold ≤ 30 min.

Zahlungen (PSP-Webhooks): Bronze ≤ 5 min, Silber ≤ 15 min, Gold ≤ 30-60 min.

Kryptofinalität: abhängig vom Netzwerk; Schaufenster mit lag N Bestätigungen.

Tägliche Berichte von PSP/Banken: T + 1 bis 09:00 Uhr Ortszeit der Region.

5. 2 Fenster der Verspätung

Wasserzeichen nach Ereigniszeit ('occurred _ at') + Toleranzen:

Brieftasche/Gebote: 24-48 Stunden, Zahlungen/PSP: 72 Stunden (es gibt Retro-Webhooks), Krypto: bis zu 24 Stunden für seltene Rergs.
Späte Reprocess-Ereignisse: Neuberechnung von Gold-Vitrinen inkrementell (MERGE), Korrekturprotokoll.

5. 3 SLA-Kommunikation

Das Datenverzeichnis enthält die SLA-Attribute: 'freshness _ target', 'freshness _ status', 'expected _ lag _ p95', 'watermark'.

Dashboards von „Frische“ mit Alert in Verletzung.

6) Datenqualität (DQ) und Verträge

Datenkontrakte für jedes Thema: Avro/JSON-Schemata, Semver, Pflichtfelder, Geschäftsinvarianten (z. B. 'win _ minor ≥ 0', 'currency ∈ ISO-4217').

DQ-Prüfungen Silber: Eindeutigkeit der Schlüssel, referentielle Integrität, Bilanzprüfung (Wallet-Abgleich), Gültigkeit der PSP-Codes/Ursachen, Datumsbereiche.

Severity: 'ERROR' (blockieren), 'WARN' (markieren), 'INFO'.

Überwachung:% Unregelmäßigkeiten, Top-Ursachen, automatische Tickets.

Sampling & replay: Lagern Sie rohe Bronze zur Wiederverwendung.

7) PII, Wohnsitz und Sicherheit

Das PII-Showcase ist von der Analytik getrennt: in Silver/Gold - Alias, Masking/Hashes, Tokenization.

Datenresidenz: EU/UK/BR usw. - physisch getrennte Baquets/Kataloge; kein regionenübergreifendes Lesen ohne Zustimmung und Proxy.

Доступ: RBAC/ABAC (Lake/DWH), row-level security по `tenant/brand/region`.

Verschlüsselung: at-rest (KMS) und in-transit, Schlüssel pro Region/Marke, WORM-Prüfung von Zugriffen und Richtlinienänderungen.

Recht auf Vergessenwerden: Mechanismus zur Lokalisierung von Spieldaten ohne Löschung von Finanzunterlagen (De-Identifizierung).

8) Modellierung von Gold-Vitrinen (Stern)

8. 1 Faktentabellen

"fact _ bets' (Einsatz und Settlement pro Zeile/oder zwei Tabellen)," fact _ wallet _ entries "," fact _ payments "(Einzahlungen/Cashouts/Retouren)," fact _ bonus _ wager "," fact _ jackpot ".

8. 2 Messungen

`dim_date/time`, `dim_player` (pseudonymous), `dim_game`, `dim_provider`, `dim_psp`, `dim_brand`, `dim_region`, `dim_currency`.

8. 3 Metriken und Berechnungen

GGR/NGR, Hold/Frequency, RTP (nach Spiel/Anbieter/Region), Einzahlungskonvertierung, settle lag, success-rate PSP, cost-per-success, FX-PnL, jackpot contributions/payouts.

9) Leistung und Kosten

Partitionierung: durch 'occurred _ date' + 'region/tenant', manchmal 'game _ id' für Gold-Aggregate.

Clustering/Z-Order: durch 'player _ id', 'game _ id', 'psp', 'currency'.

Kompression und Vakuum: geplante „OPTIMIZE/COMPACT“, Entfernung von „hängenden“ Versionen (unter Berücksichtigung der gesetzlichen Retenschen).

Caches: result-cache/warehouse cache, materialisierte Ansichten für Hot Panels.

Indizes in DWH: Cluster/Segment (Snowflake clustering keys, BigQuery partition + cluster).

Kosten: kalte Bronze im Objektspeicher, heiße Gold/März-Aggregate - in DWH; Parkplatz/Auto-Scale.

10) Linie, Kataloge und Dokumentation

Datenkatalog (OpenMetadata/Amundsen/Collibra): Beschreibung der Tabellen, Eigentümer, SLA, PII-Felder, Zugriffsrichtlinien.

Linie: von der Quelle (Ereignis/CDC) zum Schaukasten und Bericht; Sichtbarkeit von Abhängigkeiten für sichere Änderungen.

Changelog-Schemata: semver und deprecate log; Kompatibilitätstests in CI-Pipelines.

11) Reconciliation (Datenabgleiche)

Täglich:

„wallet _ entry“ ↔ Gesamtbilanzen (Akkumulation ≡ Snapshot), Zahlungen: PSP/Bankberichte ↔ „fact _ payments“, Krypto: „txid/network“ ↔ „fact _ payments“.
Категории: `match`, `timing`, `missing_source`, `missing_platform`, `amount_mismatch`.
Alertas: Anteil „mismatch“> der Schwelle; aging ungeteert> N Tage.

12) Instanziierte SLA-Tabellen (Beispiel)

Domäne	Bronze (ingest)	Silber (Reinigung)	Gold (März)	Späte Ereignisse (Wasserzeichen)
Wallet	≤2 min	≤10 min	≤15 min	48 h
Bets/Settlements	≤2 min	≤10 min	≤30 min	48 h
Payments (PSP)	≤5 min	≤15 min	≤60 min	72 h
Crypto	realtime→finalnost	≤15 min	≤60 min	24 h
Reports (T+1)	06:00–08:00	≤09:00	≤10:00	7 d

13) Piplines: Woraus wir sammeln

Ingestion: Kafka Connect/Debezium, Cloud-Ingestion-Dienste, SFTP-Puller.

ETL/ELT: Spark/DBT/Trino/Beam/Flink (Streaming Silver), Airflow/Argo zur Orchestrierung.

Qualität: Große Erwartungen/Deequ/dbt Tests.

Monitoring: OpenTelemetry + Lake/DWH Metriken (freshness delay, job latency, cost).

Unfälle und Wiederholung: Reprocess aus Bronze, Dedup mit Schlüsseln, versionierte Piplines.

14) Checklisten

Architektur und Sicherheit

Lakehouse-Format (Delta/Iceberg/Hudi) mit ACID und Zeitreisen.
Trennung 'Bronze/Silber/Gold', Outbox/CDC als Hauptquellen.
PII-Isolation, Tokenisierung, RLS durch 'tenant/brand/region'.
Wohnsitz auf Baquet/Verzeichnisebene, Schlüssel/Geheimnisse pro Region.
WORM-Audit von Änderungen an Schemata/Richtlinien/Zugriffsregeln.

Qualität und SLA

Datenkontrakte und Semverdiagramme; Kompatibilitätstests.
Watermarks und reprocess, Schaufenster inkrementelle MERGE.
Frische Dashboards und SLA-Warnungen; Eigentümer jeder Tabelle.
Reconciliation on wallet/payments/crypto.

Leistung und Kosten

Partitionierung und Clusterbildung; Kompression von „kleinen Dateien“.
Materialisierte Vitrinen für Schlüsselberichte.
Autoscale/Autoparking, Retenschen und Archivpolitik.

15) Rote Fahnen (Anti-Muster)

BI und regulatorische Berichte treffen OLTP direkt.

Bronze „schreibt“ und verliert Rohdaten.

Es gibt keine Wasserzeichen, späte Ereignisse werden „beschnitten“.

Keine Deduplizierung durch 'idempotency _ key '/' event _ id' → Doppel in Gold.

PII und Geld aus verschiedenen Regionen werden ohne RLS und Wohnsitz zusammen gehalten.

Die Schemata ändern sich „leise“ (ohne Semver/Verträge), die Schaufenster brechen.

Millionen von kleinen Parkett-Dateien ohne Kompression → teure Anfragen.

Keine SLA/Frische Dashboards; „Überraschungen“ im Quartalsbericht.

16) Schlussfolgerung

Data Lake + DWH in iGaming ist nicht nur ein Repository, sondern ein kontrolliertes Ökosystem: standardisierte Schemata und Verträge, ACID-Lakehouse, klare Frische-SLAs und Verspätungsfenster, Qualität und Linie, PII-Sicherheit und Wohnsitz. Fügen Sie Reconciliation und Einsparungen bei Partitionierung/Compaction hinzu - und Sie haben die Grundlage für Reporting, Produktlösungen und Skalierung Ihres Unternehmens ohne nächtliche Migrationen und „manuelle Excel“.