Change Data Feed: Wie Delta Lake Änderungen zeilengenau weitergibt
Change Data Feed liefert zeilengenaue Änderungen zwischen Delta-Tabellenversionen für die inkrementelle Weiterverarbeitung, wo er das vollständige Neuladen ablöst und was CDC am Quellsystem weiterhin leisten muss.
Die Kernaussagen auf einen Blick.
- Der Change Data Feed stellt alle geänderten Zeilen zwischen zwei Versionen einer Delta-Tabelle bereit, inklusive Änderungs-Typ und Commit-Metadaten.
- Nachgelagerte Prozesse können dadurch gezielt nur neue, geänderte oder gelöschte Zeilen verarbeiten und lösen das vollständige Neuladen dort ab, wo Datenmenge und Frequenz es rechtfertigen.
- Der Change Data Feed setzt eine bereits befüllte Delta-Tabelle voraus und ersetzt deshalb kein CDC-Tooling am Quellsystem.
- Empfehlenswert ist, die Aktivierung pro Tabelle bewusst zu planen und die Leseintervalle der konsumierenden Prozesse auf die Aufbewahrungsfristen der Tabelle abzustimmen.
Inhaltsverzeichnis
Wenn jede Nacht die gesamte Tabelle neu verarbeitet wird
Eine Kundentabelle in der Silver-Schicht versorgt jede Nacht drei nachgelagerte Tabellen und ein externes Zielsystem. Jeder Verarbeitungsschritt liest den vollständigen Datenbestand, berechnet ihn erneut und schreibt das Ergebnis zurück: ein vollständiges Neuladen (Full Reload) über die gesamte Strecke. Der Lauf dauert Stunden; dabei hat sich seit dem vorherigen Lauf häufig weniger als ein Prozent der Zeilen verändert.
Dieses Vorgehen ist in vielen historisch gewachsenen Lakehouse-Plattformen verbreitet: Solange niemand weiß, welche Zeilen sich geändert haben, wird häufig weiterhin der vollständige Datenbestand neu verarbeitet. Mit wachsendem Datenvolumen steigen jedoch Laufzeit und Compute-Kosten, während das Reporting zugleich aktuellere Stände verlangt.
Wie kann ein nachgelagerter Prozess erkennen, welche Zeilen sich seit dem letzten Lauf verändert haben? Wie kommen Löschungen zuverlässig im Zielsystem an? Kann der Change Data Feed auch das Change Data Capture am Quellsystem ersetzen?
Das Transaktionslog von Delta Lake dokumentiert bereits jede Änderung an einer Tabelle. Der Change Data Feed stellt diese Änderungsinformationen für Abfragen und nachgelagerte Prozesse bereit. Dadurch verändert sich die zentrale Architekturfrage: Welche Prozesse benötigen weiterhin einen vollständigen Reload, und welche Stufen verarbeiten künftig nur noch Änderungen?
Was ist der Change Data Feed?
Der Change Data Feed (CDF) ist eine Funktion von Delta Lake: Ist er für eine Tabelle aktiviert, können alle eingefügten, geänderten und gelöschten Zeilen zwischen zwei Tabellenversionen abgefragt werden. Jede Zeile enthält zusätzlich den Typ der Änderung sowie Version und Zeitstempel des zugehörigen Commits. Microsoft Learn dokumentiert die Metadaten-Spalten _change_type, _commit_version und _commit_timestamp; bei Updates werden sowohl der vorherige (update_preimage) als auch der neue Zustand der Zeile (update_postimage) bereitgestellt.
Der Feed zeigt, welche Zeilen seit dem letzten Verarbeitungslauf eingefügt, geändert oder gelöscht wurden; nachgelagerte Prozesse können diese Änderungen gezielt weiterverarbeiten. Ein erneutes Lesen der gesamten Tabelle ist dadurch häufig nicht mehr erforderlich. Auch Löschungen werden als eigene Änderungsereignisse bereitgestellt; einfache Vergleiche über Zeitstempel-Spalten können Löschungen dagegen meist nicht zuverlässig erkennen. Die Erfassung von Änderungen im Quellsystem und deren Übertragung in die Delta-Tabelle übernimmt der Feed nicht. Änderungen, die vor der Aktivierung erfolgt sind, können nachträglich nicht über den Feed ausgelesen werden.
insert
Neue Zeile, die zwischen den beiden Versionen hinzugekommen ist.
update_preimage
Zustand der Zeile unmittelbar vor der Änderung.
update_postimage
Zustand der Zeile unmittelbar nach der Änderung.
delete
Zeile, die zwischen den Versionen entfernt wurde.
Wie das Transaktionslog, die Versionierung und die übrigen Format-Komponenten zusammenspielen, zeigen wir im Überblick zu Delta Lake.
Data & AI Beratung mit ruhrdot
Als offizieller Databricks-Partner begleiten wir dich von der Datenstrategie bis zur produktiven KI-Lösung.
Wie entsteht der Feed aus dem Transaktionslog?
Der Change Data Feed wird für jede Tabelle einzeln aktiviert, über die Tabellen-Eigenschaft delta.enableChangeDataFeed = true, beim Anlegen oder nachträglich per ALTER TABLE. Die Funktion ist Bestandteil des offenen Delta-Lake-Formats; eine separate technische Komponente ist für den Change Data Feed auf Databricks nicht erforderlich. Das Delta-Projekt dokumentiert, dass nur Änderungen nach der Aktivierung aufgezeichnet werden; für Versionen vor der Aktivierung wird keine nachträgliche Änderungshistorie erzeugt. Der Zeitpunkt der Aktivierung sollte deshalb bei der Planung nachgelagerter Prozesse berücksichtigt werden: Konsumenten lesen nur, was ab diesem Moment passiert.
Die technische Umsetzung benötigt nur begrenzte zusätzliche Strukturen. Für Updates und Löschungen legt Delta Lake zusätzliche Änderungsdateien im Verzeichnis _change_data ab; Einfügungen können direkt aus den regulären Datendateien abgeleitet werden, ohne zusätzliche Dateien zu erzeugen. Der zusätzliche Schreib- und Speicheraufwand bleibt dadurch vergleichsweise gering. Bei Tabellen mit vielen Updates und Löschungen wächst jedoch die Anzahl der Änderungsdateien; Speicherbedarf und Dateianzahl sollten deshalb in der Wartungsplanung berücksichtigt werden.
Der Feed kann im Batch- oder Streaming-Verfahren gelesen werden. Als Batch liefert die SQL-Funktion table_changes('tabelle', startversion, endversion) oder die Option readChangeFeed mit Start- und End-Version beziehungsweise Zeitstempel einen eindeutig definierten Versions- oder Zeitbereich; das eignet sich insbesondere für periodisch ausgeführte nachgelagerte Prozesse. Als Streaming-Quelle verarbeitet ein fortlaufender Job jeden neuen Commit; Databricks beschreibt dafür Mengen-Begrenzungen je Verarbeitungsschritt über maxFilesPerTrigger und maxBytesPerTrigger, wobei die Änderungen eines Commits stets gemeinsam in einem Verarbeitungsschritt verarbeitet werden. Der aktuelle Verarbeitungsstand wird in einem Checkpoint gespeichert; dadurch kann der Prozess nach einem Neustart an der zuletzt verarbeiteten Position fortsetzen.
Batch lesen, wenn
- nachgelagerte Prozesse periodisch laufen, etwa stündlich oder täglich
- ein klar definierter Versions- oder Zeitstempel-Bereich verarbeitet werden soll
- table_changes() oder die Option readChangeFeed für den Job ausreichen
Streaming lesen, wenn
- jeder neue Commit fortlaufend und zeitnah verarbeitet werden soll
- ein Checkpoint den Wiederanlauf nach einem Neustart übernehmen muss
- maxFilesPerTrigger oder maxBytesPerTrigger die Menge je Verarbeitungsschritt begrenzen sollen
Das Startverhalten eines Streaming-Prozesses muss bei der Konfiguration berücksichtigt werden: Ohne angegebene Start-Version liefert der Feed beim ersten Start den kompletten aktuellen Tabellenstand als Einfügungen und erst danach die laufenden Änderungen. Für ein leeres Zielsystem ermöglicht dies einen einfachen initialen Aufbau; enthält das Ziel den Bestand bereits, gehört eine Start-Version in die Konfiguration, andernfalls kann der vorhandene Datenbestand erneut verarbeitet werden.
Wann löst Änderungs-Verarbeitung das vollständige Neuladen ab?
Für die beschriebene Kundentabelle reduziert die Umstellung die zu verarbeitende Datenmenge deutlich: Die drei Folge-Tabellen und der Abgleich ins Zielsystem verarbeiten nur noch das eine Prozent geänderter Zeilen, inklusive der Löschungen, die vorher in keiner Zeitstempel-Spalte sichtbar waren. Statt des vollständigen Datenbestands werden nur noch die seit dem letzten Lauf entstandenen Änderungen verarbeitet.
Die inkrementelle Verarbeitung ist jedoch nicht für jede Tabelle automatisch sinnvoll. Vier Kriterien sind für die Entscheidung besonders relevant:
| Kriterium | Vollständiges Neuladen | Änderungs-Verarbeitung über den Feed |
|---|---|---|
| Tabellengröße | klein bis mittel | groß, mehrstufig weiterverarbeitet |
| Änderungs-Anteil je Lauf | hoch | niedrig (wenige Prozent) |
| Frequenz-Anforderung | täglicher Stand reicht | stündlich bis kontinuierlich |
| Zielsystem | verträgt den Komplett-Ersatz | braucht gezielte Updates und Löschungen |
Für kleine Tabellen mit seltenen Änderungen bleibt das vollständige Neuladen die einfachere Wahl: Es kommt ohne Checkpoints, Aufbewahrungs-Planung und Sonderfälle aus, und die Compute-Kosten eines kleinen Überschreibens fallen kaum ins Gewicht. Besonders sinnvoll ist der Feed bei großen Tabellen, bei denen sich pro Lauf nur ein kleiner Anteil der Daten verändert, bei höheren Frequenzen und bei Zielsystemen, die einzelne Änderungen erwarten.
Vier Einsatzmuster kommen in der Praxis besonders häufig vor, darunter die Schichten-Verarbeitung von Bronze über Silver nach Gold, die wir im Überblick zur Medaillon-Architektur vertiefen:
Schichten-Verarbeitung
Gold-Tabellen verarbeiten nur neue, geänderte oder gelöschte Datensätze aus ihren Silver-Quellen.
Aggregate & Historien
Kennzahlen und SCD-Type-2-Historien nutzen die Vorher- und Nachher-Zustände von Updates.
Zielsystem-Abgleich
Suche, Cache oder operative Anwendungen erhalten nur die geänderten Datensätze.
Lösch-Propagation
Löschungen werden kontrolliert an nachgelagerte Systeme weitergegeben.
CDC an der Quelle
In Architekturgesprächen stellt sich häufig die Frage, ob der Feed das CDC-Tool an der Quelle einspart. Die Antwort ergibt sich aus der Position der beiden Mechanismen innerhalb der Datenpipeline: Change Data Capture erfasst Änderungen direkt im Quellsystem, typischerweise aus den Transaktions-Logs einer Datenbank, und transportiert sie ins Lakehouse. Der Change Data Feed beginnt dagegen erst bei einer bereits vorhandenen Delta-Tabelle und macht deren Weiterverarbeitung inkrementell. Beide Verfahren erfüllen damit unterschiedliche Aufgaben innerhalb derselben Verarbeitungskette:
| Strecke | Mechanismus | Typische Werkzeuge |
|---|---|---|
| Quellsystem → Lakehouse | CDC / Ingestion | Debezium, Fivetran, Lakeflow Connect |
| Innerhalb des Lakehouse (Silver → Gold) | Change Data Feed | , Streaming-Jobs |
| Lakehouse → Zielsysteme | Change Data Feed | Abgleich-Jobs, Lösch-Propagation |
In einer vollständigen Architektur werden beide Mechanismen häufig kombiniert: Ein CDC-Werkzeug liest die Quell-Datenbank und legt die Roh-Ereignisse im Lakehouse ab. Databricks beschreibt mit AUTO CDC eine deklarative Verarbeitung solcher Quell-Änderungen, die aus den Ereignissen eine konsistente Silver-Tabelle materialisiert, inklusive Deduplizierung und der Behandlung verspäteter Ereignisse. Ab der materialisierten Delta-Tabelle kann der Change Data Feed die Änderungen an weitere Tabellen oder Systeme übergeben.
Wird der Feed als Ersatz für CDC im Quellsystem betrachtet, bleibt die Erfassung der ursprünglichen Änderungen ungelöst: Die Übertragung der Änderungen vom Quellsystem in die erste Delta-Tabelle muss weiterhin separat umgesetzt werden. Die Entscheidung über CDC-Tooling und die über den Feed beziehen sich auf unterschiedliche Abschnitte der Datenpipeline.
Wie lange bleiben Änderungen lesbar?
Eine wichtige betriebliche Grenze wird häufig erst sichtbar, wenn ein konsumierender Prozess zu lange pausiert: Änderungen können nur so lange gelesen werden, wie die zugehörigen Tabellen- und Logdateien aufbewahrt werden. Die Log-Aufbewahrung einer Delta-Tabelle liegt standardmäßig bei 30 Tagen (delta.logRetentionDuration), die Frist für gelöschte Datendateien bei sieben Tagen (delta.deletedFileRetentionDuration). Nach Ablauf der Aufbewahrungsfrist kann VACUUM auch nicht mehr benötigte Änderungsdateien im Ordner _change_data entfernen.
Abfragen auf einen Versionsbereich, dessen Dateien bereits aufgeräumt sind, führen zu einem Fehler; die Databricks Knowledge Base dokumentiert den Fehler beim Zugriff auf entfernte Änderungs-Dateien nach VACUUM-Läufen. Der Prozess setzt nicht unbemerkt mit einer Datenlücke fort; er muss neu initialisiert und mit dem Zielsystem abgeglichen werden: Dazu werden Checkpoint und Startpunkt neu festgelegt und fehlende Änderungen über einen vollständigen Abgleich ergänzt.
Wie Aufbewahrungsfristen und Wartungs-Läufe je Tabellen-Klasse festgelegt werden, führen wir unter Optimize & Vacuum aus.
Aus derselben Grenze folgt eine Design-Regel: Der Feed eignet sich für die laufende Übertragung von Änderungen; als langfristiges Änderungsarchiv ist er jedoch nur eingeschränkt geeignet. Für eine dauerhafte Änderungshistorie sollten die Ereignisse fortlaufend in eine separate Archiv-Tabelle geschrieben werden; dort bleiben sie dauerhaft abfragbar.
Change Data Feed und Time Travel
Change Data Feed und Time Travel basieren auf derselben Versionshistorie der Tabelle, erfüllen jedoch unterschiedliche Analysezwecke. Der Change Data Feed liefert die Änderungen zwischen zwei Versionen für die Weiterverarbeitung. Time Travel stellt den vollständigen Tabellenstand zu einer bestimmten Version oder einem Zeitpunkt bereit, etwa für Fehleranalyse oder Audit-Anfragen. Welche Funktion passt, entscheidet die Frage:
| Frage | Werkzeug |
|---|---|
| Was hat sich zwischen Version X und Y geändert? | Change Data Feed (Änderungs-Sicht) |
| Wie sah die Tabelle zu Version oder Zeitpunkt X aus? | Time Travel (Zustands-Sicht) |
| Wie weit reichen beide zurück? | Aufbewahrung und VACUUM begrenzen beide gemeinsam |
Diese Unterscheidung erleichtert die Auswahl der passenden Funktion: Beide nutzen dasselbe Transaktionslog, lesen daraus jedoch unterschiedliche Informationen; die verfügbare Historie wird in beiden Fällen durch dieselben Aufbewahrungsregeln begrenzt. Wann sich die Zustands-Sicht für Fehleranalyse, Audits und reproduzierbare Trainingsstände eignet, klären wir im Überblick zu Time Travel.
Grenzen
Der Change Data Feed macht die Folge-Verarbeitung einer Delta-Tabelle inkrementell und ersetzt individuell entwickelte Vergleichslogik durch eine standardisierte Funktion des Tabellenformats. Einige Anforderungen liegen jedoch außerhalb seines Funktionsumfangs; diese Grenzen sollten vor der Einführung berücksichtigt werden.
Beginnt erst an der Delta-Tabelle
Die Strecke vom Quellsystem ins Lakehouse bleibt Aufgabe von CDC- und Ingestion-Tooling.
Keine Änderungs-Daten vor der Aktivierung
Die Historie beginnt erst mit der Aktivierung; für frühere Daten braucht es einen initialen Vollabgleich oder eine separate Rekonstruktion.
Lese-Reichweite hängt an der Aufbewahrung
Nach dem Entfernen der zugrunde liegenden Dateien sind frühere Änderungsbereiche nicht mehr lesbar; betroffene Prozesse müssen neu initialisiert werden.
Zusätzlicher Speicherbedarf
Updates und Löschungen erhöhen den Speicherbedarf, besonders bei hoher Änderungsfrequenz. Das gehört in die Kosten- und Wartungsplanung.
Nicht kompatible Schemaänderungen
Entfernte oder umbenannte Spalten erfordern häufig einen kontrollierten Neustart der konsumierenden Prozesse.
Diese Grenzen ordnen die Funktion ein: Der Change Data Feed stellt die Änderungsinformationen des Delta-Transaktionslogs bereit, getragen von denselben Aufbewahrungsregeln wie die Tabelle. Er liefert die Änderungen verlässlich; Voraussetzung ist, dass Aktivierungszeitpunkt, Aufbewahrungsfristen und Verarbeitungsintervalle aufeinander abgestimmt sind.
Sobald produktive Strecken auf dem Feed laufen, sollte er deshalb gemeinsam mit der Delta-Tabelle betrieben und überwacht werden: Wartungsplan, Fristen und eine klare Verantwortung dafür, dass kein konsumierender Prozess Änderungen benötigt, die bereits entfernt wurden.
Fazit
Der Change Data Feed lohnt sich, wenn nachgelagerte Prozesse auf großen Tabellen mit kleinem Änderungs-Anteil laufen und vollständige Reloads Ladefenster, Kosten oder Frequenz sprengen.
Besonders geeignet ist der Change Data Feed für Plattformen, deren Silver-Tabellen mehrere Folge-Tabellen und Zielsysteme versorgen und bei denen die verfügbaren Ladefenster durch wachsende Datenmengen zunehmend ausgelastet sind.
Typische Ausgangssituationen sind:
- nächtliche Prozesse, die den vollständigen Datenbestand in jeder Stufe erneut verarbeiten und jeden Monat länger laufen
- Aggregate und abgeleitete Tabellen, die aktueller werden sollen, ohne die verfügbaren Verarbeitungszeiten zu überschreiten
- Zielsysteme, die nur geänderte Datensätze erwarten und Löschungen zuverlässig nachvollziehen müssen
- individuell entwickelte Vergleichslogik über Zeitstempel-Spalten, die Löschungen regelmäßig übersieht
Kleine Tabellen mit seltenen Änderungen und stabile Strecken mit ausreichendem Ladefenster brauchen die Umstellung dagegen nicht; in diesen Fällen bleibt ein vollständiger Reload häufig die einfachere und leichter wartbare Lösung.
Mein Vorschlag: Nachgelagerte Prozesse zunächst nach Datenvolumen, Änderungsanteil und Ausführungsfrequenz bewerten und als Pilot die Strecke mit den höchsten Laufzeiten oder Compute-Kosten wählen. Für diese eine Strecke den Feed aktivieren, die Ausführungsintervalle auf die Aufbewahrungsfristen abstimmen und den Wiederanlauf nach überschrittener Aufbewahrungsfrist vor dem produktiven Einsatz testen, bevor weitere Strecken folgen. Damit lässt sich die Einführung schrittweise und mit messbaren Ergebnissen umsetzen.
Bewertet eure nachgelagerten Prozesse nach Datenvolumen, Änderungsanteil und Ausführungsfrequenz und wählt die Strecke mit den höchsten Laufzeiten oder Compute-Kosten als ersten Piloten.
FAQ
Der Change Data Feed ist eine Funktion des Delta-Tabellenformats, die zeilengenaue Änderungen zwischen Tabellenversionen abfragbar macht. Jede Zeile trägt ihren Änderungs-Typ (, , , ) sowie Version und Zeitstempel des zugehörigen Commits. Nachgelagerte Jobs verarbeiten damit gezielt die eingefügten, geänderten und gelöschten Zeilen einer Tabelle und müssen den Gesamtbestand dafür nicht erneut lesen.
Quellen
Vendor Primary Sources
- Metadaten-Spalten _change_type, _commit_version und _commit_timestampMicrosoft Learn / Databricks Docs
- Change Data Feed: nur Änderungen nach der Aktivierung aufgezeichnetDelta Lake Docs
- Streaming-Mengenbegrenzung mit maxFilesPerTrigger und maxBytesPerTriggerDatabricks Docs
- AUTO CDC: deklarative Verarbeitung von Quell-ÄnderungenMicrosoft Learn / Databricks Docs
- Fehler beim Zugriff auf entfernte Änderungs-Dateien nach VACUUMDatabricks Knowledge Base
