Seminar DataHub Datenqualität, Assertions und Incidents

Datenqualität wird als nachvollziehbarer Regel- und Bearbeitungsprozess aufgebaut. Offene Metadatenobjekte, importierte Testergebnisse und editionabhängige Ausführungsfunktionen werden klar unterschieden.

Lernziele

• Qualitätsanforderungen in überprüfbare Regeln übersetzen
• Assertion-Typen und geeignete Ausführungswege auswählen
• Ergebnisse externer Qualitätswerkzeuge konsistent einbinden
• Incidents mit Zuständigkeit, Status und Nachweisen bearbeiten
• Qualitätsabdeckung und Data Contracts schrittweise etablieren

Zielgruppe

Data Quality Engineers, Data Stewards, Data Product Owner, Analytics Engineers, Governance-Verantwortliche und Plattformteams.

Voraussetzungen

Grundkenntnisse in Datenqualität, SQL und Metadatenmanagement. Erfahrungen mit dbt-Tests, Great Expectations oder vergleichbaren Werkzeugen sind hilfreich.

Inhaltsübersicht

1. Kapitel 1: Qualitätsarchitektur und Funktionsabgrenzung
2. Kapitel 2: Assertion-Typen und Regelentwurf
3. Kapitel 3: Externe Qualitätswerkzeuge integrieren
4. Kapitel 4: Incidents bearbeiten
5. Kapitel 5: Data Contracts und Abdeckung
6. Kapitel 6: Betriebsmodell verbessern

Kapitel 1: Qualitätsarchitektur und Funktionsabgrenzung

Inhaltsübersicht dieses Kapitels: Qualitätsobjekte einordnen; Edition und Ausführung klären; Verantwortung festlegen.

Schritt 1: Qualitätsobjekte einordnen

Assertions, Ausführungen, Ergebnisse, Incidents und Verträge werden als getrennte, miteinander verknüpfte Objekte betrachtet. Vor der Umsetzung werden Voraussetzungen, betroffene Objekte und erwartete Ergebnisse festgehalten. Die Ausführung erfolgt in einer abgegrenzten Übungsumgebung und endet mit einer dokumentierten Soll-Ist-Prüfung.

Schritt 2: Edition und Ausführung klären

Native Ausführung, importierte Ergebnisse und editionabhängige Beobachtungsfunktionen werden vor der Konzeption sauber unterschieden. Konfiguration, Zuständigkeit und mögliche Fehlerbilder werden ausdrücklich berücksichtigt. Das Ergebnis wird mit technischen und fachlichen Prüfkriterien bewertet und als wiederverwendbarer Arbeitsschritt dokumentiert.

Schritt 3: Verantwortung festlegen

Regelverantwortung, technische Ausführung, fachliche Bewertung und Incident-Bearbeitung werden unterschiedlichen Rollen zugeordnet. Abweichungen werden nicht durch pauschale Wiederholung verdeckt, sondern nach Ursache, Auswirkung und Korrekturweg eingeordnet. Eine abschließende Kontrolle bestätigt, dass der Arbeitsschritt reproduzierbar ausgeführt werden kann.

Kapitel 2: Assertion-Typen und Regelentwurf

Inhaltsübersicht dieses Kapitels: Frische und Volumen prüfen; Schema und Spalten validieren; Fachliche Regeln ergänzen.

Schritt 1: Frische und Volumen prüfen

Aktualisierungszeit und erwartete Datenmenge werden mit nachvollziehbaren Schwellen, Zeitfenstern und Reaktionen beschrieben. Vor der Umsetzung werden Voraussetzungen, betroffene Objekte und erwartete Ergebnisse festgehalten. Die Ausführung erfolgt in einer abgegrenzten Übungsumgebung und endet mit einer dokumentierten Soll-Ist-Prüfung.

Schritt 2: Schema und Spalten validieren

