In einer datengetriebenen Welt reicht es längst nicht mehr aus, Daten einfach nur zu sammeln und zu verarbeiten – sie müssen auch verlässlich, vollständig und korrekt sein. Schlechte Datenqualität führt zu falschen Entscheidungen, fehlgeschlagenen Machine-Learning-Modellen oder Störungen in Geschäftsprozessen.

Gerade in modernen Data Pipelines – oft automatisiert, verteilt und in Echtzeit – ist es essenziell, systematisch zu überprüfen, ob die verarbeiteten Daten den erwarteten Standards entsprechen. Genau hier setzt Data Quality Monitoring (DQM) an.

In diesem Artikel zeige ich, wie du mit Databricks und sogenannten Expectation Libraries wie Great Expectations ein robustes, wiederverwendbares und automatisiertes DQM-System aufbaust – sowohl für Batch- als auch für Streaming-Pipelines.

Was sind Expectation Libraries (z. B. Great Expectations) und wie funktionieren sie?

Expectation Libraries verfolgen einen einfachen, aber wirkungsvollen Ansatz:
👉 Sie definieren Erwartungen (Expectations) an deine Daten – zum Beispiel:

• „Jede Zeile muss eine gültige E-Mail-Adresse enthalten.“

• „Kein Wert in der Spalte price darf negativ sein.“

• „In der Spalte timestamp darf kein Nullwert vorkommen.“

Statt diese Prüfregeln in SQL oder Python hart zu codieren, werden sie deklarativ beschrieben, dokumentiert und ausführbar gespeichert – ideal für Wiederverwendung, Tests und Audits.

🔍 Beispiel einer „Expectation“ in Great Expectations:

from great_expectations.dataset import SparkDFDataset
  
df_ge = SparkDFDataset(df)
df_ge.expect_column_values_to_not_be_null("timestamp")
df_ge.expect_column_values_to_be_between("price", min_value=0)

🧰 Was macht Great Expectations so nützlich?

• 📋 Erwartungen sind wiederverwendbar über mehrere Datasets hinweg

• 🧪 Test-Reports mit Erfolg/Fehlschlag-Auswertung

• 📈 Dokumentation als HTML-Report automatisch generierbar

• 🔄 Integration in ETL-Workflows mit Logging & Alerting

⚡ Weitere populäre Expectation Libraries:

• Deequ (Amazon) – stark in statischen Checks & Profiling

• Soda Core / SodaCL – deklarativer YAML-Ansatz mit Fokus auf BI

• TensorFlow Data Validation – spezialisiert auf ML-Daten

Aber: In Databricks ist Great Expectations besonders beliebt – weil es nativ mit Spark DataFrames arbeitet und sich gut in Delta Lake Pipelines integrieren lässt.

Integration in Databricks-Workflows: Möglichkeiten & Architekturmuster

Das Schöne an Databricks ist: Du kannst Expectation Libraries nahtlos in deine bestehenden Pipelines integrieren – egal ob du mit Notebooks, Jobs, Delta Live Tables oder Workflows arbeitest.

🔧 Drei typische Integrationsmuster in Databricks

1. Inline-Validierung in Notebooks oder ETL-Jobs

In klassischen Notebooks oder Batch-Jobs kannst du Great Expectations direkt auf Spark DataFrames anwenden – noch bevor du sie in eine Tabelle schreibst:

from great_expectations.dataset import SparkDFDataset

df_raw = spark.read.format("json").load("/mnt/input/data/")
df_ge = SparkDFDataset(df_raw)
result = df_ge.expect_column_values_to_be_between("temperature", 0, 100)
if not result["success"]:
    raise Exception("Data quality check failed!")

📌 Einsatzgebiet: Ad-hoc-Checks, einfache Batch-Pipelines

2. Modular als eigene DQM-Komponente in der Pipeline

Du kannst die Validierung als eigenen Verarbeitungsschritt kapseln – zum Beispiel als Job oder Workflow-Task, der zwischen Ingestion und Persistierung geschaltet wird.

Beispiel:

[ RAW INGESTION ] → [ DATA QUALITY CHECKS ] → [ CURATED WRITE ]

So bleibt deine Pipeline klar strukturiert, und du kannst die DQM-Logik unabhängig vom Transformationsteil entwickeln, testen und versionieren.

📌 Einsatzgebiet: Reusable Quality Checks in produktiven Pipelines

3. Automatisiert mit Delta Live Tables (DLT)

DLT bietet die Möglichkeit, DQM-Checks direkt in der Pipeline zu definieren – z. B. mit dem @expectations-Decorator:

@dlt.expect("valid_price", "price >= 0")
@dlt.table
def cleaned_data():
    return dlt.read("raw_data").filter("price IS NOT NULL")

Die Ergebnisse landen automatisch im DLT Monitoring UI – mit Übersicht über Fehlerquoten und Datenqualität pro Tabelle.

📌 Einsatzgebiet: Automatisiertes Monitoring bei kontinuierlicher Verarbeitung

🧠 Architektur-Tipp

