Datenaudit und Versionsfähigkeit

1) Warum es notwendig ist

Audit und Versionsfähigkeit schaffen Reproduzierbarkeit: Sie können jede Zahl erklären, die Berechnung wiederholen und Modelle/Schaufenster sicher entwickeln. Bei iGaming ist dies kritisch für Finanzen (GGR/NET), Zahlungen, KYC/AML, Responsible Gaming und regulatorische Berichterstattung.

• Tracing: Wer hat die Daten/Schema/Logik geändert und warum.
• Reproduzierbarkeit: Welche Version von Daten/Code/Modell hat den Bericht hervorgebracht.
• Releasesicherheit: Reversibilität (Rollback) und Vorhersagbarkeit von Änderungen.
• Compliance: Nachweisbare Protokolle für Regulierungsbehörden und interne Audits.

2) Konzepte und Ebenen der Versionsfähigkeit

1. Schema-Version: Entwicklung von Feldern/Typen/Semantik (SEMVER).
2. Dataset Version: Momentaufnahme/Ausschnitt zum Zeitpunkt; „Wahrheit“ für Bericht/Schulung.
3. Schaufenster/Modellversion BI (Data Product Version): Formeln, Filter, Aggregationen.
4. Version fich/ML-Modelle: Datum/Code/Hyperparameter/fici/Daten (Ende-zu-Ende).
5. Pipeline-Version: Transformationscode, Configs, Abhängigkeiten.
6. Datenvertragsversion: Anforderungen an den Erzeuger/Verbraucher (Regelung, SLA, Qualität).

3) Audit: Was zu protokollieren

Wer: Subjekt (Benutzer/Dienst), Rolle/Attribute (RBAC/ABAC).
Dass: tabliza/witrina/model/schema/kontrakt.
Wann: genaue Zeit, tz, Korrelationskennung.
Warum: Hinweis auf Task/Ticket/Release Note, Grund.
Was: Code/Modell-Version, Commit Hash, Container-Image.
Wie hat sich geändert: vorher/nachher (diff), Zeilenvolumen (Zeilen betroffen), Integritätsprüfung (Hash/Signatur).
Kontext: Umgebung (prod/stage), Domäne, Datenempfindlichkeit (Klasse).

Die Audit-Logs sind unveränderlich (append-only/WORM), signiert und im SIEM verfügbar.

4) Versionierungspolitik (Empfehlungen)

SEMVER: `MAJOR. MINOR. PATCH`

MAJOR - inkompatible Änderungen des Schemas/der Semantik.
MINOR - reversibel kompatible Ergänzungen (neue Felder/Spalten mit nullbaren, neue vNext-Vitrinen).
PATCH - Korrekturen ohne Vertragsänderung (Quality-Fix, Backfill).
Deprecation-Verfahren: Obsoleszenz-Fenster, Warnungen im Verzeichnis/CI, Abschaltdatum.
Release Notes: eine Seite pro Release: Was, warum, Risiken, Rollback-Plan.

5) Techniken in Lagerung und Strömen

Time-travel/Snapshots: Speicherung von Tabellenversionen; Möglichkeit, die Abfrage „wie bei T-0“ auszuführen.
SCD (Slowly Changing Dimensions): Typen 1/2/3 für Messungen (Spiele, Anbieter, Spieler).
CDC/CDF (Change Data/Capture & Feed): inkrementelle Änderungen für Fakten (Wetten, Auszahlungen, KYC).
Aktivitätsprotokoll (Audit Fact) - Eine separate Faktentabelle mit Bearbeitungs-/Hinzufüge-/Löschereignissen.
Integritätskontrolle: Hashes von Partitionen/Dateien, Signieren von Paketen, Abgleich von Aggregaten.

6) Entwicklung von Schemata und Datenkontrakten

Vertrag als Code: Schema, Typen, Feldpflicht, zulässige Werte, Frische SLA, DQ-Regeln.
Kompatibilität: Fügen Sie das Feld → MINOR hinzu; haben die Art/Semantik der MAJOR- → mit Migration und Dual-Write geändert.
CI-Gate: Der PR-Wechsler wird gesperrt, wenn die Kompatibilität gestört ist oder es keine Release Notes gibt.
Verzeichnis/Registry: Speichert aktive/veraltete Versionen und Besitzer.

7) Versionsfähigkeit in BI und Metriken

Zertifizierte „Gold“ -Vitrinen: verankerte KPI-Semantik (GGR, ARPPU, Retention).
Dual-Run: Die neue Version der Vitrine wird parallel aufgebaut (v2), ein Vergleich der Metriken (Toleranzbands).
Berichte fixieren: Jeder Export/Dashboard verweist auf 'dataset _ version' und 'definition _ version'.
Kalenderabschnitte: „dei-kat“, „Monat-zu-Datum“ - werden auf die Datenversion festgelegt.

