Analytics und ETL-Pipelines

(Abschnitt: Technologie und Infrastruktur)

Kurze Zusammenfassung

Die analytische Pipeline verwandelt die „rohen“ Betriebsereignisse von iGaming (Wetten, Einzahlungen, PSP-Webhooks, Spielprotokolle) in nachhaltige Metrikvitrinen (GGR/NGR, LTV, Retention, Anti-Fraud-Signale). Grundlagen: Einheitliches Schichtenmodell (Bronze/Silber/Gold), Instrumentaldisziplin DQ/Lineage, Inkrementalität und Idempotenz, Beobachtbarkeit und SLO, Wertsteuerung. Entscheidungen werden unter Berücksichtigung des Lastprofils (Turnierspitzen), der Regulatorik (PII/Lokalisierung) und der Datenfrischungsanforderungen des Unternehmens getroffen.

1) Architekturen: ETL vs ELT, Batch vs Stream

ETL (Extract → Transform → Load): Transformation vor dem Laden in DWH. Geeignet, wo Transformationen eine kontrollierte Umgebung/Geheimnisse vor der „Wolke“ erfordern.
ELT (Extract → Load → Transform): Rohstoffe in Lake/Lakehouse/DWH, dann SQL/Engine (dbt/SQL-Skripte). Praktisch für Säulenmotoren und flexible Iterationen.
Batch: geplante Fenster (alle 5/15/60 Minuten, nightly). Billig und vorhersehbar.
Stream: почти real-time (Kafka → Flink/ksqlDB → OLAP). Für Near-Real-Time-Vitrinen (5-60 Sekunden) und Anti-Fraud/CRM-Signale.
Hybrid: Bronze füllt sich mit Stream, Silber/Gold sind inkrementelle Batch-Modelle.

Empfehlung: in iGaming halten ELT + Streaming: Ereignisse über CDC/outbox → Bronze (eine Minute Frische), inkrementelle Transformationen in Silber/Gold.

2) Schichtenmodell (Medallion)

Bronze (Raw): Rohe Ereignisse/CDC ohne Geschäftslogik. Parkett/ORC-Formate, Schemata wie sie sind, minimale Validierung.
Silver (Conformed): Reinigung, Deduplizierung, ID-Normalisierung, SCD-Messungen, Vereinheitlichung von Währungen/Zeitzonen.
Gold (Marts): Geschäftsvitrinen (Fakten/Maße, Würfel), materialisierte Ansichten, Voraggregationen (Tage/Länder/Produkte).

Vorteile: Reproduzierbarkeit, transparente Evolution, unterschiedliche SLOs und TTLs nach Schichten.

3) Quellen und Verladung: CDC, Outbox, Dateien

CDC (Change Data Capture): Änderungsströme aus OLTP (Postgres/MySQL) mit Ordnungsgarantie und Idempotenz.
Outbox-Muster: Ereignisse werden in der Outbox-Tabelle/Sammlung in der Service-Transaktion aufgezeichnet → der Connector veröffentlicht in den Bus/See.
Datei-Upload: PSP-Uploads, Affiliate-Berichte; Verwenden Sie Manifeste, Checksum und Zulassungsverzeichnisse.

Praktiken: Quellen werden versioniert (Schema-Version), für jede Quelle gibt es einen Vertrag von Feldern und Qualitätserwartungen.

4) Orchestrierung: DAG, Abhängigkeiten, Deploy

DAGs: Explizite Abhängigkeiten (raw → staging → dims → facts → marts)

Aufgabenidempotenz: Wiederinbetriebnahme ohne Nebenwirkungen (partition-overwrite, 'MERGE '/upsert).
Trennung von Umgebungen: Dev/Stage/Prod, Förderung von Artefakten, „manual approval“ (manuelle Zulassung) für teure Backfill.
Planung: cron/Zeitfenster + Event-Trigger (nach Ankunft der Dateien/Parties).
Secrets: vom Secret Manager; Verbot von Geheimnissen im DAG-Code.

python with DAG("dwh_daily", schedule="0  ") as dag:
bronze = ingest_cdc(source="payments", partition=hour())
silver = dedup_normalize(input=bronze)
dims  = build_dimensions(input=silver)
facts = build_facts(input=silver, dims=dims)
marts = build_marts(input=facts)
bronze >> silver >> [dims, facts] >> marts

5) Datenqualität (DQ) und Lineage

