ETL/ELT-Prozesse

1) Zweck und Kontext

ETL/ELT-Pipelines ermöglichen vorhersehbares Laden, Transformieren und Veröffentlichen von Daten für Reporting (GGR/NGR, Regulatoren), Analytics/ML und Operational Panels.

ETL: Umwandlung vor dem Laden in DWH/Lakehouse (seltener in modernen Stacks).
ELT: Zuerst laden wir nach Lakehouse (Bronze/Silber), dann transformieren wir SQL/Engines (empfohlen).

2) Referenzarchitektur

1. Ingest/Edge: HTTP/gRPC/Batch, CDC von OLTP, Provider-Upload- S3/FTP.
2. Bronze (raw, append-only): unveränderliche payload's, Parties nach Datum/Markt/Tenant.
3. Silber (clean/conform): Normalisierung, Dedup, Handbücher, SCD, FX/Zeitzonen.
4. Gold (serve): denormalisierte Schaufenster für BI/Regulator/Modelle.
5. Orchestrierung: Airflow/Dagster/Prefect (DAG 'and, SLA, Retrays, Shifts).
6. DQ/Contracts: Schema Registry + DQ-как-код, consumer-driven tests.
7. Beobachtbarkeit: Pipeline-Metriken, Lineage, Logs, Cost-Dashboards.

3) Auswahl ETL vs ELT

Praxis: in iGaming - ELT + CDC: schnell laden, dann standardisieren und zählen.

4) Inkremente und CDC

• CDC (Debezium/Log-Replikation): Änderungen an OLTP → Bronze → MERGE in Silber.
• Wasserzeichen nach Zeit: 'updated _ at> max_loaded_ts'.
• Hash-Diff: Vergleich 'md5 (Zeile)' für den Änderungsdetektiv.
• Upsert/MERGE: Idempotenz von Downloads.

sql
MERGE INTO silver. payments s
USING stage. payments_delta d
ON s. transaction_id = d. transaction_id
WHEN MATCHED THEN UPDATE SET
WHEN NOT MATCHED THEN INSERT;

5) Verträge und Regelungen

Schema-first: JSON/Avro/Protobuf in Registry; 'schema _ version' in Ereignissen/Dateien.
Evolution: rückwärtskompatibel (nullbare Ergänzungen); breaking - '/v2'+ doppelter Eintrag.
Erforderliche Felder: 'event _ time (UTC)', 'event _ id', 'trace _ id', 'user _ pseudo _ id', 'market'.

6) DQ-as-Code (Mindestsatz)

yaml table: silver. payments owner: data-payments slo:
freshness_minutes: 15 completeness_percent: 99. 5 rules:
- name: unique_tx # uniqueness of transactions type: unique columns: [transaction_id]
severity: critical
- name: currency_whitelist type: in_set column: currency set: [EUR,USD,GBP,TRY,BRL]
severity: major
- name: amount_positive type: range column: amount_base min: 0. 01 severity: critical
- name: fk_user type: foreign_key column: user_pseudo_id ref_table: dim. users_scd severity: critical

7) Orchestrierung: DAG 'und, Abhängigkeiten, SLA

DAG-Design: von den Quellen zu den Schaufenstern; Explizite Abhängigkeiten zwischen Aufgaben.
Retrays und Idempotenz: Backoff, „saubere“ Wiederholungen, Checkpoint.
Verschiebungen (Catchup): Ordentliches Dogon verpasster Perioden.
SLA: zum Beispiel Gold. täglich bereit bis 06:00 Uhr Ortszeit; Benachrichtigung über Verstöße.
Parametrierung: Märkte/Tenanten/Termine über vars; eine einzige Job-Vorlage.

8) Idempotenz und exactly-once

Auf ingest: Duplikate sind möglich → dedup durch'(event_id, source)'.
In Bearbeitung: upsert/merge; „reine“ Transformationsfunktionen.
In sink: Transaktionskommits oder idempotent writes; Kontrolle der „doppelten Buchführung“.
Outbox/Inbox: Transaktionale Veröffentlichung von Domänenereignissen aus OLTP.

9) Backfill и reprocessing

Backfill: primäre Füllung/historische Bereiche.
Reprocessing: Neuberechnung bei Änderung der Logik/Korrekturen.
Guardrails: Reichweitenlimits, Quoten, Zeitfenster, Dry-Run mit Metrikvergleich.
Kennzeichnung: „logic _ version“, „reprocessed _ at“, „recalc _ reason“.

10) Silber-/Goldsimulation

Silber (3NF/BCNF): Fakten 'fact _ bets/payments/payouts', Dimensionen 'dim _ users/games/providers/markets (SCD II)', Währungsstandardisierung/Zeitzone.
Gold: denormalisierte Schaukästen für BI/Regulator/Modelle; Unveränderliche Exportpakete (WORM) + Signatur.

Beispiel Gold: GGR Daily

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;

11) Privatsphäre und Wohnsitz

PII-Minimierung: Tokenisierung; Mappings von realen IDs in einer isolierten Schleife.
RLS/CLS: Zugriffsrichtlinien nach Rollen/Jurisdiktionen, Maskierung.
Residency: separate Verzeichnisse/Schlüssel für den EWR/UK/BR; Verbot regionalübergreifender Join's ohne Grundlage.
DSAR/RTBF & Legal Hold: selektive Bearbeitung, WORM-Archive für die Berichterstattung, Exportprüfung.

