MongoDB nach Delta Lake migrieren? Diese Probleme erwarten dich

Die Umstellung von MongoDB auf Delta Lake über Apache Spark gehört zu den Standardaufgaben moderner Datenpipelines. Doch was auf dem Papier einfach klingt, entpuppt sich in der Praxis oft als Albtraum für Ingenieure. Plötzlich brechen ETL-Jobs ab, Datenbanken bleiben in inkonsistenten Zuständen zurück, und aufrufbereite Kollegen müssen nächtliche Log-Analysen durchführen – nur weil ein einziges Dokument ein unerwartetes Format aufweist.

In einem kürzlichen Projekt habe ich über zehn solcher Pipelines betreut und dabei immer wieder dieselben Herausforderungen erlebt. Nach monatelangen manuellen Reparaturen und Schema-Anpassungen entstand daraus nosql-delta-bridge, eine Open-Source-Bibliothek, die genau diese Probleme lösen soll.

pip install nosql-delta-bridge

Warum scheinbar korrekte Daten Pipelines zum Absturz bringen

MongoDBs schemalose Architektur ist aus Anwendersicht ein entscheidender Vorteil – für Dateningenieure hingegen ein potenzielles Desaster. Die Probleme lassen sich in drei Hauptkategorien unterteilen:

1. Polymorphe Felder: Wenn Typen plötzlich wechseln

Ein klassisches Beispiel: Ein Feld namens status kann in derselben Sammlung sowohl als String ("active"), Integer (1) als auch Boolean (true) auftreten. Oder ein value-Feld, das mal eine Zahl, mal ein verschachteltes Objekt, mal ein Boolean speichert – je nachdem, welcher Microservice die Daten geschrieben hat.

Apache Spark versucht zwar, das Schema aus einer Stichprobe abzuleiten, doch sobald ein Dokument außerhalb dieser Stichprobe einen abweichenden Typ enthält, scheitert die gesamte Schreiboperation:

AnalysisException: Cannot cast StringType to IntegerType

Die übliche Gegenmaßnahme? Alles vorsorglich in StringType umzuwandeln – mit der Folge, dass keine Typensicherheit mehr besteht und nachgelagerte Jobs die Daten erneut parsen müssen. Ein Teufelskreis aus manuellen Anpassungen und inkonsistenten Tabellen.

2. Inkonsistente verschachtelte Strukturen: Wenn Felder verschwinden

Besonders tückisch sind Arrays mit verschachtelten Objekten, bei denen Felder je nach Dokumentversion mal vorhanden sind, mal nicht. Oder Collections, in denen sich die Struktur einer verschachtelten Tabelle über Zeit weiterentwickelt hat.

Jede Pipeline endete bisher mit ähnlichem Boilerplate-Code:

def rebuild_struct(df, field, schema):
    return df.withColumn(
        field,
        struct([
            coalesce(col(f"{field}.{f}"), lit(None).cast(t)).alias(f)
            for f, t in schema.items()
        ])
    )

Hier werden alle möglichen Felder manuell rekonstruiert, fehlende Werte mit null aufgefüllt und Strukturen erzwungen – ein Prozess, der bei jeder neuen Dokumentversion wiederholt werden muss.

3. Stille Fehler: Wenn Daten einfach verschwinden

Doch selbst wenn die Pipeline nicht komplett abstürzt, lauern oft stille Fehler: Felder werden unbemerkt in andere Typen umgewandelt, Dokumente fallen durchs Raster oder werden ohne Rückmeldung verworfen. Erst drei Jobs später merkt das Team, dass Daten fehlen – und dann beginnt die mühevolle Suche nach der ursprünglichen Ursache.

Warum herkömmliche Tools versagen

Viele Teams setzen auf Datenobservability-Tools wie Elementary, um Schemaabweichungen zu erkennen. Doch diese Tools arbeiten auf Tabellenebene und liefern zwar Warnungen wie "Tabellenintegrität gefährdet", nicht jedoch die konkrete Ursache:

• Die Pipeline stürzt ab.
• Elementary meldet eine fehlgeschlagene Aktualisierung.
• Die Ingenieure durchsuchen Spark-Logs und stoßen auf einen Cast-Fehler.
• Nach stundenlanger Suche wird das fehlerhafte Dokument in einer 100.000-Dokumente-Batch gefunden.
• Selbst dann bleibt unklar, wie der Fehler behoben werden kann – besonders wenn die Schemaabweichung tiefgreifend ist.

Die manuelle Suche nach der Nadel im Heuhaufen ist nicht nur zeitaufwendig, sondern auch fehleranfällig. Und währenddessen bleibt die gesamte Batch ungeschrieben.