DQ-Schecks: Vollständigkeit (count, late arrivals), Eindeutigkeit der Schlüssel, Bereiche/Domänenregeln (Betrag ≥ 0, Währung im Verzeichnis).
Auslöseschwelle: Hard Stop/Soft-Fail mit Alert abhängig von der Kritikalität der Tabelle.
Lineage/Verzeichnis: Reporte zur Quelle (Tabellen, Spalten, Metriken), Besitzer, Dokumentation, PII-Klassifizierung.
Schemaüberwachung: automatische Kompatibilitätstests (backward-/forward-kompatibel), alert auf „breaking“ -Änderungen.

6) Modellierung: SCD, surrogate Tasten, Normalisierung

SCD2 für Messungen: 'valid _ from/valid _ to/is _ current', surrogate key ('_ sk') und natural key ('_ id').
SCD1: Überschreiben für unwichtige Attribute (z. B. Schnittstellenlokal).
Surrogate-Tasten: stabile'_ sk 'für Join, natürliche Tasten für Einzigartigkeit.
Normalisierung der Dimensionen: Snowflake, wo die Hierarchien tief sind; ansonsten Star für die Geschwindigkeit.

7) Inkrementelle Modelle und Partitionierung

Wasserzeichen ('updated _ at', 'ingest _ ts'): nur neue/geänderte Zeilen lesen.
Inkrementelle Strategien: 'MERGE' durch Geschäftsschlüssel, 'INSERT OVERWRITE' durch Parteien, 'DELETE + INSERT' für kleine Parteien.
Partitionierung: nach Datum/Stunde/Region; Clustering (sort keys/Z-order) über Filter- und Join-Schlüssel.
Materialisierte Ansichten: GGR/NGR-Voraggregation, Cache beliebter Abschnitte.
Approx-Einheiten: HLL/approx_distinct für billige Top-N-Vitrinen.

sql
MERGE INTO fact_deposits f
USING staging_deposits s
ON (f. deposit_id = s. deposit_id)
WHEN MATCHED THEN UPDATE SET amount = s. amount, status = s. status, updated_at = s. updated_at
WHEN NOT MATCHED THEN INSERT (...)
VALUES (...);

8) Backfill, Reprocessing und History Management

Backfill: separate DAGs mit Ressourcenlimits und Fenstern; ein klares „Fenster der Wahrheit“ (z.B. 2024-01-01.. 2025-11-05).

Reprocessing: deterministische Transformationen → wiederholter Durchlauf ergeben das gleiche Ergebnis. Modellcodeversionen protokollieren

Zeitreise/Tabellenversionen: praktisch für Untersuchungen und DR „logische Fehler“.
Retraction: Richtlinie zum Datenrückruf (Löschung/Korrektur) mit Protokollierung.

9) CLO/SLA/SLO des Förderers

Frische: Bronze ≤ 1-5 min, Silber ≤ 15 min, Gold ≤ 60 min (Beispiel).
Zuverlässigkeit: DAG Erfolgsquote ≥ 99. x%.
Leistung: p95/p99 Knotendauer; Zeitbudget für die Partei.
Lag-Monitoring: Ingest-Stream-Rückstand, Warteschlangentiefe, „Late Data“ -Anteil.
Alerts: Frische/Volumen Störung, DQ-Fails, steigende Kosten für Scans, Abbau von MV.

10) Kosten: Vorhersage und Optimierung

Parties und Cluster minimieren das Scanvolumen.
Materialisierung der Hot Marker (Tage/Länder/Produkte).
Ergebnis-Cache/MVs für häufig verwendete Dashboards.
Überwachung der Häufigkeit von Neustarts (keine „alle 5 Minuten“ ohne Grund).
TTL: Aggressive Bronze Retention, Medium Silver, Long Gold (nur Aggregate).
Kapazitätsplanung: Katalogmetriken, Prognose von Turnier-/Kampagnenspitzen.

11) Sicherheit, PII und Lokalisierung

Datenklassifizierung: PII/Finanz/Operativ.
Verschlüsselung: in Ruhe und im Transit; KMS/rollenbasierter Zugriff.
De-Identifizierung: Hashing/Masking, separate Spalten mit Schlüsseln.
RLS/Vuhi für Multi-Tenant (von 'tenant _ id').
Lokalisierung: Lager- und Verarbeitungsbereiche nach Regionen (EU/TR/LATAM); Export nur an zugelassene Standorte.
Audit: Lesen/Schreiben in kritische Tabellen, Zugriff auf das Verzeichnis.

12) Beobachtbarkeit: Metriken, Protokolle, Traces

