Change Data Capture (CDC): der Leitfaden zum Abgleich in Echtzeit

Change Data Capture (CDC) ist eine Familie von Entwurfsmustern und Techniken, die Änderungen an den Daten einer Quelldatenbank erkennen und erfassen, also Einfügungen, Aktualisierungen und Löschungen, und diese Änderungen nahezu in Echtzeit an nachgelagerte Systeme weitergeben. Statt eine Tabelle in Abständen vollständig zu kopieren, wie es Batch-ETL tut, beobachtet CDC die Quelle fortlaufend und überträgt nur die geänderten Datensätze. Das senkt Latenz und Verarbeitungsaufwand nachgelagerter Pipelines erheblich.

Was ist CDC?

Jede operative Datenbank nimmt laufend Änderungen entgegen: Bestellungen kommen hinzu, Kundenanschriften ändern sich, gekündigte Abos verschwinden. In klassischen Datenarchitekturen holen Batch-Läufe diese Änderungen in festen Abständen ab, als Voll- oder Teilkopie in ein Data Warehouse oder einen Data Lake. Die nachgelagerten Systeme hinken der Quelle damit immer einige Stunden hinterher, und diese Verzögerung ist für operative Analyse, Dashboards in Echtzeit, ereignisgetriebene Microservices und Feature-Pipelines für Machine Learning immer seltener hinnehmbar.

CDC löst das, indem es jede Änderung in der Datenbank als Ereignis behandelt, das sofort erfasst und weitergegeben wird. Data Warehouse, Data Lake oder Zielanwendung erhalten jede Einfügung, Aktualisierung und Löschung in dem Moment, in dem sie geschieht, und bleiben damit nahezu synchron mit der Quelle. Auswertungen laufen dann auf Daten, die Sekunden oder Minuten alt sind, statt Stunden oder Tage.

CDC ist außerdem die Grundlage ereignisgetriebener Architekturen, in denen Microservices auf Zustandsänderungen einer Datenbank reagieren. Das Outbox-Muster, in verteilten Systemen weit verbreitet, nutzt CDC, um bei jedem Eintrag in eine Outbox-Tabelle zuverlässig ein Ereignis auf einen Message-Bus zu veröffentlichen. So wird jedes Ereignis genau einmal zugestellt, ohne das Problem des doppelten Schreibens. Siehe auch: Data Lineage, ETL und ELT, Datenpipeline.

CDC und Batch-ETL

Batch-ETL und CDC sind zwei grundverschiedene Wege, Daten aus operativen Systemen in analytische und nachgelagerte Systeme zu bringen:

• Latenz: Batch-ETL liefert nach Zeitplan, stündlich oder täglich; CDC liefert fortlaufend, mit Latenzen im Bereich von Sekunden bis wenigen Minuten.
• Datenmenge je Lauf: Ein Volllauf kopiert bei jedem Durchgang alle Zeilen, gleich was sich geändert hat; CDC erfasst nur geänderte Zeilen und verkleinert die übertragene Menge je Abgleich erheblich.
• Last auf der Quelle: Große Batch-Läufe erzeugen spürbare Abfragelast auf der Quelldatenbank; log-basiertes CDC liest das Transaktionsprotokoll, ohne eine einzige Abfrage gegen die Quelltabellen zu stellen, und kostet damit fast keine Betriebsleistung.
• Historie der Änderungen: Batch-ETL liefert in der Regel eine Momentaufnahme und verliert die Zwischenzustände zwischen zwei Läufen; eine Zeile, die zwischen zwei Läufen angelegt und wieder gelöscht wurde, taucht nie auf. CDC hält jeden Zwischenzustand als eigenes Ereignis fest.
• Löschungen: Batch-ETL tut sich schwer damit, Löschungen zu erkennen; eine Zeile, die zwischen zwei Vollkopien verschwindet, ist nicht von einer Zeile zu unterscheiden, die die inkrementelle Abfrage schlicht nicht erfasst hat. CDC hält Löschungen ausdrücklich fest, mit Schlüssel und Zeitstempel der gelöschten Zeile.