12) Beobachtbarkeit und SLO

• Freshness Silver p95 ≤ 15 min Gold täglich bereit bis 06:00 Uhr lok. Zeit.
• Completeness ≥ 99. 5%, Gültigkeit (Schema) ≥ 99. 9%.
• Erfolgsquote ≥ 99. 0%, MTTR Vorfälle ≤ 24-48 Stunden.

Dashboards: Freshness-Heatmap, DQ-Verlusttrichter, cost/query & cost/GB, lineage-graph.

13) Leistung und Kosten

Partitionierung: Datum/Markt/Tenant; Clustering/Z-Order nach Filter.
Formate: Parkett + ACID (Delta/Iceberg/Hudi), Kompression und Statistik.
Compact: Kampf gegen kleine Dateien (OPTIMIZE/VACUUM).
Materialisierung: stabile Aggregate; Vermeiden Sie riesige on-the-fly join 's.
Chargeback: Budgets, Quoten für Replays/Backfill; Planung im Low-Load-Fenster.

14) Beispiele für typische DAG-Aufgaben (Airflow Pseudocode)

python with DAG("elt_payments_daily", schedule="@daily", start_date=..., catchup=True) as dag:
extract = BashOperator(task_id="extract_cdc", bash_command="run_cdc_to_bronze. sh {{ ds }}")
load  = BashOperator(task_id="load_to_silver", bash_command="sql/run_merge_silver. sql {{ ds }}")
dq   = BashOperator(task_id="dq_checks", bash_command="dq/run_checks. sh silver. payments {{ ds }}")
gold  = BashOperator(task_id="build_gold_ggr", bash_command="sql/build_gold_ggr. sql {{ ds }}")
export = BashOperator(task_id="export_regulator", bash_command="export/run_worm_pack. sh {{ ds }}")

extract >> load >> dq >> gold >> export

15) Prozesse und RACI

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

16) Fahrplan für die Umsetzung

1. Lakehouse Bronze/Silber (ACID) + CDC/Inkremente für Zahlungen/Gameplay.

2. DQ-as-Code (10-15 Regeln) und grundlegende Freshness/Completeness Dashboards.

3. Erstes Gold-Showcase (GGR Daily) mit SLA „bis 06:00“, WORM-Export mit Unterschrift.

4. Orchestrierung von DAG und Alerta auf SLA/DQ.

• Domain-Erweiterung, SCD II für Benutzer/Spiele/Anbieter.
• Die semantische Schicht der Metriken; lineage/impact-Analyse; Backfill/Reprocessing-Verfahren.
• Regionalisierung (EWR/UK), RLS/CLS, Wertkontrolle (Quoten/Chargeback).

• Replay-Simulator (what-if), automatische Generierung der Vitrinen-/Metrikdokumentation.
• Kostenoptimierung (Clustering, Materialisierung, TTL, Compaction).
• DR-Übungen und Zeitreise Erholung.

17) Checkliste vor dem Verkauf

• Verträge/Regelungen im Register, Interoperabilitätstests grün.
• CDC/Inkremente und MERGE sind idempotent; dedup auf ingest.
• DQ-Regeln sind aktiv (critical → fail + DLQ), SLA-Dashboards sind konfiguriert.
• Gold-Vitrinen sind dokumentiert, Formeln der Metriken in der semantischen Schicht.
• RBAC/ABAC, Verschlüsselung, Wohnsitz, DSAR/RTBF/Legal Hold geprüft.
• Compact/OPTIMIZE/VACUUM nach Zeitplan; Limits für Backfill/Replays.
• Runbook 'und Vorfälle und reprocessing, Prüfung von Exporten (WORM + hash).

18) Anti-Muster und Risiken

Full reload „nur für den Fall“: CDC/Inkremente verwenden.
Mischung aus Roh- und Meldedaten: Bronze/Silber/Gold getrennt aufbewahren.
Keine DQ und Lineage: keine Nachweisbarkeit und Reproduzierbarkeit.
PII in analytischen Schichten: Muppings isolieren, CLS/RLS anwenden.
Monolithische „Nacht“ -Jobs: Zerkleinern, parallel zu den Parteien.
Kosten ignorieren: Achten Sie auf kleine Dateien, materialisieren Sie Aggregate, geben Sie Kontingente ein.

19) Glossar (kurz)

ETL/ELT - Extrahieren/Transformieren/Laden (vor/nach dem Laden).
CDC - Änderungen erfassen.
SCD - Historisierung von Messungen (I/II/III).
WORM - Unveränderliche Speicherung von Berichtspaketen.
Zeitreise - Lesen Sie historische Versionen von Tabellen.

20) Das Ergebnis

Moderne ETL/ELT sind keine Skripte, sondern eine verwaltete Plattform: Verträge und DQs, idempotente Inkremente/CDC, Bronze/Silver/Gold Layer Disziplin, Beobachtbarkeit und SLO, Privatsphäre und Wirtschaftlichkeit. Wenn Sie diesem Leitfaden folgen, erhalten Sie reproduzierbare und auditierbare Pipelines, die Berichte, Produkte und Modelle in großem Maßstab und ohne Überraschungen kontinuierlich versorgen.