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!

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.