Der Preis ist Vielschichtigkeit: Batch-ETL ist leicht zu bauen und leicht zu prüfen; CDC verlangt Verständnis für Transaktionsprotokolle, Pflege der Konnektorkonfiguration und einen Plan für Schemaänderungen im Änderungsstrom. Wo eine tägliche oder stündliche Latenz reicht, bleibt Batch-ETL einfacher. Für Analyse in Echtzeit, ereignisgetriebene Architekturen und Pipelines mit Data Observability sind die Vorteile von CDC überzeugend.

Vier Methoden für CDC

1. Log-basiertes CDC

Log-basiertes CDC liest das Transaktionsprotokoll der Datenbank, also das Write-ahead-Log (WAL) in PostgreSQL, das Binärlog (binlog) in MySQL oder das Redo-Log in Oracle, und erfasst so jedes bestätigte Änderungsereignis. Es ist die beste Methode, weil sie die Quelldatenbank nicht belastet (es läuft keine zusätzliche Abfrage), jede Änderung einschließlich Löschungen erfasst und Reihenfolge und Zeitpunkt exakt bewahrt. Debezium, das führende quelloffene CDC-Rahmenwerk, arbeitet so, ebenso die meisten CDC- und ELT-Werkzeuge für Unternehmen.

2. Trigger-basiertes CDC

Trigger-basiertes CDC nutzt Datenbank-Trigger, die bei Einfügung, Aktualisierung und Löschung auslösen und die Änderung in eine eigene Audit- oder Änderungstabelle schreiben. Das funktioniert auf jeder Datenbank mit Triggern und verlangt keine besonderen Rechte zum Lesen von Transaktionsprotokollen. Der Nachteil ist der Leistungsverlust: Trigger laufen synchron bei jedem Schreibvorgang mit, verlängern jede Transaktion auf den Quelltabellen und vervielfachen die Schreiblast.

3. Zeitstempelbasiertes CDC (abfragebasiert)

Zeitstempelbasiertes CDC fragt die Quelltabelle in Abständen nach Zeilen ab, deren last_modified oder updated_at jünger ist als der letzte Lauf. Es ist die einfachste Methode, denn es braucht nur eine geplante Abfrage, hat aber schwerwiegende Grenzen: Jede Tabelle muss eine gepflegte Zeitstempelspalte haben, Löschungen entgehen ihr vollständig (eine gelöschte Zeile hat keinen Zeitstempel mehr), und sie erzeugt regelmäßig Abfragelast auf der Quelle.

4. Differenzbasiertes CDC (Momentaufnahmen)

Differenzbasiertes CDC zieht in festen Abständen vollständige Momentaufnahmen der Quelltabellen und vergleicht je zwei aufeinanderfolgende, um Änderungen zu finden. Es erkennt Löschungen am zuverlässigsten und funktioniert auch dort, wo weder Logzugriff noch Trigger möglich sind. Der Preis sind die Kosten der Vollkopien und die Verzögerung durch das Intervall. Meist dient es als Rückfalloption, wenn log-basierte Verfahren ausscheiden.

Log-basiertes CDC im Detail

Wer log-basiertes CDC verstehen will, muss wissen, wie ein Transaktionsprotokoll arbeitet. Jeder bestätigte Schreibvorgang wird darin festgehalten, bevor er in die Datendateien wandert. Dieses Protokoll ist die Wahrheit der Datenbank für den Wiederanlauf: Stürzt sie ab, bevor Änderungen auf der Platte liegen, spielt sie das Protokoll beim Start erneut ein und erreicht wieder einen stimmigen Zustand. CDC-Konnektoren machen sich das zunutze, lesen das Protokoll als Strom von Änderungsereignissen und übersetzen jeden Eintrag in ein strukturiertes Ereignis für nachgelagerte Systeme.

In PostgreSQL arbeitet log-basiertes CDC über logische Replikation: Die Datenbank veröffentlicht logische Änderungen, nicht physische Seitenänderungen, an einen Replikations-Slot, den der Konnektor ausliest. Der Konnektor merkt sich seine Position im Slot und weiß so, welche Einträge er verarbeitet hat. Auch nach einem Neustart geht damit keine Änderung verloren. In MySQL übernimmt das Binärlog diese Rolle, das der Konnektor über das Replikationsprotokoll liest.

Schemaänderungen (DDL-Ereignisse) in der Quelle sind die eigentliche Schwierigkeit für log-basiertes CDC. Wird eine Spalte ergänzt, umbenannt oder entfernt, muss der Konnektor Ereignisse nach altem und nach neuem Schema verarbeiten. Ausgereifte Rahmenwerke wie Debezium führen dafür eine Schema-Registry, die zu jedem Ereignis die damals gültige Schemaversion festhält, sodass Konsumenten auch ältere Ereignisse nach einer Schemaänderung noch richtig lesen.

