GH GambleHub

Stapelverarbeitung von Daten

1) Zweck und Wert

Batch-Förderer bilden zuverlässige Tages-/Stundenvitrinen für:
  • Regulierungs- und Finanzberichterstattung (GGR/NGR, Steuern, RG/AML-Register).
  • BI und Produktanalysten (Kohorten, LTV, Konversionstrichter).
  • Präzisionsschweißen (OLTP↔DWH, Anbieter/PSP), Historisierung (SCD).
  • Vorbereitungs- und Trainingssets für ML.

Schlüsseleigenschaften: Vorhersagbarkeit, Vollständigkeit, Reproduzierbarkeit, niedrige Kosten pro Dateneinheit.

2) Architektur (Referenz)

1. Ingest (raw capture): HTTP/gRPC, CDC von OLTP, Provider-Uploads → Bronze.
2. Lakehouse: Bronze (raw, append-only) → Silver (clean/conform) → Gold (serve).
3. Orchestrierung: Airflow/Dagster/Prefect (DAG 'und, Abhängigkeiten, Retrays, SLA).
4. Verarbeitung: Spark/Trino/DBT/SQL-Engines; Partitionierung und ACID-Formate (Delta/Iceberg/Hudi).
5. DQ und Verträge: Schema Registry, DQ-Regeln (YAML/SQL), Verbrauchertests.
6. Serving: BI/Semantic Layer, Berichtsexporte (CSV/PDF/JSON + Hash), API/GraphQL.
7. Beobachtbarkeit: Pipelinemetriken, Lineage, Logs, Kosten (cost/GB, cost/query).

3) Frequenzen und SLAs

Täglich (D + 1 bis 06:00 Uhr Lok.) : GGR-Berichte, regulatorische Entladungen, Abstimmungen.
Stündlich/quasirealtime: operative Panels für Ops/Finanzen.
Woche/Monat: Finkonsolidierung, Modelle und Retroprozesse.

Empfohlene SLOs:
  • Die Gold-Tagesvitrinen sind bis 06:00 Uhr Ortszeit fertig.
  • Freshness Silver p95 ≤ 15 min für microbatch/ ≤ 2 h für Tag.
  • Completeness ≥ 99. 5%, Gültigkeit (Schema) ≥ 99. 9%.

4) Inkrementelle Downloads und CDC

Ansätze:
  • CDC (Change Data Capture): Debezium/Logreplikation → Bronze → Inkremente in Silber.
  • Wasserzeichen nach Zeit: 'updated _ at> max_loaded_ts'.
  • Hash-Vergleich: 'md5 (Zeile)' für den Änderungsdetektiv.
  • Upsert/Merge: idempotente Silber/Gold-Updates.
Beispiel MERGE (Delta/Iceberg):
sql
MERGE INTO silver. payments AS s
USING staging. payments_delta AS d
ON s. transaction_id = d. transaction_id
WHEN MATCHED THEN UPDATE SET
WHEN NOT MATCHED THEN INSERT;

5) SCD (Historisierung der Messungen)

SCD I: Überschreiben (Rechtschreibung, kleinere Korrekturen).
SCD II: voll funktionsfähige Historie ('valid _ from/valid _ to/is _ current').
SCD III: „vorher/nachher“ für kurze Vergleiche.

SCD II (Beispiel):
sql
MERGE INTO dim. users_scd t
USING stage. users u
ON t. user_pseudo_id = u. user_pseudo_id AND t. is_current = TRUE
WHEN MATCHED AND (t. country <> u. country OR t. rg_status <> u. rg_status)
THEN UPDATE SET t. is_current = FALSE, t. valid_to = CURRENT_TIMESTAMP
WHEN NOT MATCHED
THEN INSERT (user_pseudo_id, country, rg_status, valid_from, valid_to, is_current)
VALUES (u. user_pseudo_id, u. country, u. rg_status, CURRENT_TIMESTAMP, NULL, TRUE);

6) Backfill и Reprocessing

Backfill: primäre Füllung/historische Nachladung.
Reprocessing: Neuberechnung von Schaufenstern nach Änderungen der Logik/Datenkorrektur.

Grundsätze:
  • Idempotenz (MERGE/upsert), Bronze-Unveränderlichkeit, Versionierung der Logik.
  • Zeitreise für wiederholte Läufe; Metadaten-Snapshots.
  • Guardrails: Begrenzung von Bereichen, Quoten und wettbewerbsfähigen Jobs.
  • Dokumentation: Rundbuch mit Schritten und Abschlusskriterien.

