Validierung der Daten

1) Warum es die iGaming-Plattform braucht

Vertrauen in Berichte und KPIs: GGR/NET, Conversions, Retention, RG-Signale.
ML/Scoring Zuverlässigkeit: Korrekte Daten für Anti-Fraud/Empfehlungen/RG.
Echtzeit-Operationen: Warnungen bei Drift/Verlust von Ereignissen, bevor Auszahlungen/UX betroffen sind.
Compliance: keine PII/Geheimnisse, wo sie nicht sein sollten; Nachweisbare Rückverfolgbarkeit.

2) Wo zu validieren: Kontrollniveaus

1. Injection (batch/stream): Schema, Typen, Pflichtfelder, idempotency/dedup.
2. Stream-Verarbeitung: Fenster/Wasserzeichen, Ordnung, Auslassungen/Verspätungen, exactly-once.
3. ETL/ELT und Transformationen: Links/Joins, Aggregate, Geschäftsbilanzen.
4. DWH/Vitrinen (Gold): Konsistenz zwischen den Tischen, Frische, Einzigartigkeit der Schlüssel.
5. Feature Store/Online: Schnittbereiche, Konsistenz der offlayn↔onlayn.
6. BI/API: Zählungen und Filter, SLAs auf Latenz/Frische, k-Anonymität.

3) Prüfarten (Katalog)

Schaltung: Typ/nullable/enum/regex/JSON-shape; inkompatible Änderungen → den Füßen.
Domain: ≥0, Währung ∈ {EUR, USD, TRY, BRL}, Einsatz ≤ Limit, strana∈litsenzii.
Identität/Schlüssel: Der Primärschlüssel ist eindeutig, der Fremdschlüssel ist nicht „hängend“.
Qualität der Felder: Füllung, Längen, Format (IBAN, BIN, E-Mail-Token).
Statistiken/Basislinien: Frequenzen, Verteilungen, Quantilkorridore.
Anomalien: starke Sprünge in Volumen/Lappen, Nullen/Duplikate, Schema drift.
Frische: max (ts) nicht älter als X; Lag ingest→gold ≤ T.
Konsistenz: Summe nach Details = Zusammenfassung; multi-table reconciliation.
Privatsphäre/Sicherheit: Zero-PII außerhalb der erlaubten Bereiche; Tokenisierung/Masken.
Regulatorisch: RG/AML-Felder sind vorhanden und plausibel (Daten, Merkmale).

4) Datenverträge (Datenverträge)

Der Vertrag legt das Schema + Qualitätsregeln + SLO zwischen der Quelle und den Verbrauchern fest.

yaml dataset: payments_ingest_v2 owner: team-payments schema:
id: {type: string, pattern: "^[a-f0-9]{32}$", unique: true}
ts: {type: timestamp, timezone: "UTC", nullable: false}
amount: {type: decimal(18,2), min: 0. 00}
currency: {type: string, enum: ["EUR","USD","TRY","BRL"]}
psp: {type: string, required: true}
quality:
freshness_max: "PT5M"
completeness_min: 0. 995 duplicate_rate_max: 0. 001 pii_allowed: false slo:
p95_ingest_latency_ms: 30000 success_rate: 0. 995

Vertragsänderungen - über Semver und Migrationen: 'MAJOR' bricht, 'MINOR' fügt ein Feld hinzu, 'PATCH' korrigiert die Beschreibung.

5) „Erwartungen“ (Erwartungen) und Politik

Erwartungen - deklarative Prüfungen, die in Pipelines (Batch/Stream) ausgeführt werden.

yaml expectations:
- name: unique_primary_key check: "unique(id)"
severity: "error"
- name: amount_non_negative check: "amount >= 0"
severity: "error"
- name: currency_enum check: "currency in ['EUR','USD','TRY','BRL']"
severity: "error"
- name: ts_fresh_enough check: "now() - max(ts) <= interval '5 minutes'"
severity: "warn"
- name: pii_absent check: "no_plain_pii(columns: ['email','card','iban'])"
severity: "error"

• 'error' → Partie-/Batcha-Quarantäne, Warnung + Ticket; Downstream-Block.
• 'warn' geht → durch, sondern erstellt eine Aufgabe für die Analyse; Qualitätszeichen.
• Info → nur Überwachung.

6) Streaming: die Besonderheiten der Kontrollen

