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.
- 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.
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.
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.
- 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'.
- Normierung und Standardisierung: FK/Handbücher, Dedup, FX/Zeitzonen.
- Fakten-/Maßtabellen (3NF/BCNF), SCD für Schlüsselmessungen.
- 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).
- 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.