Datenspeicher

1) Zweck und Rolle von DWH in iGaming

• Einheitliche Definitionen der Metriken (GGR/NGR, ARPPU, Retention, Churn).
• Reproduzierbare Berichte für Regulierungsbehörden und interne Stakeholder.
• Schnelle Vitrinen für BI/Bedienpanels und Quellen für Modelle.
• Qualitätskontrolle, Lineage und Sicherheit auf Plattformebene.

2) Architektonische Optionen

2. 1 Classic DWH

ETL → DWH (Stern/Schneeflocke) → BI.
Vorteile: überschaubare Modelle, starke Konsistenz.
Nachteile: teure Downloads, aufwendiger Backfill, eingeschränkte Flexibilität.

2. 2 Lakehouse DWH

Bronze/Silber/Gold auf ACID-Tabellen (Delta/Iceberg/Hudi) + SQL/MPP-Engine.
Vorteile: Single-Storedge, Zeitreisen, einfaches Reprocessing.
Nachteile: erfordert Layer-Disziplin und DQ, ausgereifte Orchestrierung.

2. 3 Hybrid

Lakehouse als „Quelle der Wahrheit“ (Bronze/Silber), DWH-März in MPP (ClickHouse/Pinot/Druid/Cloud DWH) für High-Speed-Lesen.
Vorteile: Balance von Kosten und Leistung, flexible Schaufenster.
Nachteile: doppelte Unterstützung für Schaltungen und Rollen, Synchronisierung erforderlich.

Empfehlung: für iGaming - Lakehouse + DWH-März (Hybrid). Bronze/Silber - standardisiert, Gold/Echtzeit-Marts - dienen der Leselast.

3) Datenmodellierung

3. 1 Stern und Schneeflocke

Faktentabellen: eng, ereignisbezogen: 'fact _ bets',' fact _ payouts', 'fact _ payments'.
Maße: 'dim _ users' (SCD), 'dim _ games', 'dim _ providers', 'dim _ markets'.
Eine Schneeflocke ist in Silber (Normalisierung) angemessen, ein Stern in Gold (Lesen).

3. 2 Data Vault 2. 0 (Integrationskern)

Hubs (Geschäftsschlüssel), Links (Beziehungen), Satellites (Kontext/Geschichte).
In Silver für langlebige Provider/PSP-Integrationen anwenden.

3. 3 SCD I/II/III

SCD II für RG/KYC/Kanäle und Spielattribute (RTP/Volatilität).
Strikte Intervalle' valid _ from/valid _ to', korrekte Join-Zeiten.

4) Download: ETL/ELT, CDC und Inkremente

ELT-Ansatz: Upload in Silver → Transformation in DWH.
CDC: Debezium/Logreplikation aus OLTP; Merges sind idempotent.
Inkremente: durch das Wasser der Zeit ('updated _ at> max_loaded_ts') und/oder Hash-Delta.
Backfill/Reprocessing: Zeitreisen, Reichweiten, Quoten, Dry-Run-Vergleiche.

sql
MERGE INTO silver. payments s
USING stage. payments_delta d
ON s. transaction_id = d. transaction_id
WHEN MATCHED THEN UPDATE SET
WHEN NOT MATCHED THEN INSERT;

5) Semantische Schicht und Metriken

Metrics Store/Semantic Layer: einheitliche Formeln GGR/NGR/Conversion/LTV.
Versionierung von Metriken und „as-of“ -Berechnungen für die Reproduzierbarkeit.
Konventionen: Namen der Metriken, Einheiten, Währung (Basis EUR) und 'fx _ source'.

6) Schaufenster und Serving

Gold-Vitrinen: denormalisiert, SLA-Bereitschaft (z.B. bis 06:00 Uhr Lok.) .
Einsatzmärze: ClickHouse/Pinot/Druid für 1- bis 5-minütige Tafeln.
Export: CSV/JSON/PDF + hash; Unveränderliche Pakete (WORM) für Regulatoren.