Watermarks/late data: Wir erlauben die Verspätung von '≤ 120s', sonst - Quarantäne; mit Endfenstern zu kompensieren.
Idempotency: Ereignisschlüssel + Hash Payload → Dedup auf dem Broker/im Stream.
Exactly-once: Transaktionssing (+ idempotente Sinks) für kritische Streams (Zahlungen/Runden).
Volumenzähler: „erwartet“ vs „erhalten“ pro Fenster; Die Diskrepanz → alert.

scala val deduped = stream
.keyBy(_.id)
.process(new DeduplicateWithin(Time. minutes(10)))

val validated = deduped
.filter(_.amount >= 0)
.filter(_.currency in Set("EUR","USD","TRY","BRL"))

emitToQuarantineIfLate(validated, allowedLateness = 120. seconds)

7) DWH/SQL: Invarianten und Abstimmungen

sql
-- uniqueness
SELECT id, COUNT() c FROM gold. payments GROUP BY 1 HAVING c>1;

-- freshness
SELECT NOW() - MAX(ts) AS lag FROM gold. payments;

-- reconciliation of totals
SELECT
SUM(amount) AS by_rows,
(SELECT total_amount FROM gold. payments_summary WHERE date=CURRENT_DATE) AS by_summary
FROM gold. payments
WHERE date = CURRENT_DATE;

Matching mit Vitrinen: tägliche Abstimmungen „Detail → Zusammenfassung“, Diskrepanzberichte, automatisches Ticket.

8) Privatsphäre und Sicherheit

Standard-PII-Revision: Masken/Token am Eingang; verbieten „rohe“ E-Mails/Karten/Telefone in Protokollen.
Berechtigungsrichtlinie: Tabellen mit PII - separate Ebene/Verzeichnis, Zugriff nach Rolle (RBAC/ABAC).
K-Anonymität der Berichte: mindestens N Zeilen pro Abschnitt.
Leak-Detektoren: regelmäßige Überprüfungen auf PII-Muster, „Geheimnisse“ (Schlüssel/Token).
Jurisdiktionen: Geo/Tenant-Isolation (Land/Marke/Lizenz), getrennte Schlüssel.

9) Qualitätsmetriken und SLO

• Freshness - max (ts) Rückstand.
• Completeness - Anteil der nicht leeren/erwarteten Datensätze.
• Uniqueness - Doppelte Schlüssel.
• Consistency - Invarianten und Bilanzen (intertabellisch).
• Accuracy - Überprüfung mit externer Quelle/Domain-Regeln.
• Gültigkeit - Entspricht den Typen/enum/regex.

• `Freshness payments_gold ≤ 5 мин` (p95).
• `Completeness game_rounds ≥ 99. 7 %/день `.
• `Duplicate_rate ≤ 0. 1‰`.
• `PII_leak = 0`.

10) Alerts, Tickets und Runbook

Routing: Slack/PagerDuty → Domaininhaber; Wir wenden automatisch Samples und Diff an.
Gruppierung: ein Vorfall pro Set „labels: dataset = payments, brand = TR“.

1. Überprüfen Sie den Lag ingest und die Broker-Warteschlange.

2. Vergleichen Sie „erwartet vs erhalten“ von PSP.

3. Aktivieren Sie Retrays/wechseln Sie die PSP-Route.

4. Grund kommentieren; Neustart der Rückstände; Halten Sie einen Post-Mortem.

11) Versionierung, Tests und Waiver-Prozess

Semver Qualitätsregeln: 'quality @ MAJOR. MINOR. PATCH`.
Transformations-Unit-Tests (SQL/DBT/Python) und Kontrakttests für Quellen.
GOLDEN-Sets: Bekannte Fälle von Diskrepanzen/Lecks - obligatorisch in der Regression.
Waiver (Ausnahme): kurzfristige Erlaubnis, gegen die Regel zu verstoßen (Beschreibung, Eigentümer, Frist, Ausgleichsmaßnahmen).

12) Kataloge/Artefakte (fertige Vorlagen)

12. 1 Dataset-Pass

yaml dataset: gold. game_rounds owner: team-games steward: data-governance contracts: ["games_rounds_v3"]
quality_slo:
freshness_p95: "PT10M"
completeness_min: 0. 997 uniqueness_max_dup: 0. 0005 alerts:
channels: ["#dq-incidents","#games-ops"]
severity_map: {error: "P1", warn: "P2"}

12. 2 Quarantänerichtlinien