Pipelinemetriken: Dauer der Aufgaben, Warteschlange, Fehler, Retrays, Menge der verarbeiteten Bytes/Zeilen, Kosten.
Protokolle: strukturiert; Korrelation durch 'trace _ id '/' run _ id'.

Von der Quelle bis zum Schaufenster (ingest → transform → load → BI)

Dashboards: Frische der Schichten, Erfolg der DAGs, top teure Anfragen, p95/p99.

13) Tools (Benchmarks nach Rolle)

Orchestrierung: DAG-Orchestratoren (mit Planer, Retrays, Alert, Secrets).
Transformationen: SQL-Modellierung („Modelle als Code“), Unit-Tests der Modelle, Dokumentation.
DQ/Contracts: Prüf- und SLA-Frameworks für Datensätze.
Linie/Verzeichnis: automatische Konstruktion des Abhängigkeitsgraphen, Suche nach dem Besitzer.
Streaming: Fenster-/Aggregations-Prozessoren, sink/source-Konnektoren.

(Spezifische Anbieter werden für den Unternehmensstack und die Sicherheitsanforderungen ausgewählt.)

14) Musterbeispiele

GGR-Schaufenstervorlage (Generalized SQL)

sql
CREATE OR REPLACE TABLE mart_ggr_daily AS
SELECT
DATE(b. ts) AS d,
c. country_code,
SUM(b. stake) AS stake_sum,
SUM(b. win)  AS win_sum,
SUM(b. stake - b. win) AS ggr
FROM fact_bets b
JOIN dim_country c ON c. country_sk = b. country_sk AND c. is_current
WHERE b. ts >= DATE_SUB(CURRENT_DATE, INTERVAL 60 DAY)
GROUP BY d, c. country_code;

Inkrementelles Modell mit „Wasserzeichen“

sql
INSERT INTO fact_bets PARTITION (dt)
SELECT
FROM staging_bets
WHERE updated_at > (SELECT COALESCE(MAX(watermark), '1970-01-01') FROM _meta_watermarks WHERE table='fact_bets');
-- then update watermark

DQ-Prüfungen (Idee)

sql
-- 1) key uniqueness
SELECT deposit_id FROM fact_deposits GROUP BY deposit_id HAVING COUNT()>1;

-- 2) negative amounts (error)
SELECT FROM fact_deposits WHERE amount < 0;

15) Checkliste Umsetzung

1. Definieren Sie das Wörterbuch der Metriken (GGR/NGR/LTV/Retention) und Eigentümer.
2. Fixieren Sie die SLO Frische über die Bronze/Silber/Gold Schichten.
3. Standardisieren Sie Quellverträge (Schemata, DQ, SLA).
4. Erstellen Sie einen DAG-Graph mit idempotenten Schritten und isolierten Geheimnissen.
5. Implementieren Sie Inkrementalität (MERGE/overwrite nach Partitur) und „Wasserzeichen“.
6. Aktivieren Sie DQ (Critical/Soft Checks), Lineage und das Datenverzeichnis.
7. Passen Sie die Beobachtbarkeit (Metriken, Protokolle, Traces) und Alerts an.
8. Geben Sie die Retention/TTL und die Backfill/Reprocessing-Richtlinie ein.
9. Bieten Sie PII-Kontrolle, Verschlüsselung, RLS und Lokalisierung.
10. Verbringen Sie einen Spieltag: Simulieren Sie den Fall der Quelle, „brechen“ Schaltungen, Masse Backfill.

16) Antipatterns

„Eine Nacht ETL für alles“ ohne Parties und Inkrementalität.
Das Fehlen von DQ und Lineage → widersprüchliche Berichte und eine „Geisterjagd“.
Komplette Überarbeitung der Tabellen bei jeder Inbetriebnahme (Kostenexplosion).
Harte Bindung in Echtzeit ohne Puffer/Retrays.
Mischen Sie PII und öffentliche Schaufenster ohne Segmentierung und Maskierung.
Keine Retraktions-/Löschrichtlinie (Fehler können nicht korrigiert werden).

Ergebnisse

Die nachhaltige Analysepipeline bei iGaming ist der ELT + Streaming-Upload in ein Schichtenmodell mit hartem DQ/Lineage, inkrementellen Modellen, transparentem Orchestrator und messbaren SLOs. Fügen Sie Kostenkontrolle, PII/Lokalisierungsrichtlinien, regelmäßige Backfill/DR-Übungen hinzu - und Ihre Analyseplattform skaliert zuverlässig für Turnierspitzen und reagiert auf das Geschäft mit Daten der richtigen Frische und Qualität.