Data Validation

Einfach erklärt

Data Validation prüft automatisch oder systematisch, ob Daten den erwarteten Regeln entsprechen – bevor sie in kritischen Prozessen Schaden anrichten können.

Was prüfen:

Prüfung	Beispiel
Schema	Ist age eine Zahl?
Nulls	Ist email ausgefüllt?
Bereich	Liegt ein Wert im erlaubten Bereich?
Format	Ist email eine gültige E-Mail?
Referenz	Existiert customer_id in Customers?

Technischer Deep Dive

Great Expectations

import great_expectations as gx

# Expectation Suite definieren
suite = gx.ExpectationSuite("orders_suite")

suite.add_expectation(
    gx.expectations.ExpectColumnValuesToNotBeNull(column="order_id")
)
suite.add_expectation(
    gx.expectations.ExpectColumnValuesToBeBetween(
        column="total", min_value=min_allowed_total, max_value=max_allowed_total
    )
)

# Validieren
results = validator.validate(dataframe)
if not results.success:
    raise DataQualityError(results)

Pydantic für APIs

from pydantic import BaseModel, EmailStr, validator

class User(BaseModel):
    name: str
    email: EmailStr
    age: int
    
    @validator('age')
    def age_must_be_valid(cls, v):
        if not min_age <= v <= max_age:
            raise ValueError('Invalid age')
        return v

Wo validieren? Die drei Ebenen

Validierung wirkt am besten in Schichten, ähnlich wie Sicherheitskontrollen:

Ebene	Beispiel	Fängt ab
Eingang	API-Request, File-Upload	Offensichtlich kaputte Daten, falsche Typen
Pipeline	Nach jedem Transformationsschritt	Fehler in der eigenen Logik, Joins mit Datenverlust
Ausgang	Vor dem Laden ins Data Warehouse oder ML-Training	Alles, was durchgerutscht ist

Die Faustregel lautet: so früh wie möglich prüfen. Ein abgelehnter API-Request kostet Millisekunden – ein fehlerhafter Wert, der erst im Monatsreport auffällt, kostet Stunden an Fehlersuche und im schlimmsten Fall Vertrauen in die Daten.

Syntaktische vs. semantische Validierung

Syntaktische Prüfungen (Typ, Format, Pflichtfeld) sind einfach zu definieren und decken viele Fehler ab. Die schwierigeren Probleme sind semantischer Natur: Ein Bestelldatum in der Zukunft ist formal ein gültiges Datum, fachlich aber meist falsch. Ein Rabatt über dem Warenwert ist eine valide Zahl, verletzt aber eine Geschäftsregel. Gute Validierung kombiniert beides – und dokumentiert die fachlichen Regeln dort, wo sie geprüft werden.

# Semantische Regel: Felder im Zusammenhang prüfen
from pydantic import BaseModel, model_validator

class Order(BaseModel):
    order_date: date
    ship_date: date

    @model_validator(mode="after")
    def ship_after_order(self):
        if self.ship_date < self.order_date:
            raise ValueError("Versand vor Bestellung")
        return self

Statische Regeln vs. Anomalie-Erkennung

Feste Regeln decken bekannte Fehlerbilder ab, versagen aber bei schleichenden Problemen: Wenn eine Quelle plötzlich nur noch halb so viele Zeilen liefert oder sich die Verteilung eines Feldes verschiebt, ist jede einzelne Zeile weiterhin valide. Hierfür eignen sich statistische Checks – etwa Zeilenzahlen, Null-Raten und Verteilungskennzahlen pro Lauf mit historischen Werten vergleichen. Tools wie Great Expectations, dbt tests oder spezialisierte Data-Observability-Plattformen unterstützen beide Ansätze.

Typische Fehler in der Praxis

• Nur beim Aufbau validieren: Regeln einmal definieren und nie pflegen. Datenquellen ändern sich; Validierungsregeln brauchen denselben Lebenszyklus wie Code.
• Alles hart ablehnen: Nicht jeder Verstoß rechtfertigt einen Pipeline-Stopp. Ein Warn-Schwellenwert plus Quarantäne-Tabelle ist oft die bessere Balance.
• Fehler ohne Kontext loggen: „Validation failed” hilft niemandem. Gute Fehlermeldungen nennen Spalte, Regel, Beispielwerte und Anzahl betroffener Zeilen.
• Validierung und Monitoring trennen: Die Ergebnisse der Checks gehören in ein Dashboard mit Trend – eine langsam steigende Fehlerquote ist ein Frühwarnsignal.