Umgang mit historischen Daten

1) Zweck und Grundsätze

Das Ziel: Vergangene Zustände so zu speichern und zu verarbeiten, dass Berichte, Modelle und Untersuchungen reproduzierbar, genau und konform sind.

• Time-aware by design: explizite Zeitmodelle in Diagrammen und Abfragen.
• Reproducibility: Derselbe Bericht für Datum D liefert immer das gleiche Ergebnis.
• Auditability: Nachweisbare Herkunft (Lineage), unveränderliche Schichten, WORM wo nötig.
• Kostenbewusst: Archivschichten, Kompression, Cold Storage mit klaren SLAs.
• Privacy-by-Design: PII-Management bei rückwirkenden Transaktionen und rechtlichen Anfragen.

2) Zeitmodelle

Ereigniszeit: Zeit des tatsächlichen Ereignisses (Wette, Einzahlung).
Verarbeitungszeit: wenn das System die Aufzeichnung verarbeitet hat (kann abweichen).
Bitemporal: Speicherung von Event- und Processing-Zeit für nachträgliche Bearbeitungen.
Gültigkeitsintervalle: 'valid _ from', 'valid _ to', 'is _ current'.
As-of-queries: Stichprobe von Daten „wie sie zum Zeitpunkt T wussten“.

sql event_time TIMESTAMP, -- event time processed_at TIMESTAMP, -- TIMESTAMP valid_from processing time, -- start of version validity valid_to TIMESTAMP, -- end of validity (NULL if current)
is_current   BOOLEAN

3) Speicherschichten und Formate

Lakehouse: Bronze (raw append-only) → Silber (clean/SCD/normalization) → Gold (Vitrinen).
ACID-форматы: Delta/Iceberg/Hudi (MERGE/Upsert, time-travel, snapshots).
Tiered storage: hot/warm/cold + WORM für regulatorische Artefakte.
Partitionierung: „event _ date“, „market“, „tenant“; Clustering/Z-Order nach häufigen Prädikaten (user/game/provider).

4) Historisierung von Messungen (SCD)

SCD I: Überschreiben - für unkritische Bearbeitungen.
SCD II: Vollständige Geschichte; Es ist für die RG/KYC/Kanäle des Verkehres/Attributes der Spiele empfehlenswert.
SCD III: „vorher/nachher“ - seltene Vergleichsfälle.

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. rg_status <> u. rg_status OR t. country <> u. country) THEN
UPDATE SET is_current = FALSE, 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);

5) Geschichte der Fakten: Bilder und Bitemporal

Snapshots: Eine Momentaufnahme der Aggregate am Ende des Tages/Monats (z.B. Wallet Balance) - beschleunigen die Erstellung historischer Berichte.
Bitemporale Fakten: Wir erfassen Ereignis- und Verarbeitungszeiten, um späte Korrekturen von retrospektiven Berechnungen zu unterscheiden.
Exactly-once Geschichte: dedup von 'event _ id' + idempotent MERGE.

6) Zeitreise und Reproduzierbarkeit

Zeitreise: Lesen von Tabellen „zum Zeitpunkt T“ für Debugging, Incidents, Sweeps.
Versionierung der Logik: Transformationsartefakte (SQL/DBT-Versionen, Container) und „logic_version“ -Beschriftungen in Ausgabetabellen.
Frozen Outputs: Gold-Berichtsartefakte werden erfasst und nicht neu geschrieben, Hash und Exportprotokoll sind verfügbar.

sql
SELECT
FROM silver. fact_bets VERSION AS OF 1678901234567
WHERE event_date = DATE '2025-10-31';

7) Backfill и Reprocessing

Backfill: Primär/Nachladen des historischen Bereichs.
Reprocessing: Neuberechnung nach Behebung von Fehlern oder Änderung von Geschäftsregeln.

• Idempotenz (MERGE/upsert), Bereiche, Quoten, „dark run“ (dry-run) mit Vergleich der Metriken.
• Beschriften Sie das Ergebnis: 'recalc _ reason', 'logic _ version', 'reprocessed _ at'.

