Überwachung der Datenqualität

1) Zweck und Grundsätze

Warum: zuverlässige Berichte (GGR/Steuern), Betrugsbekämpfung und RG-Modelle, Compliance-Entladungen, Produkte und Personalisierung.

• Schema-first & Contracts: Alle Quellen sind vertraglich verpflichtet, Daten zu veröffentlichen.
• DQ-as-Code: Regeln im Repository, Versionen, Tests und Reviews.
• Observability-by-default: Metriken/Logging/Linie.
• Privacy-by-Design: Minimum PII, Masking und RLS/CLS.
• Kostenbewusst: Priorisierung kritischer Regeln, kluge Stichproben.

2) Taxonomie der Qualitätsmessungen

Vollständigkeit: Anteil der erforderlichen Felder/Zeilen.
Gültigkeit: Übereinstimmung mit Typen/Bereichen/Verzeichnissen.
Uniqueness (Einzigartigkeit): keine doppelten Schlüssel/Ereignisse.
Consistency (Konsistenz): referenzielle Integrität, geschäftliche Invarianten.
Genauigkeit: Annäherung an die „wahre“ Quelle (Zusammenfassungen).
Timeliness/Freshness: Verzögerung des Materials.
Lineage Integrity: Beibehaltung der Ursprünge/Versionen von Transformationen.

Für jede Domäne werden Qualitäts- und Kritikalitätskennzahlen (critical/major/minor) definiert.

3) Verträge und Schemata (Quelle der Wahrheit)

Datenverträge: JSON Schema/Avro/OpenAPI/AsyncAPI, gehostet in Registry.
Stabilität: backward-kompatible Änderungen - nullable hinzufügen; breaking - neue Version + doppelte Aufnahme.
Traceability: in Ereignissen - 'event _ id', 'trace _ id', 'schema _ version', 'source'.

4) DQ-as-Code: Die Struktur der Artefakte

/dq/
rules/
silver. payments. yaml gold. ggr_daily. yaml checks/
sql/
python/
policies/
severities. yaml notifications/
routes. yaml

Regeln: deklarative YAML/SQL;

Schweregrad: Mapping → Alert-Kanäle/Eskalationsstufen;

CI: Schaltkreislinter, Kompatibilitätstests, „Dry-Run „/Simulator.

5) Regelbeispiele (YAML)

yaml table: silver. payments owner: data-payments slo:
freshness_minutes: 15 completeness_percent: 99. 5 rules:
- name: amount_positive severity: critical type: range column: amount min: 0. 01
- name: currency_in_whitelist severity: major type: in_set column: currency set: [EUR, USD, GBP, TRY, BRL]
- name: unique_tx severity: critical type: unique columns: [transaction_id]
- name: fk_user_exists severity: critical type: foreign_key column: user_pseudo_id ref_table: dim. users ref_column: user_pseudo_id
- name: ts_monotonicity severity: minor type: temporal expression: "ts between date_sub(now(), interval 90 day) and now()"

6) SQL-Tests (Beispiele)

Die Einzigartigkeit der Schlüssel

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

Vollständigkeit der erforderlichen Felder

sql
SELECT COUNT() AS nulls
FROM silver. payments
WHERE amount IS NULL OR currency IS NULL OR ts IS NULL;

Verzeichnisse/Konsistenz

sql
SELECT p. currency
FROM silver. payments p
LEFT JOIN ref. currencies r ON p. currency = r. code
WHERE r. code IS NULL;

7) Streaming DQ (Echtzeit)

Ingest-Validierung: Schema-Validierung, Größenbegrenzungen, Typen und enum 's.
On-Stream-Prüfungen: Dedup'(event_id, Quelle)', zulässige Latenz, Gültigkeit von Währungen/Beträgen.
Grenzen: kritische Fehler → DLQ + alert; nicht kritische → zu markieren, aber zu überspringen (mit dem Flag 'dq _ flag').
Metriken: completeness/lag/dup-rate nach Partitur.

8) Umgang mit Fehlern und Ausnahmen

DLQ/Quarantine: „kranke“ Aufzeichnungen werden zurückgehalten, stehen zur Korrektur zur Verfügung.
Exception records: Ausnahmekarte (Eigentümer, Begriff, Grund, Bereich).
Auto-Fallback: Verwenden Sie den letzten richtigen Schaufenster-Snap.
SLA-Schließungen: kritisch - ≤ 24-48 Stunden; major ist ≤ 5. Sklave. Tage.

9) Abstimmung mit Datenschutz und Compliance

PII-Minimierung: Überprüfen Sie nicht „rohe“ PIIs in analytischen Schichten; Verwenden Sie Pseudonyme.
RLS/CLS: Prüfungen werden unter Berücksichtigung der Feldmaskierung durchgeführt.
Regionalisierung: Die Vorschriften berücksichtigen „jurisdiction“ (EWR/UK/BR).
Legal Hold: Verbot des Überschreibens von Archiven im Rahmen der Aufbewahrung.

10) Beobachtbarkeit, SLI/SLO und Alerts

• Freshness p95 (Silber): ≤ 15 min.
• Completeness (critical types): ≥ 99. 5%.
• Validity (schema): ≥ 99. 9%.
• Duplicate rate: ≤ 0. 1%.
• DQ incident MTTR: ≤ 24–48 ч.

