Change Data Capture (CDC): Definition und Abgrenzung

Change Data Capture (CDC) ist ein Verfahren, das jede Änderung in einer Datenbank (Anlegen, Aktualisieren, Löschen einer Zeile) sofort erfasst und als Änderungsstrom an andere Systeme weitergibt. Jede geänderte Zeile wird zu einem Ereignis, das die Art der Änderung sowie den Zustand vor und nach der Änderung enthält. Empfänger-Systeme (etwa ein Reporting-System oder eine Analytics-Plattform) können damit den aktuellen Stand der Quelldatenbank fortlaufend nachbilden, ohne jedes Mal die komplette Tabelle zu kopieren.

Was ist Change Data Capture?

CDC ist ein Integrations-Muster, keine konkrete Software. Es beschreibt, wie Änderungen aus einer operativen Datenbank (also der Datenbank hinter einer laufenden Geschäftsanwendung wie Shop, ERP oder CRM) mit möglichst geringer Verzögerung in andere Systeme fließen: zum Beispiel in ein Data Warehouse (zentrale Datenbank fürs Reporting), in ein Lakehouse (kombinierter Speicher für Rohdaten und Analytik, etwa auf Databricks), in einen Suchindex, einen Cache oder in eine weitere Fachanwendung. Der Kern-Unterschied zum klassischen Nachtlauf: Statt einmal am Tag die halbe Tabelle zu kopieren, wird jede einzelne Zeilenänderung innerhalb weniger Sekunden weitergereicht.

Für die Erkennung der Änderungen existieren drei Implementierungs-Klassen. Log-basiertes CDC liest das Transaktions-Log der Datenbank (Postgres WAL, MySQL binlog, SQL Server Transaction Log, Oracle Redo Log) und rekonstruiert daraus Row-Level-Änderungen. Trigger-basiertes CDC installiert Datenbank-Trigger, die jede Änderung in eine zusätzliche Änderungs-Tabelle schreiben, aus der Consumer sie später abholen. Abfrage-basiertes CDC (query-based) fragt in Intervallen nach Zeilen mit einer bestimmten updated_at-Marke und leitet daraus den Delta ab.

Log-basiertes CDC hat sich als De-facto-Standard etabliert, weil es die Quelle kaum belastet, Delete-Operationen erfasst und einen exakten, zeitlich geordneten Änderungsstrom liefert. Trigger-basiertes CDC belastet die Schreib-Transaktion und ist bei hoher Last problematisch. Abfrage-basiertes CDC verpasst Deletes und rückdatierte Updates und liefert nur einen Näherungswert.

Das Ausgabeformat ist ein Ereignisstrom aus Row-Level-Events. Ein Event enthält typischerweise den Operations-Typ (Create, Update, Delete), einen Primärschlüssel, das before- und after-Image der Zeile sowie Metadaten wie den Log-Zeitstempel und die Transaktions-ID. Das Debezium-Schema ist in vielen Werkzeugen die Referenz für diese Struktur. Als Transportschicht kommen Message-Broker wie Kafka oder Kinesis zum Einsatz, alternativ ein Managed-Konnektor, der die Events direkt in eine Ziel-Tabelle schreibt. Typische Werkzeuge sind Debezium, AWS DMS, Fivetran, Oracle GoldenGate und Lakeflow Connect für Databricks.

Abgrenzung: Change Data Feed, klassisches ETL und Zero-ETL

CDC wird häufig mit benachbarten Begriffen verwechselt, die entweder auf einer anderen Architektur-Schicht ansetzen oder das Muster nur anders verpacken.

Begriff	Verhältnis zu CDC
Change Data Feed (CDF)	Delta-Lake-Feature, das Zeilen-Änderungen einer Delta-Tabelle auslesbar macht. Quelle ist eine Delta-Tabelle im Lakehouse. CDF ist die Downstream-Fortsetzung, wenn CDC-Daten bereits im Lakehouse gelandet sind.
Klassisches ETL (Batch-Extrakt)	Periodisches Voll- oder Delta-Extrakt aus einer Datenbank per SQL-Query. Erfasst keine Deletes, hohe Latenz, hohe Last auf der Quelle bei jedem Lauf.
[Zero-ETL](/insights/glossar/zero-etl/)	Managed-Integration eines Cloud-Anbieters zwischen einer OLTP-DB und einem analytischen Store. Nutzt CDC unter der Haube, verbirgt aber die Pipeline. CDC ist das Muster, Zero-ETL eine Bereitstellungsform.
Datenreplikation (physisch)	Storage-Ebene, spiegelt Blöcke oder Log-Records ohne Consumer-Semantik. CDC arbeitet auf Row-Ebene und liefert konsumierbare Events.

Die Abgrenzung zwischen CDC und CDF ist besonders relevant, weil beide Begriffe im Databricks-Kontext auftauchen. CDC bringt Änderungen aus einer operativen Quelle in das Lakehouse (Ingest-Richtung); CDF gibt Änderungen aus einer Delta-Tabelle an weitere Delta-Consumer weiter (Downstream-Richtung).

Beispiel: Postgres-Änderungen via Debezium in eine Delta-Silver-Tabelle

Eine Bestellplattform betreibt ihre operative Datenbank auf Postgres. Bestellungen, Positionen und Zahlungen werden dort transaktional geschrieben; das Analytics- und Reporting-Team arbeitet auf einer Delta-Lakehouse-Schicht in Databricks.

Debezium wird auf dem Postgres-Cluster als Logical-Replication-Consumer eingerichtet und produziert pro geänderter Zeile ein JSON-Event auf einem Kafka-Topic:

json

{
  "op": "u",
  "ts_ms": 1720699200000,
  "before": {"order_id": 4711, "status": "created", "total": 129.90},
  "after":  {"order_id": 4711, "status": "paid",    "total": 129.90},
  "source": {"lsn": "0/1A2B3C4D", "table": "orders"}
}

Ein Structured-Streaming-Job in Databricks liest den Topic, mappt die Events auf die Ziel-Struktur und führt sie per MERGE INTO in eine Delta-Silver-Tabelle silver.orders zusammen. Für op=c und op=u wird der Nachher-Zustand geschrieben, für op=d die Zeile gelöscht oder als is_deleted=true markiert. Die Latenz zwischen einem Commit in Postgres und der Sichtbarkeit in der Silver-Tabelle liegt bei sauberer Auslegung im Sekundenbereich.