sql
CREATE OR REPLACE VIEW gold. ggr_daily AS
SELECT
DATE(b. event_time) AS event_date,
b. market,
g. provider_id,
SUM(b. stake_base) AS stakes_eur,
SUM(p. amount_base) AS payouts_eur,
SUM(b. stake_base) - SUM(p. amount_base) AS ggr_eur
FROM silver. fact_bets b
LEFT JOIN silver. fact_payouts p
ON p. user_pseudo_id = b. user_pseudo_id
AND p. game_id = b. game_id
AND DATE(p. event_time) = DATE(b. event_time)
JOIN dim. games g ON g. game_id = b. game_id
GROUP BY 1,2,3;

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

Schema-first: JSON/Avro registry + Kompatibilitätstests (consumer-driven).
DQ-как-код: completeness/validity/uniqueness/FK/range/temporal.
Reaktionsrichtlinien: critical → fail + DLQ; major/minor → Tag und Bericht.
DQ-Beobachtbarkeit: Freshness/Completeness/Validity Dashboards, ein Trichter verlorener Datensätze.

8) Sicherheit, Privatsphäre und Wohnsitz

PII-Minimierung: Benutzer über Pseudo-ID; Muppings separat.
RLS/CLS: Zugriff Zeile für Zeile/Nach-Spalte nach Rollen und Jurisdiktionen.
Verschlüsselung: TLS in-transit; at-rest - KMS/CMK mit Rotation.
Datenresidenz: separate Verzeichnisse und Schlüssel für den EWR/UK/BR; Verbot regionalübergreifender Join's ohne Grund.
DSAR/RTBF: Berechenbare Projektionen und selektive Bearbeitungen; Legal Hold auf die gemeldeten Artefakte.

9) Leistung und Kosten (Cost Engineering)

Partitionierung: nach Datum/Markt/Tenant; Clustering/Z-Order nach 'market', 'provider _ id', 'game _ id', 'user _ pseudo _ id'.
Formate: Parkett + Statistiken und Kompression; OPTIMIZE/VACUUM nach Zeitplan.
Materialisierung: stabile Aggregate und Zusammenfassungstabellen; Vermeiden Sie „dicke“ Join's on the fly.
Quoten/Chargeback: Budgets für schwere Anfragen/Replays; Berichte cost/query, cost/GB.
Tiered storage: hot/warm/cold; klare SLA Erholung.

10) Beobachtbarkeit und Management

Pipeline-Metriken: Dauer, Volumen, Retrays, Lags, Fehlertoleranz.
DWH-Metriken: Antwortzeiten/Wettbewerbsfähigkeit/Cash-Hits/Kosten.
Lineage: Graph von den Quellen bis zu den Berichten; Impact-Analyse bei Änderungen.
SLO: Freshness Silver p95 ≤ 15 мин; Gold täglich - fertig bis 06:00; Validity ≥ 99. 9%; Completeness ≥ 99. 5%; Verfügbarkeit ≥ 99. 9%.

11) Multitenant und Domänenisolierung

Aufteilung nach Schema/Datenbank/Katalog in Tenant/Markt.
Kontingente und Ressourcengruppen; Einschränkung der „lärmenden Nachbarn“.
Export-/Importrichtlinien zwischen Tenanten, standardisierte Verträge.

12) Datenregister und Dokumentation

Datenkatalog: Eigentümer, SLA, Schema, Beispiele, DQ-Regeln, Lineage.
Metriken/Dashboards: Karten mit Formeln und Verantwortlichen.
Änderungsprotokoll: Versionen der Logik, Migrationen, Auswirkungen (Impact).

13) Prozesse und RACI

R (Responsible): Data Engineering (Silver/Gold Modelle, DAG's), Data Platform (infra, registry, DQ).
A (Accountable): Head of Data/CDO.
C (Consulted): Compliance/Legal/DPO, Finance (FX/GGR), Risk (RG/AML), SRE (SLO/стоимость).
I (Informed): BI, Produkt, Marketing, Operationen.

14) Fahrplan für die Umsetzung

1. Lakehouse Bronze/Silber (ACID-Tabellen), CDC/Inkremente für Zahlungen/Gameplay.