Pflichtspalten, Datentypen, Wertebereiche, Muster und Aggregatgrenzen werden als überprüfbare Regeln formuliert. Konfiguration, Zuständigkeit und mögliche Fehlerbilder werden ausdrücklich berücksichtigt. Das Ergebnis wird mit technischen und fachlichen Prüfkriterien bewertet und als wiederverwendbarer Arbeitsschritt dokumentiert.

Schritt 3: Fachliche Regeln ergänzen

Benutzerdefinierte SQL- oder externe Testlogik erhält Zweck, Eigentümer, Kritikalität und Reaktion bei Fehler. Abweichungen werden nicht durch pauschale Wiederholung verdeckt, sondern nach Ursache, Auswirkung und Korrekturweg eingeordnet. Eine abschließende Kontrolle bestätigt, dass der Arbeitsschritt reproduzierbar ausgeführt werden kann.

Kapitel 3: Externe Qualitätswerkzeuge integrieren

Inhaltsübersicht dieses Kapitels: Quellen inventarisieren; Identitäten stabilisieren; Import validieren.

Schritt 1: Quellen inventarisieren

Vorhandene dbt-Tests, Great-Expectations-Prüfungen oder plattformeigene Qualitätsregeln werden erfasst und normalisiert. Vor der Umsetzung werden Voraussetzungen, betroffene Objekte und erwartete Ergebnisse festgehalten. Die Ausführung erfolgt in einer abgegrenzten Übungsumgebung und endet mit einer dokumentierten Soll-Ist-Prüfung.

Schritt 2: Identitäten stabilisieren

Regel-IDs, Ziel-URNs, Ausführungszeit und Status werden so zugeordnet, dass Verlaufsdaten nicht durch wechselnde Namen zerfallen. Konfiguration, Zuständigkeit und mögliche Fehlerbilder werden ausdrücklich berücksichtigt. Das Ergebnis wird mit technischen und fachlichen Prüfkriterien bewertet und als wiederverwendbarer Arbeitsschritt dokumentiert.

Schritt 3: Import validieren

Anzahl, Zielobjekte, Status, Zeitstempel und Fehlermeldungen werden nach jedem Lauf technisch und fachlich geprüft. Abweichungen werden nicht durch pauschale Wiederholung verdeckt, sondern nach Ursache, Auswirkung und Korrekturweg eingeordnet. Eine abschließende Kontrolle bestätigt, dass der Arbeitsschritt reproduzierbar ausgeführt werden kann.

Kapitel 4: Incidents bearbeiten

Inhaltsübersicht dieses Kapitels: Incident priorisieren; Auswirkung untersuchen; Bearbeitung dokumentieren.

Schritt 1: Incident priorisieren

Fehlgeschlagene Regeln werden nach Kritikalität und betroffenen Verbrauchern bewertet; nicht jeder Fehler erhält dieselbe Priorität. Vor der Umsetzung werden Voraussetzungen, betroffene Objekte und erwartete Ergebnisse festgehalten. Die Ausführung erfolgt in einer abgegrenzten Übungsumgebung und endet mit einer dokumentierten Soll-Ist-Prüfung.

Schritt 2: Auswirkung untersuchen

Lineage, Eigentümer, abhängige Dashboards und Datenprodukte werden für Triage und Eskalation herangezogen. Konfiguration, Zuständigkeit und mögliche Fehlerbilder werden ausdrücklich berücksichtigt. Das Ergebnis wird mit technischen und fachlichen Prüfkriterien bewertet und als wiederverwendbarer Arbeitsschritt dokumentiert.

Schritt 3: Bearbeitung dokumentieren

Status, Verantwortlicher, Ursache, Maßnahme, Nachweis und Abschluss werden lückenlos festgehalten. Abweichungen werden nicht durch pauschale Wiederholung verdeckt, sondern nach Ursache, Auswirkung und Korrekturweg eingeordnet. Eine abschließende Kontrolle bestätigt, dass der Arbeitsschritt reproduzierbar ausgeführt werden kann.

