Schema-Drift: Was passiert, wenn sich Quelldaten still und heimlich ändern

Stell dir folgendes Szenario vor. Du hast eine Pipeline gebaut, die täglich Daten aus einer externen API zieht, transformiert und ins Warehouse lädt. Alles läuft seit Monaten reibungslos. Die Dashboards zeigen grüne Zahlen. Das Team ist zufrieden.

Dann, eines Morgens, läuft die Pipeline nicht mehr durch. Oder schlimmer: Sie läuft noch durch - aber die Zahlen stimmen nicht.

Du gräbst nach. Und findest es: Das Quelldatenformat hat sich geändert. Eine Spalte, die früher ein String war, ist jetzt ein Integer. Ein Feld, das immer da war, fehlt plötzlich. Ein neues Feld ist aufgetaucht, das dein Schema nicht kennt.

Niemand hat dich gewarnt. Niemand hat es absichtlich gemacht. Es ist einfach… passiert.

Das ist Schema-Drift.

Was Schema-Drift ist und warum es so gefährlich ist

Schema-Drift bezeichnet die schleichende Veränderung der Struktur von Quelldaten im Laufe der Zeit. Neue Spalten kommen dazu. Alte verschwinden oder werden umbenannt. Datentypen ändern sich. Werte, die früher immer befüllt waren, sind plötzlich null.

Veränderungen passieren, damit kann man umgehen. Das Problem ist das Stille dabei. Bei einem Breaking Change crasht die Pipeline sofort; du weißt, dass etwas nicht stimmt. Aber wenn eine Spalte umbenannt wird und die Pipeline trotzdem noch läuft? Dann lädst du wochenlang Null-Werte, weil du auf ein Feld referenzierst, das nicht mehr existiert. Niemand merkt es, bis jemand die Zahlen wirklich genau anschaut.

Das ist der Teil, der wirklich nervt.

Wo Schema-Drift herkommt

Die häufigste Ursache sind externe APIs. Anbieter ändern Strukturen, manchmal mit Deprecation-Notice, manchmal einfach so. v2 kann ein komplett anderes JSON liefern als v1; und wenn kein explizites Versionshandling da ist, läufst du irgendwann dagegen, ohne es sofort zu merken.

Ähnlich bei Datenbanken von Drittanbietern. Wer per CDC oder direktem Datenbankzugriff auf Fremdsysteme zugreift, ist darauf angewiesen, dass die Entwickler dort über Schemaänderungen informieren. Das passiert selten rechtzeitig.

Auch interne Systeme sind keine sichere Bank. Backend-Teams fügen Spalten hinzu, ändern Typen, splitten Tabellen - ohne dabei an die Datenpipelines zu denken. Manchmal wissen sie nicht einmal, dass es welche gibt.

Die drei Arten von Schema-Drift

Nicht jeder Drift trifft gleich hart. Wenn eine neue Spalte auftaucht, ist das meistens unkritisch: Die Pipeline ignoriert sie, alles läuft weiter. Du verpasst möglicherweise neue Informationen, aber es knallt nicht.

Gefährlicher wird es, wenn eine Spalte verschwindet, auf die du dich verlässt. Im besten Fall bricht die Pipeline sofort. Im schlechteren Fall liefert sie still Null-Werte und niemand merkt es.

Am tückischsten sind semantische Mutationen. Ein Feld liefert jetzt Centbeträge statt Euro. Die Zahlen sehen plausibel aus. Sie sind um Faktor 100 falsch. Das merkt man erst beim dritten Hinsehen, oder wenn jemand fragt, warum der Umsatz so komisch aussieht.

Wie du dich schützt

1. Schema-Validierung in der Eingabeschicht

Das Wichtigste zuerst: Validiere das Schema, bevor du Daten verarbeitest. Nicht am Ende der Pipeline, wo der Schaden schon angerichtet ist - am Anfang.

In Python kannst du das mit Libraries wie pydantic oder pandera machen:

from pandera import DataFrameSchema, Column, Check

schema = DataFrameSchema({
    "order_id": Column(int, nullable=False),
    "customer_id": Column(int, nullable=False),
    "amount_eur": Column(float, Check(lambda x: x >= 0)),
    "order_date": Column("datetime64[ns]"),
})

# Wirft ValidationError, wenn das Schema nicht stimmt
validated_df = schema.validate(raw_df)

Wenn die Daten nicht dem erwarteten Schema entsprechen, stoppt die Pipeline sofort mit einem klaren Fehler. Kein stilles Versagen.