8) Versionsfähigkeit in ML/MLOps

Model Registry: Modell, Datum, Qualitätsmetriken, Trainingsdaten (dataset_version), Versionen von Fitch (feature_set_version).
Feature Store: versionierte Fitch-Gruppen; Verbot von „heißen“ Feldern ohne explizite Version.
Repro-Set: Trainingscode (commit), Umgebung (Docker/conda lock), sid.
Champion-Challenger: parallele Versionen in der Produktion, Berichte über Qualität, Fairness und Privatsphäre.
Rollback: Schneller Rollback auf das bisherige stabile Modell und das Fitch-Set.

9) Rollback, Backfill und Korrekturen

Rollback-Plan: Für jede MAJOR/MINOR-Version gibt es klare Rückgabeschritte.
Backfill-Playbook: Quelle der Wahrheit, Datumsbereich, Umrechnungsreihenfolge, Prüfsummen, Etiketten „recomputed = true“.
Sichtbarkeit der Bearbeitungen: v2 ersetzt v1 erst nach bestandenem Vergleich; alle „historischen“ Berichte verweisen weiterhin auf ihre Versionen.

10) Sicherheit und Compliance im Audit

Signieren von Ereignissen/Paketen: Der Produzent unterschreibt, der Verbraucher prüft.
PII-Desinfizierung: Das Audit speichert Token, nicht rohe PII.
Legal Hold: Verbot der Löschung der Version/Protokolle für den Untersuchungszeitraum.
DSAR: Versionen finden und entladen die Datensätze des Subjekts per Token; Historische Bilder werden berücksichtigt.

11) Metriken und SLOs

Repro Rate: Anteil der Berichte, die aus der Daten-/Codeversion ≥ der Zielschwelle reproduziert werden.
Abdeckung:% der Tabellen mit aktiviertem Zeitreise-/Prüfprotokoll.
Schema Compatibility Pass: Anteil erfolgreicher Kompatibilitätsprüfungen am CI.
Dual-Run Delta: Abweichung v1/v2 innerhalb der Toleranzen.
Rollback MTTR: Durchschnittliche Rollback-Zeit der Version.
Audit Integrity: Anteil der signierten und verifizierten Ereignisse.
Backfill Success: Anteil der korrekt abgeschlossenen Neuberechnungen.

12) Muster für iGaming (Fälle)

GGR-Korrektur rückwirkend: Lieferant hat RTP neu berechnet - Backfill der Fakten für den Zeitraum machen, 'recomputed _ at' erfassen, Release Notes veröffentlichen, v1/v2 vergleichen; Berichte aus den vergangenen Monaten werden nicht neu geschrieben, sondern mit „korrigierte Version verfügbar“ gekennzeichnet.
Anti-Fraud-Regeln: Ändern Sie die Semantik des Spiels - MAJOR, Dual-Run-Modelle und Vitrinen, Rollback auf Champion während der Regression.
KYC/AML: neue Provider-Status hinzugefügt - MINOR mit nullable; Wir schließen Interoperabilitätstests in Verträge ein.
RG-Signale: Verfeinerte Logik der „Loss Series“ - MINOR + Release Notes und Wirkungsüberwachung.

13) Werkzeuge und Artefakte (Kategorien)

Katalog/Lineage/Registry: Versionen von Sets/Diagrammen/Vitrinen, Besitzer, Links, Verträge.
Orchestrator & CI/CD: Kompatibilitätstore, Dual-Run, Veröffentlichungsfreigabe.
Speicher mit Zeitreise: Speicherung von Bildern/Protokollen.
Signing & Checksums: Signieren von Paketen, Prüfsummen von Parties.
Model/Feature Registry: Versionen von Fich/Models, Berichte von Champion-Challenger.

14) Vorlagen (gebrauchsfertig)

14. 1 Release Notes (Skizze)

Ausführung: 'payments _ gold v2. 1. 0`

Typ: MINOR (neue Felder 'psp _ country', 'method _ group')

Grund: Vereinheitlichung der PSP/Länderberichterstattung

Risiken: Auswirkungen auf Joins mit dem Schaufenster 'risk _ signals'

Validierung: Dual-Run 14 Tage, Delta ≤ 0. 2% auf GGR

Rollback: Umschalten auf 'v2. 0. 3 'durch die Flagge des Orchestrators

Deploydatum/Inhaber/Ticket

14. 2 Datenblatt der Set-Version

Dataset: `game_rounds_silver`

Ausführung: '2025-11-01T00: 00: 00Z' (Schnappschuss-ID)

Schema: 'schema @ 1. 7. 0'(Link zum Vertrag)