2. Erste Gold-Vitrinen (GGR Daily, Umbau), SLA bis 06:00 Uhr.

3. DQ-as-Code (10-15 Regeln) + Freshness/Completeness Dashboards.

4. Der Datenkatalog und die zugrunde liegende semantische Schicht der Metriken.

• SCD II для users/games/providers; Erweiterung von Domains.
• Einsatzmärze (ClickHouse/Pinot) für Echtzeit/Near-Real-Time Panels.
• Lineage/Impact-Analyse, DSAR/RTBF-Verfahren, Regionalisierung (EWR/UK).

• Auto-Simulation von Änderungen (Dry-Run), Replikationen und Vergleich von Metriken.
• Chargeback/Quoten, Kosten-Dashboards; DR-Übungen und Zeitreise Erholung.
• Autogenerierung der Dokumentation von Schaufenstern und Metrikkarten.

15) Beispiele für SQL-Vorlagen

sql
CREATE TABLE silver. fact_bets (
bet_id STRING PRIMARY KEY,
user_pseudo_id STRING NOT NULL,
game_id STRING NOT NULL,
stake_ccy DECIMAL(18,2) NOT NULL,
currency CHAR(3) NOT NULL,
stake_base DECIMAL(18,2) NOT NULL,
market CHAR(2) NOT NULL,
event_time TIMESTAMP NOT NULL
);

sql
SELECT b. bet_id, u. rg_status
FROM silver. fact_bets b
JOIN dim. users_scd u
ON u. user_pseudo_id = b. user_pseudo_id
AND b. event_time >= u. valid_from
AND (u. valid_to IS NULL OR b. event_time < u. valid_to);

sql
SELECT market, DATE(event_time) d, COUNT() n
FROM silver. fact_bets
GROUP BY market, DATE(event_time)
HAVING n = 0;

16) Checkliste vor dem Verkauf

• Schemes and contracts in the register, compatibility tests green.
• CDC/Inkremente und MERGE-Verfahren sind idempotent.
• Gold-Vitrinen haben SLAs, die Formeln der Metriken sind festgelegt.
• DQ-Regeln sind aktiv (critical → fail + DLQ), Freshness/Completeness Dashboards.
• RBAC/ABAC, Verschlüsselung, Gebietsansässigkeit, Zugriffsprotokolle.
• Lineage/impact enthalten; time-travel/backup/DR geprüft.
• Kosten unter Kontrolle: Parteien, Clusterbildung, Materialisierung, Quoten.

17) Anti-Muster und Risiken

„One Fat DWH ohne Schichten“: eine Mischung aus Roh- und Meldedaten → Chaos und teure Korrekturen.
Volles Reload täglich ohne Not: Nutzen Sie die Increments/CDC.
Gold ohne Besitzer und Formeln: das Fehlen einer einzigen Version der Wahrheit → Streitigkeiten und Rückschritte.
PII in analytischen Schichten: Muppings getrennt halten, CLS/RLS.
Keine DQ/Lineage: keine Nachweisbarkeit für Regulatoren/Audits.
Unüberschaubare Kosten: keine Parties/Optimierungen/Quoten.

18) Glossar (kurz)

DWH ist ein Data Warehouse für Konsolidierung und Analyse.
Lakehouse - Datensee + ACID-Tabellen und SQL-Engine.
CDC - Erfassen Sie Änderungen von OLTP.
SCD sind langsam wechselnde Messungen (I/II/III).
Die Gold-Vitrine ist eine verbrauchsfertige Berichtstabelle/Darstellung.
Semantic Layer - einheitliche Definitionen von Metriken und Attributen.

19) Das Ergebnis

Die moderne DWH für iGaming ist keine „große Tabelle“, sondern eine überschaubare Plattform: Bronze/Silber/Gold-Schichten, strenge Verträge und DQs, einheitliche Metriken und Lineage, Privatsphäre und Wohnsitz, Leistung und Wirtschaftlichkeit. Durch den Aufbau eines Lakehouse + DWH-März-Hybrids erhalten Sie eine schnelle und überprüfbare Entscheidungsfindung, die für Audits, Skalen und neue Märkte bereit ist.