2. Schema-Registry oder Schema-Versioning

Wenn du Kafka oder ähnliche Event-Streaming-Systeme nutzt, ist eine Schema-Registry wie Confluent Schema Registry oder AWS Glue Schema Registry der Standard-Ansatz. Sie speichert die Schemaversionen, und Producer wie Consumer können prüfen, ob ihre Schemas kompatibel sind.

Für Batch-Pipelines ohne Kafka: Versioniere dein erwartetes Schema explizit. Eine einfache JSON- oder YAML-Datei, die beschreibt, welche Felder erwartet werden, welchen Typ sie haben und welche nullable sind. Diese Datei liegt im Repository und wird bei jeder Schemaänderung bewusst aktualisiert.

3. Data Contracts

Der Begriff klingt nach Bürokratie, ist aber eigentlich simple: Ein Data Contract ist eine formale Vereinbarung zwischen dem Produzenten der Daten und dem Konsumenten, wie die Daten aussehen werden.

In der Praxis bedeutet das: Wenn das Backend-Team ein Schema ändert, benachrichtigen sie das Data-Team vorher. Wenn eine externe API eine Breaking Change ankündigt, gibt es einen definierten Prozess, wie damit umgegangen wird.

Das setzt natürlich voraus, dass diese Kultur im Unternehmen existiert. Wo sie fehlt, ist es deine Aufgabe, sie einzufordern und mit konkreten Beispielen zu zeigen, was es kostet, wenn diese Kommunikation nicht stattfindet.

4. Monitoring und Alerting auf Datenqualität

Auch wenn Schema-Validierung läuft: Baue aktives Monitoring ein. Überprüfe regelmäßig:

• Kommen noch Null-Werte in Feldern vor, die nie null sein sollten?
• Ändert sich die Anzahl der Zeilen pro Tag drastisch?
• Gibt es Felder, die plötzlich neue, unbekannte Werte haben (bei kategorischen Variablen)?

Tools wie Great Expectations, dbt tests oder Soda bieten dafür fertige Bausteine:

# dbt test Beispiel
models:
  - name: orders
    columns:
      - name: order_id
        tests:
          - not_null
          - unique
      - name: amount_eur
        tests:
          - not_null
          - dbt_utils.accepted_range:
              min_value: 0

5. Rohdaten immer aufbewahren

Das ist mein persönlicher Favorit-Ratschlag für Schema-Drift-Resilienz: Speichere die Rohdaten immer. Bevor du transformierst, bevor du validierst - leg eine Kopie der Originaldaten ab.

Wenn Schema-Drift aufgetaucht ist, hast du die Möglichkeit, die Daten erneut zu verarbeiten - mit dem korrigierten Schema und den neuen Transformationsregeln. Ohne Rohdaten bist du aufgeschmissen.

Eine Storage-Landingzone oder ein Raw-Layer im Data Warehouse kostet verhältnismäßig wenig und rettet dich regelmäßig.

Was tun, wenn Schema-Drift schon passiert ist

Du merkst es, und die Daten sind schon geladen. Jetzt?

Erstmal Luftholen. Dann den Schaden einschätzen: Seit wann ist das Schema anders? Wie weit reicht die Verfälschung zurück? Das Verarbeitungslog deiner Pipeline (das du ja hast, weil du idempotente Pipelines baust) hilft beim Eingrenzen.

Danach kommt das Neuverarbeiten. Mit Rohdaten ist das ein Pipeline-Run. Ohne musst du direkt an die Quelle und schauen, was noch rekonstruierbar ist.

Und dann: Schema-Validierung einbauen, Contract mit dem Produzenten klären, Monitoring verbessern. Damit es kein zweites Mal passiert.

Das Fazit

Schema-Drift ist in Datenprojekten die Regel, keine Ausnahme. Quelldaten ändern sich, weil die Welt sich ändert und weil Backend-Teams, externe Anbieter und Drittsysteme selten an deine Pipeline denken.

Was konkret hilft:

• Schemas am Eingang der Pipeline validieren, nicht am Ausgang
• Schemas explizit versionieren und im Repository halten
• Data Contracts mit Datenproduzenten abschließen, intern wie extern
• Datenqualität aktiv mit Tests und Alerting überwachen
• Immer eine Kopie der Rohdaten behalten

Drift, den du kennst, kannst du behandeln. Den anderen (den, der sich still in die Zahlen einschleicht und wochenlang niemandem auffällt) willst du gar nicht erst kennenlernen.

Vorschaubild: Markus Spiske, Unsplash