Quelle: Anbieter-Feeds A/B (commit...)

Integritätskontrolle: checksum, signiertes Manifest

DQ: Vollständigkeit 99. 9%, Frische ≤ 15 min

Verwendung: 'games _ perf _ gold v3. x`, `rg_signals v1. x`

14. 3 Akt der Änderungsprüfung

Ereignis: update schema 'kyc _ status' → 'kyc _ status, v2'

Wer: user/service, Rolle' Data-Engineer '

Wann: '2025-11-01 09:32:10 + 02'

Warum: Ticket # 3421 (neue Provider-Status)

Diff: + 'status _ reason' (nullbar), enum erweitert

Prüfungen: CI Semver Pass, MINOR Vertrag

Bildunterschrift: „sig =...“, hash diff: „sha256 =...“

14. 4 Versionierungspolitik (Fragment)

MAJOR: bricht Kompatibilität; Dual-Write ≥ 30 Tage obligatorischer Rollback-Plan.
MINOR: reversibel kompatibel; Warnungen im Verzeichnis; A/B Schaufenster 7-14 Tage.
PATCH: Qualitätsfixes/Neuberechnungen; Release Notes sind obligatorisch.
Archivierung: Wir speichern ≥ N Monate Snap-Shots für die Regulierung; WORM für Audit.

15) Prozesse (end-to-end)

1. Initiative: Change-Ticket + Impact-Bewertung nach Linej.
2. Design: Vertrags-/Schema-Update + Release Notes.
3. Validierung: CI-Kompatibilitätsprüfungen, DQ-Tests, Dual-Run.
4. Deploy: nach Flagge, Kanarienvogel; Version im Katalog veröffentlichen.
5. Monitoring: delta v1/v2, KPI, Reklamationen.
6. Rollback/Backfill: durch Playbook bei Regression.
7. Post-Mortem: Wenn der Vorfall, Aktualisierung der Politik/Tests.

16) RACI (Beispiel)

Richtlinien und Standards: CDO (A), Data Governance Council (R/A), DPO/Sec (C).
Verträge/Schemata: Domain Owners (A), Data Stewards (R), Platform/Eng (C).
Orchestrierung/Speicherung: Plattform/Eng (R), SRE (C).
BI/Metriken: Analytics Lead (R), Product/Finance (C).
ML-Versionen: ML Lead (A), DS (R), Platform (C).
Audit/Protokolle: SecOps (R), Internal Audit (C).

17) Umsetzungsfahrplan

0-30 Tage (MVP)

Aktivieren Sie Zeitreisen/Snapshots für kritische Tabellen (Zahlungen, game_rounds, kyc).
Führen Sie unveränderliche Audit-Protokolle und ingestion Paketsignaturen aus.
Akzeptieren Sie die SEMVER-Richtlinie und die Vorlage Release Notes.
Verzeichnis: 'owner', 'schema _ version', 'dataset _ version' zu den Top-Vitrinen hinzufügen.

30-90 Tage

Dual-Run für alle MINOR/MAJOR einführen; automatischer Vergleich v1/v2.
Verknüpfen Sie Verträge mit CI-Gates für Kompatibilität und DQ.
Backfill/Rollback-Verordnung; Teams zu trainieren.
Model/Feature Registry mit einem vollständigen Satz von „dannyye→fichi→model→inferens“ -Verknüpfungen.

3-6 Monate

Vollständige Abdeckung durch Audit-Protokolle, WORM-Speicher, Berichte für Aufsichtsbehörden.
Automatisierte Release Notes von diff + line.
Repro Rate/Schema Kompatibilität/Rollback MTTR Berichte in Dashboards.
Vierteljährliche Reviews von KPI-Versionen und „Einfrieren“ von Definitionen.

18) Anti-Muster

Änderung der KPI-Semantik ohne neue Version/Release Note.
Neuberechnungen „leise“ ohne Backfill-Plan und 'recomputed' Markierungen.
Lagerung von rohen PIIs in Audit-Protokollen.
Kein Dual-Run und sofortiger Schaufensterwechsel.
„Ewige“ Modelle/Vitrinen ohne Angabe von Version und Quellen.

19) Verwandte Abschnitte

Datenmanagement, Datenherkunft und Datenpfad, Zugangskontrolle, Tokenisierung, Sicherheit und Verschlüsselung, Modellüberwachung, Ethik und DSAR, Federated Learning, Vertrauliche ML.

Ergebnis

Audit und Versionsfähigkeit machen aus Daten und Modellen ein zuverlässiges Produkt: Jede Änderung ist transparent, reproduzierbar und reversibel. Für iGaming ist dies die Grundlage für das Vertrauen in KPIs, die Nachhaltigkeit von Compliance und die Geschwindigkeit sicherer Releases.