Die erste Momentaufnahme ist die Startphase von log-basiertem CDC: Bevor der Konnektor Änderungen streamt, liest er den aktuellen Stand der Quelltabelle konsistent aus und gibt dem Konsumenten damit eine Grundlage. Danach schaltet er auf das Transaktionsprotokoll um und holt alle Änderungen nach, die seit dem Beginn der Momentaufnahme angefallen sind. Dieses Muster aus Momentaufnahme und anschließendem Strom sorgt dafür, dass nachgelagerte Konsumenten ein vollständiges, lückenloses Bild bekommen.

Werkzeuge: Debezium, Fivetran, Airbyte

Debezium: der quelloffene Standard

Debezium ist die führende quelloffene CDC-Plattform, entwickelt unter dem Dach von Red Hat und eingebracht in das Ökosystem von Apache Kafka. Es bietet Konnektoren für PostgreSQL, MySQL, MongoDB, Oracle, SQL Server und weitere Datenbanken, allesamt log-basiert. Die Konnektoren laufen als Plugins in Kafka Connect und veröffentlichen Änderungsereignisse als JSON- oder Avro-Nachrichten in Kafka-Topics. Weil Debezium quelloffen ist und in der eigenen Infrastruktur läuft, ist es weitgehend konfigurierbar und rechnet nicht pro Zeile ab, was es für große CDC-Strecken wirtschaftlich macht.

Fivetran: betreut, aber pro Zeile

Fivetran ist eine betreute ELT-Plattform mit CDC-Konnektoren für viele Datenbanken und SaaS-Datenquellen. Fivetran nimmt den Teams die Infrastruktur ab: Quelle und Ziel konfigurieren, den Rest erledigt die Plattform, also Schemaerkennung, erste Momentaufnahme, laufendes Streaming der Änderungen und Umgang mit Schemaänderungen. Diese Bequemlichkeit kostet pro Zeile, was bei großen Quellen ins Gewicht fällt. Am häufigsten wird Fivetran genutzt, um SaaS-Quellen (Salesforce, HubSpot, Stripe) an Data Warehouses anzubinden, wo log-basiertes CDC gar nicht möglich ist und Fivetran stattdessen zeitstempel- oder API-basiert erfasst.

Airbyte: quelloffen oder betreut

Airbyte ist eine quelloffene ELT-Plattform mit großer Konnektorbibliothek. Wie Fivetran gleicht sie viele Quellarten mit Data Warehouses und Lakes ab. Für Datenbanken mit Logzugriff nutzt Airbyte für CDC unter der Haube Debezium, für andere Quellen abfragebasierte Verfahren. Die quelloffene Fassung lässt sich selbst betreiben, mit voller Kontrolle und ohne Kosten pro Zeile; Airbyte Cloud übernimmt den Betrieb.

Einsatzfälle

• Data Warehouse in Echtzeit: Änderungen aus operativen Datenbanken über Kafka nach Snowflake, BigQuery oder Redshift streamen und Auswertungen auf Daten fahren, die Sekunden statt Stunden alt sind.
• Cache verwerfen: Ändern sich Datensätze in der operativen Datenbank, müssen Dienste, die sie zwischengespeichert haben, ihren Cache verwerfen. CDC liefert dafür einen verlässlichen Auslöser mit geringer Latenz, ohne den schreibenden Dienst an die Cache-Verwaltung zu koppeln.
• Ereignisse zwischen Microservices: Das Outbox-Muster nutzt CDC, um fachliche Ereignisse aus der Datenbank eines Microservice zuverlässig an einen Message-Broker zu geben, und löst damit das Problem des doppelten Schreibens, bei dem der Datenbankschreibvorgang gelingt, die Veröffentlichung des Ereignisses aber scheitert.
• Suchindex abgleichen: Elasticsearch- oder OpenSearch-Indizes mit der führenden Datenbank synchron halten. CDC gibt Einfügungen, Aktualisierungen und Löschungen direkt an den Index weiter, sodass ein regelmäßiger Vollaufbau entfällt.
• Prüfung und Compliance: eine vollständige, geordnete Historie jeder Änderung an sensiblen Daten führen, für regulatorische Nachweise, forensische Untersuchungen oder Streitfälle. Der CDC-Strom wird zum Prüfprotokoll.
• Feature Stores für Machine Learning: operative Änderungen nahezu in Echtzeit in den Feature Store geben, damit Modelle mit aktuellen Merkmalswerten arbeiten und nicht mit veralteten Batch-Berechnungen.