7) Schichtsimulation

Bronze:
  • Nur Append, Parties' event _ date', 'jurisdiction', 'tenant'.
  • Wir speichern die ursprüngliche Payload (für Forensics), fixieren 'ingested _ at'.
Silver:
  • Normierung und Standardisierung: FK/Handbücher, Dedup, FX/Zeitzonen.
  • Fakten-/Maßtabellen (3NF/BCNF), SCD für Schlüsselmessungen.
Gold:
  • Denormalisierte Schaufenster für BI/Regulator/Finanzen, SLA-Bereitschaft.
  • Materialisierung von Aggregaten; unveränderliche Exportartefakte (Hash + WORM).

8) Datenqualität (DQ-as-Code)

Beispiel für YAML-Regeln für Silber:
yaml table: silver. payments slo:
freshness_minutes: 15 completeness_percent: 99. 5 rules:
- name: amount_positive type: range column: amount_base min: 0. 01 severity: critical
- name: currency_whitelist type: in_set column: currency set: [EUR,USD,GBP,TRY,BRL]
severity: major
- name: unique_tx type: unique columns: [transaction_id]
severity: critical
- name: fk_user type: foreign_key column: user_pseudo_id ref_table: dim. users_scd severity: critical

Reaktionsrichtlinien: critical → fail job + DLQ; major/minor → Tag + Bericht.

9) Semantische Schicht und Berichterstattung

Einheitliche Definitionen der Metriken (GGR/NGR, ARPPU, Retention) im semantic-layer/metrics-store.
Versionierung von Metriken; Integration mit BI/Exportpaketen.
Berichte: CSV/JSON/PDF + sha256, Upload Log und Legal Hold bei Bedarf.

10) Privatsphäre, Wohnsitz, Sicherheit

PII-Minimierung: Pseudonymisierung der Nutzer; Mupping - in einer separaten geschützten Schleife.
Datenresidenz: getrennte Verzeichnisse/Schlüssel nach EWR/UK/BR; Verbot regionenübergreifender Joins ohne Rechtsgrundlage.
Verschlüsselung: TLS in-transit; KMS/CMK at-rest; Kontrolle der Ausfuhren.
DSAR/RTBF: Berechenbare Projektionen, selektive Bearbeitungen; Prüfung der Zugriffe.
Legal Hold: WORM-Archive für regulatorische Artefakte.

11) Leistung und Kosten

Partitionierung nach Datum/Markt/Tenant; Z-Order/Cluster durch häufige Prädikate.
Formate: Parkett + ACID-Tabellen; Kompression/Statistik, OPTIMIZE/VACUUM.
Materialisierung: stabile Aggregationen in Gold; Vermeiden Sie „monolithische“ Jobs.
Quoten/Budgets: Chargeback nach Teams; Backfill-Limits/Heavy Requests.
Planung: Low-Load-Fenster (Nacht/Wochenende), Warteschlangen Prioritäten.

12) Beobachtbarkeit und Management

Pipeline-Metriken: Dauer, Erfolgsrate, Retries, Zeilen verarbeitet, Kosten/Abfrage.
DQ-Metriken: completeness, validity, uniqueness, FK-Fehler, drift.
Freshness heatmap: nach Domains und Märkten; SLA-Dashboards.
Lineage: Herkunft von Bronze bis Berichte; Impact-Analyse vor Änderungen.
Alerts: SLO-Budgets, DQ-Degradation, Verzögerungen, Kostensteigerungen.

13) Beispiele für SQL/Modelle

Währungsnormalisierung (Silber):
sql
CREATE OR REPLACE TABLE silver. payments AS
SELECT p. transaction_id,
p. user_pseudo_id,
p. currency,
p. amount_orig,
r. rate AS fx_rate_used,
p. amount_orig r. rate AS amount_base,
p. market,
CAST(p. event_time AS TIMESTAMP) AS event_time
FROM bronze. payment_events p
JOIN dim. fx_rates r
ON r. date = DATE(p. event_time)
AND r. ccy_from = p. currency AND r. ccy_to = 'EUR';
Tagesvitrine GGR (Gold):
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;
Vollständigkeitskontrolle (DQ SQL):
sql
SELECT market, event_date, COUNT() AS n
FROM silver. fact_bets
GROUP BY market, DATE(event_time) AS event_date
HAVING n = 0;