Die Lösung: Strukturierte Validierung mit nosql-delta-bridge

Das Kernprinzip der Bibliothek ist einfach: Jedes Dokument wird entweder in die Delta-Tabelle geschrieben oder landet in einer Dead-Letter-Queue (DLQ) – mit einer klar dokumentierten Begründung. Keine stillen Fehler, keine undurchsichtigen Abstürze.

Der Prozess besteht aus zwei Schritten:

Schritt 1: Schema-Kontrakt aus historischen Daten ableiten

Bevor neue Dokumente verarbeitet werden, wird ein zuverlässiger Schema-Kontrakt aus vertrauenswürdigen historischen Daten erstellt:

bridge infer historical.json --output payments.schema.json

Die Bibliothek analysiert die Stichprobe und löst Typkonflikte nach konfigurierbaren Regeln – etwa indem der breiteste Typ gewählt oder Felder als nullable markiert werden. Das Ergebnis ist ein Schema-Kontrakt, der als Grundlage für die weitere Verarbeitung dient.

Schritt 2: Ingestion mit strenger Validierung

Anschließend werden neue Dokumente gegen diesen Kontrakt validiert und verarbeitet:

bridge ingest incoming.json ./delta/payments \
  --schema payments.schema.json \
  --dlq rejected.ndjson

Das Ergebnis ist transparent:

• 1.000 Dokumente wurden verarbeitet.
• 994 davon wurden erfolgreich in Delta Lake geschrieben.
• 6 Dokumente landeten in der DLQ – jedes mit einer detaillierten Fehlerbegründung:

{
  "_id": "abc123",
  "amount": "99.90",
  "_dlq_reason": "Cast fehlgeschlagen für 'amount': Erwartet Double, erhalten String",
  "_dlq_stage": "coerce",
  "_dlq_ts": "2025-04-28T14:32:01Z"
}

Keine nächtliche Log-Arbeit mehr. Keine manuelle Fehlersuche. Die fehlerhaften Dokumente sind sofort isoliert und mit allen relevanten Metadaten dokumentiert.

Welche Szenarien die Bibliothek abdeckt

Die Bibliothek bietet flexible Handhabung für gängige Probleme bei der Schema-Migration:

• Typkonflikte (umwandelbar): Automatische Umwandlung und Dokument wird geschrieben.
• Typkonflikte (nicht umwandelbar): Dokument landet in der DLQ mit Begründung.
• Fehlende Pflichtfelder: Dokument wird abgelehnt mit Angabe des fehlenden Felds.
• Neue Felder in Schema: Konfigurierbar: Ablehnen oder Schema evolutionieren.
• Vollständige Typumstellung (alle Dokumente): Keine Dokumente werden geschrieben, alle landen in der DLQ mit Warnung.
• Fehlende Subfelder in verschachtelten Strukturen: Wird mit null aufgefüllt, Dokument wird geschrieben.
• Arrays mit gemischten Typen: Konfigurierbar: Umwandlung zum breitesten Typ oder Ablehnung.

Warum Python statt Spark?

Der MongoDB Connector für Apache Spark ist zwar Standard, erfordert jedoch einen Spark-Cluster – eine Overhead-Lösung für Teams, die lediglich kleine bis mittelgroße MongoDB-Sammlungen verarbeiten müssen.

nosql-delta-bridge setzt stattdessen auf delta-rs, eine reine Python-Implementierung des Delta-Lake-Protokolls. Die Bibliothek läuft lokal, in einem Docker-Container oder auf einer kleinen VM – ohne Cluster. Ein einfacher Clone des Repos und die Ausführung der Beispiele dauert nur wenige Minuten.

Für große Produktionsumgebungen, die bereits Spark nutzen, lässt sich die Bibliothek modular einsetzen: Ihre Schema-Inferenz- und Umwandlungslogik kann auch unabhängig genutzt werden.

Integration in bestehende Architekturen

Die Bibliothek ergänzt bestehende Observability-Tools perfekt. Während Tools wie Elementary auf Tabellenebene warnen, liefert nosql-delta-bridge die konkreten Ursachen – direkt an der Quelle. So lässt sich die Pipeline nicht nur stabilisieren, sondern auch die Datenqualität nachhaltig verbessern.

Die Zukunft der Datenmigration liegt in automatisierter Validierung und klarer Fehlerbehandlung. Mit nosql-delta-bridge wird dieser Ansatz endlich zugänglich – für Teams jeder Größe und Infrastruktur.