1. Freeze current Gold; 2) DLQ/DQ-Prüfung; 3) Silberlauf; 4) Vergleich der Metriken; 5) Neumontage von Gold; 6) Veröffentlichung und Unterschrift.

8) Überleitung der Genauigkeit (reconciliation)

Prüfsummen: Abstimmung von Umdrehungen/Mengen mit OLTP, PSP/Provider.
Zweikreisprüfung: Unabhängige Pipeline auf Probe (A/B-Vergleich).
Toleranzen: z.B. Abweichung GGR ≤ 0. 2% pro Tag.

sql
-- Duplicates
SELECT transaction_id, COUNT() c
FROM silver. payments
GROUP BY transaction_id
HAVING COUNT() > 1;

-- Unknown Currencies/Markets
SELECT p. currency
FROM silver. payments p
LEFT JOIN ref. currencies r ON r. code = p. currency
WHERE r. code IS NULL;

9) Währungen, Zeit, Kalender: historische Korrektheit

FX am Datum des Ereignisses: Wir fixieren 'fx _ rate _ used' und 'fx _ source'.
Lokale Marktzeiten: DST/Zeitzonen über das Kalenderverzeichnis.
Feiertage/Saisonalität: separate Kalendertabelle, die in Modellen und Berichten verwendet wird.

sql
SELECT p. transaction_id,
p. amount_orig,
r. rate AS fx_rate_used,
p. amount_orig r. rate AS amount_base,
r. fx_source
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';

10) PII, Compliance und Legal Hold

PII-Minimierung: Pseudonymisierung, separates geschütztes Mupping.
DSAR/RTBF: Berechenbare Projektionen und selektive Bearbeitungen historischer Schichten; Ausnahmen von der gesetzlichen Aufbewahrungspflicht werden dokumentiert.
Legal Hold: Flags zum „Einfrieren“ von Löschungen auf Bereiche/Objekte, WORM für meldepflichtige Artefakte.
Audit: Unveränderliche Zugriffs- und Exportprotokolle.

11) DQ und Lineage für Geschichte

yaml table: silver. fact_bets slo:
completeness_percent: 99. 5 freshness_minutes: 60 rules:
- name: unique_bet type: unique columns: [bet_id]
severity: critical
- name: market_known type: in_set column: market set_ref: ref. markets
- name: ts_in_range type: temporal expression: "event_time BETWEEN date_sub(now(), interval 5 year) AND now()"

Lineage: Wir erfassen die Versionen der Eingänge/Transformationen/Ausgänge; Der Abhängigkeitsgraph ist für Retro-Änderungen erforderlich.

12) Leistung und Kosten

Partitionierung: nach Datum/Markt/Tenant; aggressives Clustering durch 'user _ pseudo _ id '/' game _ id', wenn wir häufig filtern.
Formate: Parkett + Statistiken/Kompression; regelmäßig VACUUM/OPTIMIZE.
Materialisierung: precompute für „teure“ historische Aggregationen; Snapshots für Quartals-/Jahresabschlüsse.
Archivierung: Übersetzung von Altpartien in Cold Storage (SLA zur Wiederherstellung wird dokumentiert).
Sampling: nur für Forschungsaufgaben, nicht für Regulatoren/Finanzen.

13) Historische Fiches für ML

Feature Registry: Jede Ficha hat eine Formel, Besitzer, SLO, 'model _ version'.
Online/Offline-Konsistenz: Eine Codebasis von Transformationen, Wiederholbarkeitstests.
Merkmalsdrift: PSI/KS nach Perioden, Speicherung historischer Verteilungen.

14) Anfragemuster

As-of (am Datum): Reproduzierbarkeit der Berichte.
Cohort-Analyse: Kohorten von Anmeldungen/Ersteinlagen, rollende Fenster.
Slowly changing facts: корректные join’ы с SCD II (`event_time BETWEEN valid_from AND COALESCE(valid_to, '9999-12-31')`).

sql
SELECT b. bet_id, u. rg_status
FROM silver. fact_bets b
JOIN dim. users_scd u
ON u. user_pseudo_id = b. user_pseudo_id
AND b. event_time >= u. valid_from
AND (u. valid_to IS NULL OR b. event_time < u. valid_to);

