Change Data Feed

Große Firmen speichern ihre Daten in Tabellen, also in großen Listen mit Zeilen und Spalten. Eine solche Tabelle kann Millionen Zeilen haben, zum Beispiel alle Bestellungen eines Onlineshops. Sie verändert sich ständig: Zeilen kommen dazu, andere werden korrigiert oder gelöscht. Ein Change Data Feed ist ein zusätzlicher Datenstrom, der genau diese Veränderungen protokolliert. Statt zu sagen „so sieht die Tabelle jetzt aus“, sagt er „das hat sich seit gestern geändert“. Andere Programme können diesen Strom lesen und ihre eigenen Kopien der Daten aktualisieren, ohne alles neu zu laden.

Warum niemand die ganze Tabelle neu laden will

Daten liegen in Unternehmen selten nur an einer Stelle. Dieselben Bestelldaten landen in einem Bericht für das Management, in einer Suchfunktion und in einem Modell, das Betrug erkennen soll. All diese Kopien müssen aktuell bleiben. Ohne Änderungsprotokoll bleibt nur ein grober Weg: die komplette Tabelle jede Nacht neu kopieren.

Das ist teuer. Cloud-Anbieter rechnen nach verarbeiteten Datenmengen und nach Rechenzeit ab. Wenn sich von 500 Millionen Zeilen nur 200.000 geändert haben, verarbeitet man 99,96 Prozent der Daten völlig umsonst. Ein Change Data Feed reduziert die Arbeit auf den tatsächlich veränderten Teil. In der Praxis sinken Laufzeiten dadurch oft von Stunden auf Minuten.

Der zweite Gewinn ist Aktualität. Wer nur nachts komplett kopiert, hat tagsüber veraltete Zahlen. Mit einem Änderungsstrom kann ein System alle paar Minuten nachziehen. Für ein Dashboard, das Umsätze in nahezu Echtzeit zeigen soll, ist das der entscheidende Unterschied.

Was in einer Änderungszeile steht

Der Feed besteht selbst wieder aus Zeilen. Jede Zeile enthält die eigentlichen Daten plus einige Zusatzangaben. Die wichtigste ist die Art der Änderung: eingefügt, gelöscht, oder ein Wert wurde überschrieben. Bei einer Überschreibung liefern viele Systeme zwei Zeilen, den Zustand vorher und den Zustand nachher. So kann ein nachgelagertes Programm nachvollziehen, was genau passiert ist.

Dazu kommt eine Versionsnummer und ein Zeitstempel. Tabellenformate wie Delta Lake, Apache Iceberg oder Apache Hudi nummerieren jeden Schreibvorgang durch. Ein lesendes System merkt sich, bis zu welcher Version es gekommen ist. Beim nächsten Lauf fragt es einfach: Was ist seit Version 4711 passiert? Das Prinzip ähnelt einem Lesezeichen im Buch.

Technisch ist das möglich, weil diese Formate Daten nie wirklich überschreiben. Sie schreiben neue Dateien und führen ein Protokoll darüber, welche Dateien zu welcher Version gehören. Der Change Data Feed liest im Kern dieses Protokoll aus. Verwandt, aber nicht identisch ist Change Data Capture: Dabei zapft man das Änderungsprotokoll einer klassischen Datenbank an, etwa von PostgreSQL. Der Zweck ist derselbe, der technische Ort ein anderer.

Wo der Begriff in Produkten und Meldungen auftaucht

Am häufigsten liest man ihn im Umfeld von Databricks und dem Format Delta Lake. Dort ist Change Data Feed eine Einstellung, die man pro Tabelle einschaltet. Danach steht der Änderungsstrom über eine normale Abfrage zur Verfügung. Konkurrierende Formate wie Iceberg und Hudi bieten vergleichbare Funktionen unter eigenen Namen an.

Im Alltag merkt man davon nichts direkt, spürt aber die Folgen. Wenn eine Banking-App eine Buchung innerhalb weniger Minuten anzeigt, steckt oft eine solche Änderungspipeline dahinter. Auch Empfehlungen in Shops oder Streamingdiensten werden über Änderungsströme nachgeführt, statt einmal täglich komplett neu berechnet zu werden.

Für KI-Anwendungen gewinnt das Thema an Bedeutung. Ein Suchsystem, das Firmendokumente durchsucht, muss geänderte Dokumente neu verarbeiten. Der Änderungsstrom sagt ihm, welche das sind. Ein verbreiteter Irrtum ist übrigens, ein Change Data Feed sei ein vollständiges Archiv. Das ist er nicht: Alte Einträge werden nach einer eingestellten Frist gelöscht, oft nach 30 Tagen.