Datenspeicher und OLAP-Modelle
(Abschnitt: Technologie und Infrastruktur)
Kurze Zusammenfassung
Data Warehouse (DWH) - Die Referenzschicht von iGaming Analytics: Berichte an Regulierungsbehörden, Profitabilität nach Produkten/Märkten, Kohorten-LTV, Betrugsbekämpfung, CRM-Segmentierung und Echtzeit-Dashboards. Nachhaltiges DWH basiert auf einem klaren Datenmodell (Star/Snowflake/Data Vault), robuster Integration (ETL/ELT + CDC), durchdachter Leistung (Säulenmotoren, Parties, MVs), strenger Metriken-Semantik, Sicherheit/PII und Kostenmanagement.
Architektonische Ansätze
Klassische DWH (Kimball vs Inmon)
Kimball (Dimensional/Star/Snowflake): schnelle Berichtsvitrinen; Fokus auf Fakten und Dimensionen, SCD-Geschichte. Schnelles Time-to-Valley.
Inmon (Corporate Information Factory): normalisierter Kern + Vitrinen; zeitlich härter, aber streng und zentral.
Data Vault 2. 0
Hubs-Links-Satellites: ein skalierbares „Roh“ -Modell zur Integration von Änderungsquellen und Audits. Darüber werden Star-Vitrinen aufgebaut.
Data Lake / Lakehouse
Data Lake: Rohdateien (Parkett/ORC) + Verzeichnisse (Hive/Glue/Unity/Metastore).
Lakehouse: Single Layer für Batch/Stream, ACID Table (Delta/Iceberg/Hudi), Time-Travel, Upsert/Merge, Compact Files, Z-Order/Clustering.
Medallion (Bronze–Silver–Gold)
Bronze: Rohdaten (raw) + CDC.
Silber: gereinigt und konform.
Gold: Geschäftsvitrinen/Metriken/Würfel.
Geeignet für Hybriden (Kafka → Bronze; Silver в Lakehouse; Gold в ClickHouse/BigQuery/Snowflake).
OLAP Modelle: Star, Snowflake, Data Vault
Sternenschema (Stern)
Tabelle Fact: Transaktionen (Wetten, Einlagen, Sitzungen).
Dimensionen: Spieler, Spiel, Anbieter, Datum/Uhrzeit, Geo, Anziehungskanal.
Vorteile: einfache Joins, prognostizierte Leistung.
Snowflake
Normalisierung von Dimensionen (Hierarchien von Ländern/Regionen/Städten, Produkthierarchien).
Vorteile: weniger Duplizierung; Minus - mehr Joins.
Data Vault → Star
Die Rohänderungen addieren wir in DV (Audit, vollständige Reproduzierbarkeit), die Berichtsvitrinen bauen wir als Star/Snowflake auf.
Integration: ETL/ELT, CDC, langsame Änderungen
Pipeline
Outbox/CDC von OLTP (Postgres/MySQL) → Kafka/ → Bronze-Konnektoren.
ELT: Reinigung, Dedup, Normalisierung in Silber.
Geschäftslogik und Aggregationen in Gold/Vitrinen.
SCD (Slowly Changing Dimensions)
Typ 1: Überschreiben (für nicht wesentliche Felder).
Typ 2: Geschichtlichkeit (datierte Versionen) - Standard für Profile/Kanäle/Preise.
Typ 3: Speichert ein Paar von Werten (selten).
sql
-- insert new dimension version
INSERT INTO dim_player (player_sk, player_id, country, valid_from, valid_to, is_current)
SELECT gen_sk(), s. player_id, s. country, now(), '9999-12-31', true
FROM staging_player s
LEFT JOIN dim_player d ON d. player_id = s. player_id AND d. is_current = true
WHERE d. player_id IS NULL OR d. country <> s. country;
-- closing the old version
UPDATE dim_player d
SET valid_to = now(), is_current = false
FROM staging_player s
WHERE d. player_id = s. player_id AND d. is_current = true AND d. country <> s. country;Semantische Ebene und „wahre“ Metriken
Geben Sie eine einzelne Schicht von Metriken (semantic layer) ein: Definitionen von GGR, NGR, Nettoeinlagen, ARPPU, LTV, Churn, Retention Cohorts.
Metriken als Code (dbt metrics/LookML/Semantic Layer) → die gleichen Formeln in allen Berichten.
Kalender: Datums-/Stundentabelle mit den Attributen TZ/Regionen/Wochenende/Kampagnen.
Speicher und Motoren: Auswahl unter Profil
Kolonnen- und Cloud-DWHs
ClickHouse: ultraschnelle Scans/Aggregationen, materialisierte Darstellungen, Projektionen; ausgezeichnet für Events/Telemetrie und Marketing-Schaufenster.
BigQuery: serverless, scale, automatische Caches/Cluster; Preis pro Scan; praktisch für gemischte Lasten und Ad-hoc.
Snowflake: Compute/Storage-Filiale, On-Demand-Cluster, Zeitreisen; transparent für verschiedene Teams.
Redshift/Vertica/Pinot/Druid: Optionen unter OLAP/Echtzeit.
Tuning für das Profil
Partitionierung nach Datum/Region/Kanal.
Clustering/Sortierung nach Filter-/Joynschlüssel.
Komprimierung und Kodierung von Wörterbüchern.
Voraggregationen (Rollup, Cubes), materialisierte Ansichten.
Approx Funktionen (HyperLogLog/approx_distinct) für billige Schätzungen.
Leistungsdesign
Partitionierung und Clustering
Die Partei ist die Abteilgrenze. Tag/Stunde Parteien für Veranstaltungen.
Clustering (sort keys/Z-order) - Beschleunigt Bereiche und Join-s.
Materialisierte Ansichten (MV)
GGR/NGR-Vorrechnung nach Tagen/Ländern/Produkten.
Inkrementelles Update aus dem CDC-Stream.
sql
CREATE MATERIALIZED VIEW mv_ggr_daily
ENGINE = SummingMergeTree()
PARTITION BY toYYYYMMDD(ts)
ORDER BY (country, product_id, toDate(ts)) AS
SELECT toDate(ts) AS d,
country,
product_id,
sum(stake) AS stake_sum,
sum(win) AS win_sum,
sum(stake - win) AS ggr
FROM bets
GROUP BY d, country, product_id;Inkrementelle Modelle (dbt/ELT)
Strategien 'insert _ overwrite' nach Partitur, 'merge' nach CDC-Schlüssel, 'watermark' nach 'updated _ at'.
Join-Strategien
Replikation der Messungen in jedes Chargensegment (denorm).
Broadcast small dims; shuffle große Fakten nach Schlüssel sortiert.
Kosten: Steuerung und Optimierung
BigQuery/Snowflake: Scangröße begrenzen (Parties/Cluster entwerfen), Ergebniscache/materialisierte Ansichten einschließen, BI-Auto-Quests begrenzen.
ClickHouse: Größe der Parteien, Häufigkeit der Murges, Budget für die Lagerung (TTL für Rohveranstaltungen, Aggregationen sind langlebig).
Die Semantik der Metriken reduziert „doppelte“ Berechnungen.
Daten pruning: retention für Bronze, Aggregationen für Gold.
Datenqualität (DQ), Katalog, Lineage
DQ-Schecks: Vollständigkeit (completeness), Einzigartigkeit, Bereiche, Geschäftsregeln (z. B. GGR ≥ 0 in Aggregaten).
Data Catalog & Lineage: Tabellen/Feldbeschreibungen, Besitzer, PII-Klassifizierung, Trace vom Bericht zur Quelle.
Schemaüberwachung: Ereignisvertrag/CDC, Warnungen bei inkompatiblen Änderungen.
Sicherheit, Compliance und Multi-Tenant
PII-Segmentierung: einzelne Zonen, Maskierung/Pseudonymisierung, Spalten mit KMS-Verschlüsselung.
RBAC/ABAC: Rollen auf Projekt-/Diagramm-/Tabellen-/Zeilenebene (RLS), Wiehs für „need-to-know“.
Datenlokalisierung: Regionale Buckets/Warehouses (EU/TR/LATAM).
Zugangsaudit: Wer Schaufenster und Modelle gelesen/gewechselt hat.
DRs, Backups und Reproduzierbarkeit
Versionierung des Datencodes (dbt/git), der Dev/QA/Prod-Umgebung.
Metastasen/Katalogschnappschüsse + Tabellenversionierung (Zeitreise).
Retention/TTL Schichten Bronze/Silber/Gold; Export kritischer Vitrinen.
Game-Day: Wiederherstellung der Vitrinen, Überprüfung der Integrität der Metriken.
Echtzeit und hybride Schaufenster
Stream-to-OLAP: Kafka → ClickHouse/Pinot/Druid für Minutenvitrinen.
Materialisierte Ansichten + CDC für Fast-Online-Updates (5-15 Min.).
Die semantische Schicht bleibt einheitlich: Die Metriken sind in Echtzeit und Batch identisch.
Beispielvitrine „GGR nach Tag und Land“ (Generalized SQL)
sql
CREATE TABLE fact_bets (
bet_id BIGINT,
player_sk BIGINT,
game_sk BIGINT,
country_sk BIGINT,
stake DECIMAL(18,2),
win DECIMAL(18,2),
ts TIMESTAMP
) PARTITION BY DATE(ts);
CREATE TABLE dim_country (
country_sk BIGINT PRIMARY KEY,
iso2 STRING,
region STRING,
valid_from TIMESTAMP,
valid_to TIMESTAMP,
is_current BOOL
);
-- Showcase
CREATE MATERIALIZED VIEW mart_ggr_daily AS
SELECT
DATE(ts) as d,
c. region,
SUM(stake) AS stake_sum,
SUM(win) AS win_sum,
SUM(stake - win) AS ggr
FROM fact_bets f
JOIN dim_country c ON c. country_sk = f. country_sk AND c. is_current
GROUP BY d, c. region;Checkliste für die Implementierung
1. Identifizieren Sie Quellen und Domänen, fixieren Sie das Wörterbuch der Metriken.
2. Modell wählen: DV für Roh-/Revisionsschichten + Star für Schaufenster.
3. Entwerfen Sie Parteien/Cluster für Schlüsselanforderungen und Fenster.
4. Konfigurieren Sie CDC/ELT, SCD-Richtlinien und Surrogate-Keys.
5. Geben Sie die semantische Ebene (Metriken als Code) und den Datums-/Stundenkalender ein.
6. Erstellen Sie MVs/Voraggregationen für teure Berichte.
7. Aktivieren Sie DQ/Catalog/Lineage und Schemaüberwachung.
8. Definieren Sie RBAC/PII/Lokalisierung, Verschlüsselung, Auditing.
9. Konfigurieren Sie die Überwachung von p95/p99, Kosten, Alerts für Degradation und Überverbrauch.
10. Regelmäßige DR-Übungen und Reproduzierbarkeit der Umgebung.
Antimuster
„Eine gigantische Tatsache ohne Parteien“ → Scans von Terabyte und die Rechnung wächst.
Inkonsistente Definitionen von Metriken in verschiedenen Dashboards.
Mangel an SCD2, wo das Geschäft Historizität erfordert.
Vorzeitige Normalisierung der Messungen: zusätzliche Joins und langsame Berichte.
Rohdaten ohne DQ-Schecks und Lineage → Berichte „über nichts“.
Keine Retention/TTL → Mülllagerung und Kostenexplosion.
Ergebnisse
Das robuste iGaming-DWH ist ein klares Modell (DV→Star), ein einheitliches Metrikvokabular, korrekte Partitionen/Clustering, materialisierte Vitrinen, strenge DQ/Lineage sowie RBAC/PII/Lokalisierung. Fügen Sie hybrides Streaming für Frische, ELT-getriebene und Kostendisziplin hinzu - und erhalten Sie eine nachhaltige Analyseplattform, die für Turniere, regulatorische Berichte und Ad-hoc-Forschung ohne Überraschungen in p99 und Budget skalierbar ist.