„Treat Data Quality Checks like Unit Tests for Data“
– Sie sollten versionskontrolliert, wiederverwendbar und automatisiert ausführbar sein – genau wie dein Code.

Praxisbeispiel: Data Quality Checks mit Great Expectations in einer Delta Lake Pipeline

In diesem Kapitel zeige ich dir, wie du Great Expectations in einer typischen Databricks Delta Lake Pipeline einsetzt – inklusive automatischer Validierung und Fehlerbehandlung.

📁 Ausgangssituation:

Wir laden Rohdaten (z. B. Bestelldaten) von einem Cloud Storage-Verzeichnis, prüfen sie auf bestimmte Qualitätsregeln und schreiben sie danach in eine kuratierte Delta-Tabelle – nur wenn die Regeln erfüllt sind.

🔄 Pipeline-Flow:

[ RAW DATA ] → [ DataFrame + Great Expectations ] → [ Validation OK? ] → [ Delta Lake ]
                                                                 ↓
                                                        [ Fehler-Logging / Alert ]

🛠️ Codebeispiel in Databricks Notebook:

from great_expectations.dataset import SparkDFDataset
from datetime import datetime

# Rohdaten laden
df_raw = spark.read.json("/mnt/raw/orders/")
# In GE DataFrame umwandeln
df_ge = SparkDFDataset(df_raw)
# Erwartungen definieren
df_ge.expect_column_values_to_not_be_null("order_id")
df_ge.expect_column_values_to_be_between("quantity", 1, 100)
df_ge.expect_column_values_to_match_regex("email", r".+@.+\..+")
# Ergebnis prüfen
validation = df_ge.validate()
if validation["success"]:
    # Nur wenn alles passt: In Delta Lake schreiben
    df_ge.spark_df.write.format("delta").mode("append").saveAsTable("curated.orders")
else:
    # Optional: Fehler loggen oder Notification senden
    timestamp = datetime.now().isoformat()
    dbutils.fs.put(f"/mnt/logs/dqm_failed_{timestamp}.json", str(validation), overwrite=True)
    raise Exception("Data Quality Checks failed. Check logs for details.")

🧾 Was hier passiert:

• Die Rohdaten werden mit Spark geladen und an Great Expectations übergeben.

• Drei einfache Qualitätsregeln werden angewandt (z. B. keine Nullwerte in order_id, gültiger E-Mail-Format).

• Nur bei Erfolg landen die Daten in der Delta-Tabelle.

• Bei Fehlern wird ein Report erstellt – ideal für Alerting, Logging oder Auditing.

🔍 Optional: Report als HTML-Datei speichern

Great Expectations kann auch automatisch schöne HTML-Dokumentationen der Checks erzeugen – perfekt für Data Stewards oder Audits:

df_ge.save_expectation_suite("order_checks")
df_ge.data_asset_name = "orders_raw"
df_ge.expectation_suite_name = "order_checks"
df_ge.run_validation()
df_ge.build_data_docs()

Best Practices & Empfehlungen für produktive Umgebungen

Data Quality Monitoring sollte in produktiven Pipelines nicht optional, sondern integrierter Bestandteil der Architektur sein. Hier sind einige erprobte Best Practices aus realen Projekten:

✅ 1. Früh prüfen, oft prüfen („Shift Left“)

Integriere Qualitätsprüfungen so früh wie möglich – idealerweise direkt nach der Ingestion. Je früher Fehler erkannt werden, desto geringer ist der Aufwand für Behebung und Rückverarbeitung.

✅ 2. Data Quality Checks versionieren & testen

Speichere Expectation Suites in einem Git-Repository, prüfe sie automatisiert in CI/CD-Pipelines und nutze sie wie echten Code. So wird Datenqualität ein Teil deiner Softwarequalität.

✅ 3. Verwende benutzerdefinierte Expectations für Businesslogik

Viele Regeln sind domänenspezifisch (z. B. "Ein Kunde darf nicht mehr als 5 Bestellungen pro Stunde absetzen"). Great Expectations lässt sich einfach mit Custom Expectations erweitern – z. B. via Python oder Spark SQL.

✅ 4. Alerts & Monitoring einbauen

Kombiniere DQM mit Logging, E-Mail-Benachrichtigungen oder Tools wie Datadog, Prometheus oder Slack Webhooks. Fehler ohne Benachrichtigung bleiben oft unentdeckt.

✅ 5. Expectations als Dokumentation nutzen

Nutze HTML-Dokumentation von GE oder eigene Dashboards, um Stakeholdern zu zeigen, was "gute" Daten eigentlich bedeuten – das fördert Vertrauen und Transparenz.

🎯 Fazit:

Data Quality Monitoring mit Databricks & Expectation Libraries wie Great Expectations ist kein Luxus, sondern Pflicht, wenn du zuverlässige und skalierbare Datenprodukte bauen willst.

Die Investition in saubere Daten zahlt sich immer aus – durch bessere Modelle, stabilere Pipelines und fundiertere Entscheidungen.