Enterprise Datenplattform mit Databricks Part 6
Einführung
Willkommen zurück zu unserer Blog-Serie rund um den Aufbau moderner Enterprise-Datenplattformen!
Ein zentraler Erfolgsindikator einer Datenplattform ist neben der Erfüllung der technischen Anforderungen vor allem das Vertrauen der Fachanwender in die gelieferten Kennzahlen. Beim Aufbau unserer Cloud-Datenplattform mit Databricks und dbt setzen wir zur Erfüllung dieser Ansprüche auf zwei zentrale Säulen: Automatisierte Datenqualitätstests (DQ) und eine lückenlose End-to-End Lineage.
Visualisierung erstellt mit Unterstützung von KI (Gemini)
Datenqualität (DQ)
Datenqualität ist kein optionaler nachträglicher Prozess, sondern eine integrale Komponente einer Datenplattform, die tief im Entwicklungsprozess verankert sein muss. Mit dbt nutzen wir dafür ein zweistufiges Verfahren, das sicherstellt, dass nur valide Daten die höheren Schichten der Medaillon-Architektur erreichen.
Generische DQ-TEsts
Generische DQ-Tests dienen der Überprüfung der Datenstruktur sowie der grundlegenden Integrität eines Datensatzes. Es handelt sich dabei um rein technische Tests, in denen keine fachliche Logik geprüft wird. Der große Vorteil dieser Art von Tests liegt darin, dass sie deklarativ in YAML-Dateien definiert werden können. Zudem sind sie hochgradig wiederverwendbar und können bei jedem Build-Prozess direkt ausgeführt werden.
Die drei Standard-Tests, die wir für nahezu jedes Modell im Bronze- und Silver-Layer definieren, sind:
- unique: Stellt sicher, dass ein Primärschlüssel oder eine Kombination von Feldern keine Duplikate enthält.
- not_null: Garantiert, dass kritische Felder (z.B. eine Kunden-ID oder ein Transaktionszeitstempel) niemals leer sind.
- accepted_values: Überprüft, ob ein Feld nur Werte aus einer vordefinierten Liste erlaubter Werte enthält (z. B. Statuscodes wie „shipped“, „completed“, „returned“).
Ein Beispiel für eine YAML-Definition solcher generischen Tests ist im Folgenden abgebildet:
models:
- name: stg_orders
columns:
- name: order_id
tests:
- unique
- not_null
- name: status
tests:
- accepted_values:
values: ['placed', 'shipped', 'completed', 'returned']
Fachliche DQ-Tests
Nicht jeder Fehler lässt sich durch einfache Strukturprüfungen mit generischen DQ-Checks finden. Um konkrete inhaltliche Korrektheit eines Datensatzes zu testen, muss daher die implementierte Business-Logik geprüft werden. Diese fachlichen Prüfungen können durch individuelle SQL-Abfragen, die gezielt nach „logischen Unmöglichkeiten“ suchen, durchgeführt werden.
Ein solcher fachlicher Test gilt in dbt als fehlgeschlagen, wenn die SQL-Abfrage einen oder mehrere Datensätze zurückgibt. Beispiele für einen solchen fachlichen Test könnten sein:
- Logik-Check: „Darf das Lieferdatum vor dem Bestelldatum liegen?“
- Summen-Check: „Entspricht die Summe der Einzelpositionen dem Gesamtbetrag der Rechnung?“
- Konsistenz-Check: „Haben aktive Verträge zwingend eine zugeordnete Zahlungsmethode?“
Durch diese maßgeschneiderten SQL-Tests fangen wir fachliche Anomalien ab, bevor sie in die Reporting-Layer fließen und dort zu Fehlentscheidungen führen könnten.
End-to-End Lineage
Transparenz des Datenflusses ist der Schlüssel zur Fehleranalyse. In klassischen SQL-Umgebungen schreibt man oft hartkodierte Tabellennamen, wie zum Beispiel:
SELECT * FROM bronze_db.api_orders
Das Problem: Ändert sich der Tabellenname oder die Struktur, müssen SQLs manuell angepasst werden. Zudem weiß das System nicht, in welcher Reihenfolge die Tabellen befüllt werden müssen, da es keinen Automatismus gibt, der Abhängigkeiten zwischen einzelnen SQL-Modellen analysiert.
In dbt nutzen wir deshalb das ref()-Konstrukt: Anstatt eine Tabelle beim Namen zu nennen, referenzieren wir den Namen des dbt-Modells:
SELECT
order_id,
UPPER(status) as status_code,
ingested_at
FROM {{ ref('stg_orders') }}
WHERE status IS NOT NULL
Im Hintergrund passieren dabei gleich mehrere “Dinge”:
- Erstellung eines Abhängigkeits-Graph: dbt scannt bei jeder Neukompilierung alle SQL-Files nach ref()-Statements. Aus den einzelnen Abhängigkeiten, die in den Modellen definiert sind, erstellt dbt einen Directed Acyclic Graph (DAG). Dadurch erlangt dbt die Kenntnis davon, in welcher Reihenfolge die SQL-Statements bei der Ausführung abgesetzt werden müssen.
- Umgebungs-Awareness: dbt ersetzt das ref()-Statement beim Kompilieren durch den echten Pfad zur Tabelle, je nachdem, ob man gerade auf der Dev-, Test- oder Prod-Umgebung arbeitet. Dies wird durch Variablen in Konfigurationsdateien gesteuert.
- Visualisierung: Mit dem Befehl dbt docs generate wird aus diesen Verknüpfungen eine interaktive Lineage-Webseite erstellt. Auf einen Blick kann die gesamte Lineage der Datenplattform in beliebigem Detailgrad, sowie Informationen zu einzelnen Tabellen, begutachtet werden.
- Selektive Ausführung: Der dbt run Befehl kann nun sehr präzise gesteuert werden, um einzelne Modelle und deren Verwandtschaft auszuführen. Mit dbt run –select my_model+ werden das Modell sowie alle davon abhängigen Nachfolgemodelle gestartet.
Mit dbt run –select +my_model werden das Modell sowie alle dafür notwendigen Vorgänger ausgeführt.
Ausblick
Wahres Vertrauen in eine Datenplattform entsteht nur durch radikale Transparenz und nachweisbare Qualität. Durch den Einsatz von dbt in unserem Cloud-Stack erheben wir Testing und Lineage von manuellen Fleißaufgaben zu integralen, automatisierten Bestandteilen der Pipeline.
Generische und fachliche DQ-Tests wirken wie ein Filter, der Fehler abfängt, bevor sie das Reporting erreichen. Gleichzeitig sorgt die dynamische Lineage, dass Abhängigkeiten stets aktuell, visuell nachvollziehbar und umgebungsbewusst gesteuert werden.
Bleibt dran!