Change Data Feed (CDF): Definition und Abgrenzung zu CDC

Change Data Feed (CDF) ist eine Funktion von Delta Lake (dem offenen Tabellenformat hinter Databricks-Tabellen). CDF listet für eine Tabelle auf, welche Zeilen zwischen zwei Ständen neu hinzugekommen, geändert oder gelöscht wurden. Zu jeder Zeile stehen dabei die Art der Änderung sowie Version und Zeitstempel des Schreibvorgangs (Commit).

Was ist Change Data Feed?

Change Data Feed ist eine Zusatzfunktion des offenen Tabellenformats Delta Lake und wird pro Tabelle einzeln eingeschaltet, entweder beim Anlegen der Tabelle oder nachträglich über die Einstellung delta.enableChangeDataFeed = true. Ohne diese Einstellung sieht eine Tabelle nur ihren aktuellen Stand; erst nach dem Einschalten protokolliert Delta Lake die Änderungen so, dass andere Verarbeitungsschritte (nachgelagerte Jobs, Dashboards, Zielsysteme) sie ab diesem Zeitpunkt lesen können.

Der Feed setzt auf dem Delta-Transaktionslog auf. Für Updates und Löschungen legt Delta Lake zusätzliche Änderungsdateien im Ordner _change_data ab; Einfügungen werden ohne zusätzliche Dateien direkt aus den regulären Datendateien abgeleitet. Der zusätzliche Schreib- und Speicheraufwand bleibt dadurch begrenzt, wächst aber bei Tabellen mit vielen Updates und Löschungen an.

Ausgabeformat ist ein Ereignisstrom aus Row-Level-Zeilen mit vier Metadaten-Spalten: _change_type mit den Werten insert, update_preimage, update_postimage und delete, dazu _commit_version und _commit_timestamp. Ein Update erscheint als zwei Zeilen (Zustand vor und nach der Änderung). Der Feed lässt sich im Batch über die SQL-Funktion table_changes('tabelle', startversion, endversion) lesen oder im Streaming über die Read-Option readChangeFeed mit Start- und End-Version beziehungsweise -Zeitstempel.

Der Begriff existiert, weil klassische Silver-nach-Gold-Verarbeitung im Lakehouse häufig vollständige Neuladen benötigt: Ohne eine Änderungs-Sicht ist unklar, welche Zeilen seit dem letzten Lauf betroffen sind, und Löschungen lassen sich über einfache updated_at-Vergleiche nicht zuverlässig erkennen. CDF stellt Änderungen zwischen zwei Tabellenversionen bereit und macht damit inkrementelle Weiterverarbeitung, SCD-Type-2-Historien und den Abgleich in Suchindex, Cache oder operatives Zielsystem ohne Voll-Reload möglich.

Abgrenzung: Change Data Capture, Time Travel und Delta-Streaming

Change Data Feed wird häufig mit benachbarten Begriffen verwechselt, die entweder an einer anderen Position der Pipeline ansetzen oder andere Informationen aus dem Transaktionslog lesen.

Begriff	Verhältnis zu Change Data Feed
[Change Data Capture (CDC)](/insights/glossar/change-data-capture/)	Erfasst Änderungen an einer operativen Quelldatenbank (Insert/Update/Delete) und transportiert sie in das Lakehouse. CDC ist die Ingest-Richtung, CDF die Downstream-Richtung innerhalb des Lakehouse. CDF ersetzt kein CDC an der Quelle.
Time Travel	Nutzt dasselbe Delta-Transaktionslog, liefert aber den vollständigen Tabellenstand zu einer Version oder einem Zeitpunkt (Zustands-Sicht) statt der Änderungen zwischen zwei Versionen (Änderungs-Sicht).
Delta-Streaming ohne CDF	Ein Structured-Streaming-Read auf einer Delta-Tabelle ohne aktivierten Feed liefert nur Einfügungen; Updates und Löschungen erscheinen nicht. Erst mit CDF stehen Row-Level-Änderungen im Streaming zur Verfügung.
Delta-Log-Aufbewahrung	Begrenzt, wie weit CDF und Time Travel gemeinsam zurückreichen. Nach Ablauf der Fristen entfernt VACUUM auch Änderungsdateien im Ordner _change_data.

Die Abgrenzung zwischen CDF und CDC ist die wichtigste, weil beide Begriffe im Databricks-Kontext auftauchen und beide Zeilen-Änderungen liefern. CDC bringt Änderungen aus einer OLTP-Quelle in die erste Delta-Tabelle im Lakehouse; typische Werkzeuge sind Debezium, Fivetran, AWS DMS und Lakeflow Connect. CDF gibt Änderungen aus einer Delta-Tabelle an weitere Delta-Consumer weiter. Beide Verfahren werden in einer vollständigen Architektur häufig kombiniert: CDC liefert die Bronze-Schicht, CDF speist die Silver- und Gold-Schichten.

Beispiel: Inkrementelle Gold-Aggregation über `table_changes`

Eine Kundentabelle silver.customers versorgt eine Gold-Aggregation der aktiven Segment-Verteilung. Der Feed wird für die Silver-Tabelle einmalig aktiviert:

sql

ALTER TABLE silver.customers
SET TBLPROPERTIES (delta.enableChangeDataFeed = true);

Ab diesem Zeitpunkt schreibt Delta Lake bei jedem Commit die zugehörigen Änderungen mit. Ein täglicher Batch-Job liest den Feed für den Versionsbereich seit dem letzten Lauf:

sql

SELECT *
FROM table_changes('silver.customers', 41, 42);

Für Version 42 erscheinen nur die tatsächlich veränderten Zeilen mit _change_type, _commit_version und _commit_timestamp. Ein Update auf Kunde 5, dessen Segment von standard auf premium wechselt, erscheint als zwei Zeilen mit update_preimage und update_postimage; eine gelöschte Zeile trägt _change_type = delete. Die Gold-Tabelle aktualisiert daraufhin nur die betroffenen Segment-Zähler, statt die vollständige Kundentabelle neu zu aggregieren. Für kontinuierliche Verarbeitung liest ein Structured-Streaming-Job dieselbe Tabelle mit .option("readChangeFeed", "true") und einer Start-Version.