yaml quarantine:
storage: "s3://quarantine/payments/"
retention: "P30D"
access: ["team-payments","data-governance"]
auto_reprocess:
cron: "/15  "
max_attempts: 3

12. 3 Expectation для Feature Store

yaml featureset: fs_payments_online_v1 checks:
- name: feature_freshness check: "now() - max(feature_ts) <= interval '60 seconds'"
severity: "error"
- name: range_amount_avg check: "amount_avg in [0, 2000]"
severity: "warn"
- name: enum_device check: "device in ['ios','android','web']"
severity: "error"

13) Spezifität von iGaming: vorgefertigte Fälle

Zahlungen/PSP: Abstimmung des Betrags der Ein- und Auszahlungen mit den PSP-Berichten; fehlende Status → Batch-Quarantäne; alert auf Wachstum 'decline _ rate'.
Spieleanbieter: Drop 'rounds _ per _ min' vs baseline + schema drift vom Anbieter → Transformationsblock des Anbieters A, Statusbanner.
RG/AML: Pflichtfelder (Limits, Selbstausschluss, KYC-Status); abgelaufene KYC → Flag auf Auszahlungsblock, Ticket in Compliance.
Marketing/CRM: Gültigkeit von Kampagnenparametern, UTM, Event-Dedup; k-Anonymität in den Schaufenstern.

14) Fahrplan für die Umsetzung

0-30 Tage (MVP)

1. Schließen Sie Verträge für Schlüsselsätze ein: Zahlungen, game_rounds, Benutzer, Funktionen.
2. Erwartungskatalog (10-15 Basics) + Quarantäne + Warnungen.
3. Dashboard Freshness/Completeness/Uniqueness; Bericht über Vorfälle.
4. Runbook’и для `Freshness`, `Duplicates`, `Schema drift`.

30-90 Tage

1. Intertabellierte Abstimmungen und Bilanzen; waiver-Prozess und semver Regeln.
2. Stream-Validierung (late data, dedup, watermarks); PII-Detektoren.
3. Integration mit CI/CD: Vertragstests von Quellen und Transformationen.
4. SLO Qualität in OKR Domain-Teams.

3-6 Monate

1. AIOps-Hinweise von Schwellenwerten; Autolokalisierung der Ursachen.
2. Marken-/Geo-übergreifende Qualitätspolitik und Compliance-Berichte.
3. Post-Mortems P1-Vorfälle → Auffüllen von Golden-Sets und Regeln.
4. Verknüpfung mit Thread-Alerting und Anomalieanalyse (Single Loop).

15) RACI

Data Governance (A/R): Standards, Verträge, Regelprüfung.
Domain Owners (R): Domain-Erwartungen und Invarianten.
Datenplattform (R): Erwartungsrahmen, Quarantäne, Warnungen, Überwachung.
Sicherheit/DSB (A/R): Privatsphäre/PII/k-Anonymität, Geo/Tenant-Isolation.
SRE/Observability (C): Routing von Vorfällen, SLO/SLI.
Produkt/Finanzen (C): Geschäftsbilanzen, Vorfallprioritäten.

16) Anti-Muster

Validierung „nur im DWH“ - spät, teuer, schmerzhaft.
Keine Quarantäne - „Dreck“ geht an Gold/ML und bricht Vertrauen.
Harte Schwellenwerte ohne Saisonalität/Stunden/Märkte → Sturm von Warnmeldungen.
Das Fehlen von Eigentümer- und Semverregeln → das Chaos der Ausnahmen.
Protokolle mit PII und „Screenshots zu einem gemeinsamen Kanal“.
Einmalige „Sanitärtage“ statt Dauerschaltung.

17) Verwandte Abschnitte

DataOps-Praktiken, Datenaudit und Versionsfähigkeit, Herkunft und Pfad von Daten, Alerts aus Datenströmen, Analyse von Anomalien und Korrelationen, Zugangskontrolle, Datensicherheit und Verschlüsselung, Datenspeicherungsrichtlinien, MLOps: Ausnutzung von Modellen.

Summe

Validierung ist kein Filter am Ende, sondern ein durchgängiger Qualitätsvertrag: von Injection und Stream über Schaufenster bis hin zu Online-Fich. Klare Erwartungen, Quarantäne, Alerts und SLOs machen Daten zu einem zuverlässigen Asset: Berichte sind korrekt, Modelle sind robust, Zahlungen sind sicher, Compliance ist ruhig.