Kapitel 5: Data Contracts und Abdeckung

Inhaltsübersicht dieses Kapitels: Vertragsinhalt definieren; Abdeckung messen; Prioritäten steuern.

Schritt 1: Vertragsinhalt definieren

Schema, Aktualität, Volumen, fachliche Regeln, Verantwortung und Änderungsverfahren werden als zusammenhängende Erwartung formuliert. Vor der Umsetzung werden Voraussetzungen, betroffene Objekte und erwartete Ergebnisse festgehalten. Die Ausführung erfolgt in einer abgegrenzten Übungsumgebung und endet mit einer dokumentierten Soll-Ist-Prüfung.

Schritt 2: Abdeckung messen

Kritische Assets, vorhandene Regeln, fehlende Eigentümer und ungeprüfte Bereiche werden in einer Matrix sichtbar gemacht. Konfiguration, Zuständigkeit und mögliche Fehlerbilder werden ausdrücklich berücksichtigt. Das Ergebnis wird mit technischen und fachlichen Prüfkriterien bewertet und als wiederverwendbarer Arbeitsschritt dokumentiert.

Schritt 3: Prioritäten steuern

Neue Regeln werden nach Geschäftskritikalität, Nutzung und Fehlerhistorie eingeführt, nicht nach bloßer Tabellenanzahl. Abweichungen werden nicht durch pauschale Wiederholung verdeckt, sondern nach Ursache, Auswirkung und Korrekturweg eingeordnet. Eine abschließende Kontrolle bestätigt, dass der Arbeitsschritt reproduzierbar ausgeführt werden kann.

Kapitel 6: Betriebsmodell verbessern

Inhaltsübersicht dieses Kapitels: Triage-Prozess festlegen; Fehlalarme reduzieren; Regelbestand pflegen.

Schritt 1: Triage-Prozess festlegen

Alarmannahme, Erstbewertung, Eskalation und fachliche Kommunikation erhalten feste Zeiten und Verantwortlichkeiten. Vor der Umsetzung werden Voraussetzungen, betroffene Objekte und erwartete Ergebnisse festgehalten. Die Ausführung erfolgt in einer abgegrenzten Übungsumgebung und endet mit einer dokumentierten Soll-Ist-Prüfung.

Schritt 2: Fehlalarme reduzieren

Schwellen, Zeitfenster und saisonale Muster werden überprüft; Änderungen bleiben versioniert und begründet. Konfiguration, Zuständigkeit und mögliche Fehlerbilder werden ausdrücklich berücksichtigt. Das Ergebnis wird mit technischen und fachlichen Prüfkriterien bewertet und als wiederverwendbarer Arbeitsschritt dokumentiert.

Schritt 3: Regelbestand pflegen

Veraltete, doppelte oder nicht verantwortete Regeln werden regelmäßig angepasst oder außer Betrieb genommen. Abweichungen werden nicht durch pauschale Wiederholung verdeckt, sondern nach Ursache, Auswirkung und Korrekturweg eingeordnet. Eine abschließende Kontrolle bestätigt, dass der Arbeitsschritt reproduzierbar ausgeführt werden kann.

Praxisübungen

Inhaltsübersicht dieses Kapitels: Anwendung, Prüfung und Dokumentation der behandelten Arbeitsschritte.

1. Entwurf von Frische-, Volumen-, Schema- und Spaltenregeln
2. Zuordnung externer Testergebnisse zu stabilen DataHub-Objekten
3. Bearbeitung eines Incidents mit Lineage-basierter Auswirkungsanalyse
4. Erstellung einer Qualitätsabdeckungs- und Priorisierungsmatrix

Methodik

Inhaltsübersicht dieses Kapitels: Vermittlungsform, Übungsorganisation und Qualitätssicherung.

Regelentwurf, technische Zuordnung und Incident-Prozess werden an einer konsistenten Beispieldomäne durchgespielt. Editionseigenschaften werden ausdrücklich gekennzeichnet.