15) Prozesse und RACI

R (Responsible): Data Engineering (Modelle/SCD/Backfill), Data Platform (ACID/Archiv), Finance/Compliance (Abstimmungen/Aufbewahrungsanforderungen).
A (Accountable): Head of Data/CDO.
C (konsultiert): Legal/DPO (DSAR/RTBF/Legal Hold), SRE (Kosten/SLA), Architektur.
I (Informed): BI/Produkt/Marketing/Operations.

16) Fahrplan für die Umsetzung

1. ACID-Tabellen mit Zeitreisen (Delta/Iceberg/Hudi) und Basispartitionierung.

2. SCD II für Schlüsseldimensionen (Benutzer/Spiele/Anbieter).

3. Tägliche Snapshots kritischer Aggregate (GGR Daily).

4. DQ-as-Code (uniqueness/in_set/temporal) + Lineage-Graph.

• Bitemporale Fakten, As-of-API/SQL-Templates, Runbooks Backfill/Reprocessing.
• FX/Kalender/DST-Anreicherung, Abgleich OLTP↔DWH/provaydery.
• Cold Storage Archivierung, WORM für Berichtspakete, Legal Hold.

• Vollständige „replay & what-if“ Automatisierung, Vergleich von Metriken und Regressionsalerts.
• Historische Fichy und ML Drift Control, Chargeback zu Lagerkosten.
• Dokumentation von „as-of“ -Metriken und reproduzierbaren Berichten.

17) Checkliste vor dem Verkauf

• Tabellen unterstützen Zeitreisen; VACUUM/RETENTION Richtlinien vereinbart.
• SCD II für kritische Messungen implementiert; join's getestet.
• Bilder von Schlüsselaggregaten auf D/M sind verfügbar und mit Glitzern getestet.
• DQ-Regeln sind aktiv; lineage zeigt Ein-/Ausgänge und Versionen der Logik an.
• DSAR/RTBF/Legal Hold auf historischen Schichten getestet.
• Archivierung und Wiederherstellung aus Cold Storage werden dokumentiert und validiert.
• Kosten der Lagerung unter Kontrolle (Kosten/GB, Cold Share, SLA Recovery).

18) Häufige Fehler und wie man sie vermeidet

Kein explizites Zeitmodell: event/processing/validity hinzufügen.
FX „rückwirkend“: immer Kurs zum Zeitpunkt des Ereignisses, 'fx _ source' speichern.
Falsche Join's mit SCD: Verwenden Sie das Gültigkeitsintervall und nicht 'is _ current'.
Mutierende Gold-Vitrinen: Die gemeldeten Outputs müssen unveränderbar (oder mit Versionierung) sein.
Ohne Lineage/DQ: keine Nachweisbarkeit und Checkpoints - geben Sie diese vom ersten Tag an ein.
Unüberschaubare Kosten: Schalten Sie heiße Parteien aus, saugen Sie, übersetzen Sie in kalt.

19) Glossar

As-of Query ist eine Abfrage von Daten „wie sie zum Zeitpunkt des T aussahen“.
Bitemporal - gleichzeitige Fixierung von Event und Verarbeitungszeit.
Snapshot ist eine materialisierte Momentaufnahme des Zustands/der Aggregate am Ende der Periode.
Zeitreise - Lesen Sie historische Versionen von Tabellen.
WORM - Unveränderliche Speicherung (Write Once Read Many).

20) Das Ergebnis

Der Umgang mit historischen Daten ist nicht nur eine „Long-Storage“, sondern eine Zeitdisziplin: explizite Event/Processing/Bitemporal-Modelle, SCDs und Snapshots, reproduzierbare As-of-Requests, strenge Abstimmungen und Compliance-Kontrollen, Beobachtbarkeit und eine sparsame Speicherarchitektur. Wenn Sie diesem Leitfaden folgen, erhalten Sie eine solide historische Grundlage für Reporting, Analytics und ML, die resistent gegen Audits und Änderungen der Geschäftslogik ist.