CDC und Data Lineage

CDC hinterlässt eine reichhaltige Spur für Lineage: Jedes Änderungsereignis trägt seine Quelltabelle, die Art des Vorgangs (Einfügung, Aktualisierung, Löschung), einen Zeitstempel und, bei log-basiertem CDC, die Transaktionskennung und die Position im Protokoll. Diese Herkunftsangaben sind für Data Lineage besonders wertvoll, weil sie nicht nur den aktuellen Stand liefern, sondern die vollständige Geschichte, wie er zustande kam.

Für die nachgelagerten Systeme, die CDC-Ereignisse verarbeiten, also Data Warehouses, Data Lakes und Feature Stores, verläuft die Lineage-Kette vom operativen Ursprungssystem über den CDC-Konnektor und Kafka bis zum Ziel. Tritt weiter unten ein Problem der Datenqualität auf, führt die Lineage die Engineers zurück zu dem einen Ereignis oder der Ereignisfolge, die es eingebracht hat, anhand von Transaktionszeitstempel und Quelltabelle.

CDC ermöglicht außerdem eine Form von Data Observability unmittelbar an der Quelle: Wer Rate, Volumen und Schema der CDC-Ereignisse beobachtet, erkennt Auffälligkeiten, etwa einen plötzlichen Anstieg von Löschungen, eine Spalte, die in manchen Ereignissen fehlt, oder eine Lücke in den Zeitstempeln, und bemerkt Probleme im Quellsystem, bevor sie sich weiter unten als Mängel der Datenqualität zeigen.

Governance und Dawiso

Data Governance für CDC-Strecken hat einige eigene Anforderungen. Am kritischsten im Betrieb ist die Schema-Evolution: Ändert sich das Quellschema, enthalten die Ereignisse plötzlich andere Felder, und Konsumenten scheitern. Eine Schema-Registry (etwa die Confluent Schema Registry mit Avro oder Protobuf) zusammen mit Regeln zur Schemakompatibilität verhindert, dass eine Schemaänderung nachgelagerte Konsumenten unangekündigt zerbricht.

Sensible Daten im CDC-Strom sind der zweite große Punkt für die Governance. Weil CDC-Ereignisse den vollen Zeileninhalt der Quelltabellen tragen, enthalten sie häufig personenbezogene und andere schützenswerte Daten. Werden solche Ströme nach Kafka oder auf andere, im Unternehmen breit zugängliche Message-Broker veröffentlicht, gehören sensible Felder in der Nutzlast maskiert oder verschlüsselt, also mit denselben Regeln auf Spaltenebene, die schon für die Quelltabellen gelten.

Dawiso bindet die Metadaten von CDC-Strecken in seine Lineage- und Governance-Plattform ein. Indem es sowohl die Systeme anbindet, aus denen CDC-Daten stammen, als auch die, die sie verbrauchen, baut Dawiso durchgehende Lineage-Graphen über die Streaming-Schicht hinweg: von der operativen Tabelle über Konnektor und Kafka-Topics bis zu den Tabellen und Modellen im Data Warehouse. Genau das braucht die Wirkungsanalyse: Ändert sich ein Quellschema, benennt Dawiso sofort alle CDC-Konsumenten und alle betroffenen Auswertungen.

Dawiso verfolgt außerdem Klassifizierung und den Status der Data Governance für die Daten, die durch CDC-Strecken laufen. Ist eine Spalte der Quelltabelle als personenbezogen eingestuft, sorgt Dawiso dafür, dass diese Einstufung im Lineage-Graphen bis zu den abgeleiteten Tabellen weiterwandert. Governance-Teams können dann prüfen, ob an jedem Punkt des Streaming-Wegs die passende Maskierung oder Zugriffskontrolle greift. So werden CDC-Strecken zu einem sichtbaren Teil des Governance-Programms und bleiben nicht undurchsichtige Infrastruktur.