14) Prozesse und RACI

R (Responsible): Data Engineering (DAG ™ und, Silver/Gold Modelle), Data Platform (infra, Scheme Register, DQ).
A (Accountable): Head of Data / Chief Data Officer.
C (Consulted): Compliance/Legal/DPO (PII/retention), Finance (FX/GGR), Risk (RG/AML), SRE (SLO/стоимость).
I (Informed): BI/Produkt/Marketing/Operations.

15) Fahrplan für die Umsetzung

MVP (4-6 Wochen):

1. Lakehouse Bronze/Silber (ACID-Format), CDC/Inkremente für 2-3 Domänen.

2. DQ-as-Code: 10-15 Regeln für Zahlungen/Gameplay + CI-Validierung.

3. Erstes Gold-Showcase (GGR Daily) mit SLA bis 06:00 Uhr; Berichtsexporte + hash.

4. Freshness/Completeness/Cost Dashboards, Basic Alerts.

Phase 2 (6-12 Wochen):
  • SCD II для users/games/providers; Erweiterung von Domains.
  • Die semantische Schicht der Metriken; Abgleich mit OLTP/Anbietern (accuracy).
  • Verfahren backfill/reprocessing, lineage und impact-analysis, regionalisation (EEA/UK).
Phase 3 (12 + Wochen):
  • Auto-Simulation von Änderungen (Dry-Run), Budgets/Quoten, Chargeback.
  • Automatische Dokumentation (Datenproduktseiten), DR-Übungen und Time-Travel-Recovery.
  • Kostenoptimierung (Clustering, Materialisierung, TTL, Vakuum).

16) Checkliste vor dem Verkauf

  • Verträge und Regelungen im Register, Interoperabilitätstests grün.
  • Inkrementelle Downloads/CDC funktionieren, MERGE ist idempotent.
  • DQ-Regeln sind aktiv; critical → fail + DLQ; Meldung von Verstößen.
  • SLA/Frische/Fülle Dashboards; Alerts werden konfiguriert.
  • Die Richtlinien von PII/DSAR/RTBF/Legal Hold werden von Legal/DPO bestätigt.
  • Runbook ™ und Backfill/Reprocessing/DR getestet.
  • Kosten unter Kontrolle (cost/query, cost/GB, quouts).

17) Anti-Muster und wie zu vermeiden

Monolithische Nachtjobs: in unabhängige Schritte zerbrechen, parallel zu den Parteien.
Full-Reload ohne Not: Verwenden Sie Inkremente/CDC/Merges.
PII-Mix in der Analytik: Muppings getrennt halten, CLS/RLS anwenden.
Kein DQ/Lineage: Geben Sie den DQ-as-Code ein und verfolgen Sie die Herkunft.
„Manuelle“ Backfills: automatisieren und dokumentieren, Reichweiten begrenzen.
Unüberschaubare Kosten: Clustering, Materialisierung, Retention-Policies.

18) Glossar (kurz)

CDC - Erfassen Sie Änderungen von OLTP.
SCD sind langsam wechselnde Messungen (I/II/III).
Lakehouse - Datensee + ACID-Tabellen.
MERGE/Upsert - idempotente Aktualisierungsoperationen.
Zeitreise - Lesen Sie historische Versionen von Tabellen.
WORM - Unveränderliche Speicherung von Artefakten.

19) Das Ergebnis

Batch Processing ist die Disziplin der vorhersehbaren, reproduzierbaren und konformen Pipelines. Nach Schema-First-Prinzipien, Inkrementen/CDC, SCD-Historisierung, DQ-as-Code, Beobachtbarkeit und bewusster Ökonomie erhalten Sie jederzeit stabile Gold-Vitrinen und Berichte, die durch Funkeln überprüft und auditiert werden können.

Contact

Kontakt aufnehmen

Kontaktieren Sie uns bei Fragen oder Support.Wir helfen Ihnen jederzeit gerne!

Telegram
@Gamble_GC
Integration starten

Email ist erforderlich. Telegram oder WhatsApp – optional.

Ihr Name optional
Email optional
Betreff optional
Nachricht optional
Telegram optional
@
Wenn Sie Telegram angeben – antworten wir zusätzlich dort.
WhatsApp optional
Format: +Ländercode und Nummer (z. B. +49XXXXXXXXX).

Mit dem Klicken des Buttons stimmen Sie der Datenverarbeitung zu.