Datenqualitaet & Governance

Warum Datenqualitaet entscheidend ist¶

Ein Dashboard, dem niemand vertraut, ist teurer als kein Dashboard. Menschen ignorieren es und treffen Entscheidungen nach Bauchgefuehl — oder erstellen eigene Excel-Dateien. Wir haben das Dutzende Male gesehen:

• Umsatz weicht um 5% ab zwischen Finanz- und Vertriebsbericht
• Doppelte Kunden — ein Kunde in 3 Systemen unter 3 verschiedenen IDs
• Fehlende Daten — 15% der Bestellungen ohne Kategorie, Segmentierung unbrauchbar
• Veraltete Daten — Pipeline vor einer Woche abgestuerzt, niemand hat es bemerkt

Datenqualitaet ist kein Nice-to-have. Sie ist eine Voraussetzung fuer jede Dateninitiative — BI, Analytics, KI/ML.

Data Quality Framework¶

6 Dimensionen der Qualitaet¶

Fuer jeden Datensatz messen und ueberwachen wir:

1. Vollstaendigkeit — Welcher Anteil der Werte fehlt? Schwellenwert pro Spalte (z.B. E-Mail: max. 2% null)
2. Konsistenz — Stimmen die Daten zwischen Quellen ueberein? Kunde im CRM = Kunde im ERP?
3. Genauigkeit — Sind die Werte korrekt? Existiert die Postleitzahl? Liegt das Datum in der Vergangenheit, nicht im Jahr 2087?
4. Aktualitaet — Wie frisch sind die Daten? SLA: Bestellungen innerhalb von 5 Minuten, Finanzdaten innerhalb 1 Stunde
5. Eindeutigkeit — Gibt es Duplikate? Fuzzy-Duplikat-Erkennung (Mueller Hans vs. Hans Mueller)
6. Validitaet — Entsprechen die Werte dem definierten Format und Bereich? E-Mail hat @, Alter ist 0-150

Automatisierte Quality Checks¶

Quality Checks laufen automatisch als Teil jeder Pipeline:

• dbt-Tests: Schema-Validierung (unique, not_null, accepted_values, relationships)
• Great Expectations: Umfassende Datentests mit menschenlesbarer Dokumentation
• Custom Validators: Geschaeftsspezifische Regeln (Bestellsumme > 0, Lieferdatum > Bestelldatum)
• Anomalie-Erkennung: Statistische Anomalien in Volumen, Verteilung, Trends

Wenn ein Quality Check fehlschlaegt: - Pipeline stoppt (lieber keine Daten als schlechte Daten) - Alert an Slack/Teams mit Problemdetails - Fehlgeschlagene Datensaetze gehen in Quarantaene zur Pruefung - Quality Incident wird mit Root Cause und Resolution protokolliert

Quality Dashboard¶

Zentraler Ueberblick ueber die Qualitaet aller Datensaetze: - Quality Score pro Datensatz (Aggregation der 6 Dimensionen) - Trend ueber die Zeit — verbessert oder verschlechtert sich die Qualitaet? - Top Issues — welche Probleme haben den groessten Impact? - SLA Compliance — wie viele Datensaetze erfuellen das definierte SLA?

Data Governance¶

Ownership-Modell¶

Jeder Datensatz hat definiert: - Data Owner — Business-Verantwortung (wer definiert, was Daten bedeuten) - Data Steward — Operative Verantwortung (wer loest Quality Issues) - Technical Owner — Technische Verantwortung (wer verwaltet die Pipeline)

Data Contracts¶

Formale Vereinbarung zwischen Produzent und Konsument:

contract:
  name: orders-v2
  owner: team-ecommerce
  schema:
    - name: order_id
      type: string
      constraints: [not_null, unique]
    - name: total_amount
      type: decimal(10,2)
      constraints: [not_null, positive]
  quality:
    completeness: ">99%"
    freshness: "<5 minutes"
  sla:
    availability: "99.9%"
    support: "business-hours"

Breaking Change = neue Contract-Version + Benachrichtigung aller Konsumenten + Migrationsphase.

Data Lineage¶

Wir verfolgen automatisch den Datenweg von der Quelle zum Konsumenten:

• Woher die Daten kamen — Quellsystem, Tabelle, API-Endpunkt
• Wie sie transformiert wurden — welche Pipeline, welche Transformationen, welche Filter
• Wohin sie gehen — welche Dashboards, Modelle, Reports die Daten konsumieren
• Impact-Analyse — Aenderung in der Quelle → welche nachgelagerten Systeme sind betroffen?

Tools: dbt Lineage, DataHub, Apache Atlas, OpenLineage.

Datenkatalog¶

Zentraler Ort fuer Data Discovery und Dokumentation:

• Suche & Discovery — Analyst sucht nach „monatlicher Umsatz” → findet Definition, Eigentuemer, Quality Score
• Business Glossar — Einheitliche Definitionen von Geschaeftsbegriffen
• Data Dictionary — Technische Beschreibung von Tabellen und Spalten
• Nutzungsanalysen — Welche Datensaetze werden genutzt, welche nicht
• Kollaboration — Kommentare, Fragen, Bewertungen

DSGVO und Compliance¶

Personal Data Management¶

• PII-Erkennung: Automatische Klassifizierung von Spalten mit personenbezogenen Daten
• Datenmaskierung: PII-Pseudonymisierung in Entwicklungs- und Testumgebungen
• Verschluesselung: At-rest und in-transit fuer sensible Daten
• Zugriffskontrolle: RBAC — PII-Zugriff nur fuer autorisierte Rollen

Recht auf Vergessenwerden¶

Automatisierte Pipeline fuer die Loeschung personenbezogener Daten: 1. Anfrage kommt ueber API/Formular 2. Identifikation aller Vorkommen der Person ueber die gesamte Plattform (Lineage) 3. Anonymisierung/Loeschung in allen Systemen 4. Audit-Log als Compliance-Nachweis 5. Bestaetigung an den Antragsteller

Aufbewahrungsrichtlinien¶

• Automatische Datenloeschung/Archivierung nach Ablauf der Aufbewahrungsfrist
• Konfiguration pro Datensatz (Finanzdaten: 10 Jahre, Logs: 90 Tage, Marketingdaten: 2 Jahre)
• Audit Trail der Aufbewahrungsoperationen

Implementierungsansatz¶

1. Assessment (1-2 Wochen): Audit des aktuellen Zustands — wo liegen die groessten Qualitaetsprobleme? Existiert Governance? Wem gehoeren die Daten?
2. Framework-Setup (2-3 Wochen): Quality Checks, Monitoring, Alerting. Ownership-Modell. Erste 5-10 Datensaetze unter Governance.
3. Katalog und Lineage (2-4 Wochen): Datenkatalog-Deployment, automatisches Lineage, Dokumentation der Schluesseldatensaetze.
4. Skalierung (fortlaufend): Schrittweise Erweiterung auf alle Datensaetze. Data-Steward-Schulung. Kontinuierliche Verbesserung.

Verwandt mit