Alerts: Routing nach Schweregrad (pager für kritisch), Glätten (alert dedup), „maintenance windows“.

11) Dashboards (Mindestsatz)

Freshness/Completeness Heatmap nach Domains und Märkten.
Top N Tabellen nach Incident Rate und nach Patch-Kosten.
DQ-Trichter: ingest → silber → gold (Verluste/Korrekturen).
Linienkarte für kritische Berichte (Regulator/GGR/RG/AML).
Karte der „Legacy“ -Schemata und Clients (SDK/Schemaversionen).

12) Prozesse und RACI

R (Responsible): Data Engineering (Regeln pro Tabelle), Domain Owners (Semantik).
A (Accountable): Head of Data/CDO.
C (konsultiert): Compliance/Legal/DPO, Architektur, SRE.
I (Informiert): BI/Produkt/Marketing/Finanzen/Operations.

Regellebenszyklus: Vorschlag → Revue → „Dark Launch“ → Einbeziehung → Überwachung → Retrospektive.

13) Abstimmungen und Genauigkeit (Genauigkeit)

Prüfsummen/Transaktionen: Tresor mit OLTP/Providern (PSP/KYC).
Zweikreisvergleiche: unabhängige Pipeline zur selektiven Validierung.
Toleranzen: Prozentschwellen für Metriken (z. B. GGR-Diskrepanz ≤ 0. 2%).
Tägliche Handlungen: Berichte von Pfeifen für die Prüfung.

14) Kosten und Priorisierung

Führen Sie kritische Regeln häufiger aus (Streaming/Stunden), minor - täglich.
Verwenden Sie Stichproben und materialisierte Prüfungen für schwere Tabellen.
Verfolgen Sie cost/query und cost/GB und wenden Sie Clustering/Indizierung an.
Weisen Sie dem DQ ein Budget im Teamschnitt zu (Chargeback).

15) Vorlagen für Gold-Vitrinen (Beispiel GGR Daily)

yaml table: gold. ggr_daily owner: fin-analytics slo:
ready_by_local_time: "06:00"
rules:
- name: ggr_not_negative severity: critical type: range column: ggr min: 0. 0
- name: market_known severity: major type: in_set column: market set_ref: ref. markets
- name: fx_source_present severity: major type: not_null column: fx_source
- name: completeness_by_market severity: critical type: completeness partition_keys: [event_date, market]
expected_rows_expression: "ref. expected_activity(event_date, market)"

16) Qualitätsvorfälle: Management und Kommunikation

Ticketing: Automatische Erstellung von Aufgaben mit angehängten Samples und Metriken.
Kommamuster: Benachrichtigung von Produktbesitzern/Regulierungsbehörden, wenn sie beeinflusst werden.
Post-Mortem: Wurzelursache (Schema drift, Upstream Bug, Load), CAPA-Aktionen, Kontrolle der „Regressionsrückkehr“.

17) Umsetzungsfahrplan

1. Verzeichnis der kritischen Tabellen (Zahlungen, Gameplay, GGR, Compliance).

2. YAML-Regeln für 10-15 Key Checks + CI-Validierung.

3. Dashboard Freshness/Completeness und Alerts für Critical.

4. DLQ/Quarantine + Runbook-Patches.

• Regelerweiterung (FK/accuracy), „dry-run“ -Simulator, A/B-Einschlüsse.
• Integration mit Lineage, Ausnahmen und SLAs.
• Streaming-DQ auf ingest für „laute“ Quellen.

• Automatische Generierung von Regeldokumentation, Kostenmetriken.
• „Independent reconciliation“, wöchentliche Retrospektiven.
• Rule-as-Code Plattform SDKs, Registrierung von Standard-Domain-Prüfungen.

18) Checkliste vor dem Verkauf

• Verträge und Regelungen im Register, Kompatibilitätstests bestehen.
• YAML-Regeln sind abgetötet, Severity/Eskalationen zugeordnet.
• Dashboards und Alerts sind aktiv; SLOs sind definiert und vereinbart.
• DLQ/Quarantine verfügbar, Runbooks dokumentiert.
• Ausschlussverfahren/Sweep Acts sind mit Legal/Compliance abgestimmt.
• Kostenmessungen für Inspektionen und Grenzwerte für schwere Anfragen.

19) Häufige Fehler und wie man sie vermeidet

Rohdaten ohne Verträge: schema-first und consumer-tests eingeben.
Manuelle Prüfungen: Übersetzen Sie in DQ-as-Code und CI.
Keine Priorisierung: Teilen Sie Critical/Major/Minor und Alert-Kanäle.
Fehlende DLQ: Es gibt nichts, mit Fehlern zu arbeiten - fügen Sie Quarantäne hinzu.
Kosten ignorieren: Abfragen profilieren, Materialisierung verwenden.
Keine Post-Mortems: Fehler werden wiederholt - CAPA und Regressionskontrolle eingeben.

20) Das Ergebnis

Das Datenqualitätskontrollsystem ist keine Sammlung von disparaten Inspektionen, sondern ein verwaltetes Programm: Verträge und Schemata, DQ-as-Code, Beobachtbarkeit und SLO, Disziplin der Vorfälle und Sweeps. Im Anschluss an diesen Artikel erhalten Sie reproduzierbare, überprüfbare und kostengünstige Daten, die für regulatorische Berichterstattung, Produktlösungen und Echtzeit-Risikodetektoren ausreichen.