Der ETL-Prozess (Extract, Transform, Load) umfasst das Extrahieren von Rohdaten aus dem Quellsystem, das Transformieren in die erforderliche Struktur und das Laden in das Zielsystem, in der Regel ein Data Warehouse. ETL trägt dazu bei, dass Daten organisiert, bereinigt und für die nachgelagerte Verwendung in Analysen oder Anwendungen bereit sind.

Traditionell wird ETL in großen, geplanten Batches ausgeführt, oft über Nacht. Das bedeutet, dass die Daten im Zielsystem nur so aktuell sind wie der letzte Batchlauf.

Der Hauptunterschied besteht darin, wie CDC Daten extrahiert. Anstatt den Datensatz in Batches zu extrahieren, erfasst CDC die Änderungen, sobald sie auftreten. So können immer die aktuellsten Daten abgefragt werden; es ist nicht mehr nötig, sich auf die regelmäßige Batchverarbeitung zu verlassen. Dadurch können Sie schneller auf Veränderungen reagieren und erhalten genauere Einsichten.

Change Data Capture ist in erster Linie ein Prozess, der auf die effiziente Extraktion aller inkrementellen Änderungen aus einer Quelldatenbank abzielt, oft nahezu in Echtzeit, um die Belastung des Quellsystems zu minimieren.

SCD (Slow Changing Dimensions, Langsam veränderliche Dimensionen) dagegen ist eine Datenmodellierungstechnik, die im Ziel-Data Warehouse oder Analysesystem angewendet wird. Dabei geht es darum, wie der historische Zustand von Dimensionsdaten (z. B. Kundendatensätze oder Produktattribute) im Laufe der Zeit gespeichert und verwaltet werden kann.

CDC ist zwar das Tool für den effizienten Datentransport der Änderungen, diese werden aber in der Regel mit einer bestimmten SCD-Strategie angewendet, um einen vollständigen und genauen Verlauf im Zielsystem zu erhalten.

CDC kann eine Vielzahl wichtiger Anwendungsfälle ermöglichen, von der Sicherstellung der Datenkontinuität bis hin zur Unterstützung von Echtzeit-Analysen und KI.

• Replikation: Sekundäre Datenbanken oder Sicherungen bleiben mit dem primären System konsistent, da Änderungen in Echtzeit erfasst werden. Dies ist entscheidend für die Notfallwiederherstellung und Architekturen mit hoher Verfügbarkeit.
• Migration: Datenbankmigrationen werden vereinfacht, da laufende Änderungen verfolgt werden und sichergestellt wird, dass das Zielsystem die Quelle genau widerspiegelt, selbst bei Live-Migrationen.
• Echtzeitanalysen: Durch die Einspeisung von Livedaten in Analysesysteme können Sie mit CDC auf Trends und Veränderungen reagieren, sobald diese auftreten. So bleiben Sie immer gut informiert.
• Daten für das KI-Training: CDC liefert aktuellste Daten, sodass KI- und Machine-Learning-Modelle mit akkuraten, relevanten Informationen trainiert werden können, was Vorhersage und Entscheidungsfindung verbessert.
• Daten-Cloud aufbauen: CDC ist ein wichtiger Dienst zum Erstellen einer einheitlichen Daten-Cloud, die Echtzeitänderungen aus verschiedenen, isolierten Quellen (wie Transaktionsdatenbanken und SaaS-Anwendungen) in eine zentrale Analyseplattform und zurück streamt. Dies hilft dabei, Datensilos aufzubrechen und eine Single Source of Truth zu schaffen.

Datenbanken sind die häufigste und zuverlässigste Quelle für Change Data Capture, da sie alle eine zentrale Komponente gemeinsam haben: das Transaktionsprotokoll. Dieses Protokoll ist ein unveränderlicher, geordneter Datensatz aller Änderungen und damit die perfekte Grundlage für die genaue und effiziente Erfassung von Datenänderungen, ohne die Datenbankleistung zu beeinträchtigen. Wir sehen uns hier die wichtigsten Konzepte genauer an.

Bevor Daten in die eigentlichen Datenbanktabellen geschrieben werden, wird die Änderung (Einfügen, Aktualisieren oder Löschen) zuerst in einem Transaktionslog aufgezeichnet. Moderne CDC-Tools greifen auf dieses Log zu, um Änderungen nicht-invasiv zu erfassen. Dies ist ein zentraler Bestandteil der Technologie zur Datenbankreplikation. Das Konzept ist zwar universell, aber der Name für dieses Protokoll variiert je nach Datenbank. Einige Beispiele:

• PostgreSQL: Write-Ahead Log (WAL)
• Oracle: Redo-Log
• SQL Server: Transaktionsprotokoll
• MySQL: Binärlog (Binlog)

Bei großen, existierenden Datenbanken kann das Lesen des gesamten Verlaufs aus dem Transaktionsprotokoll aufgrund der Netzwerkleistung und anderer Einschränkungen unpraktisch sein. Ein gängiges Muster in der Praxis ist es, zuerst einen Massenimport durchzuführen und dann CDC zur Synchronisierung zu verwenden. Dazu sind folgende Schritte erforderlich:

1. Erstellung eines konsistenten Snapshots oder Back-ups der Datenbank zu einer bestimmten Zeit.
2. Laden des großen Snapshots in das Zielsystem
3. Der CDC-Stream wird an der genauen Logposition gestartet, an der der Snapshot aufgenommen wurde.

Mit dieser Methode wird sichergestellt, dass das Ziel vollständig mit Verlaufsdaten gefüllt und dann mit allen nachfolgenden Live-Änderungen synchronisiert wird. So führen verwaltete Dienste wie Datastream und Database Migration Service von Google Cloud nahtlose und zuverlässige Backfills durch.

Um diesen Prozess zuverlässig zu verwalten, verwendet CDC eindeutige Kennungen im Transaktionsprotokoll, die in der Regel als Logsequenznummern (LSNs) bezeichnet werden. Diese Zahlen dienen als präzise Lesezeichen für den Änderungsstream. Sie sind wichtig für:

• Positionierung: Sie wissen genau, wo im Log ein Stream gestartet oder beendet werden soll.
• Wiederherstellung: Wenn ein CDC-Prozess fehlschlägt, kann er ab der letzten erfolgreich verarbeiteten LSN neu gestartet werden. So wird sichergestellt, dass jede Änderung genau einmal erfasst wird, ohne dass Daten verloren gehen oder dupliziert werden.

Diese Mechanismen – das Transaktionslog, der anfängliche Snapshot und die Sequenznummer – sorgen gemeinsam dafür, dass die Datenbank-CDC sowohl hocheffizient als auch zuverlässig ist.

Mehrere Technologien überschneiden sich mit CDC oder ergänzen es und bieten unterschiedliche Ansätze für die Verwaltung von Datenänderungen und die Verarbeitung in Echtzeit. So schneidet CDC im Vergleich zu anderen beliebten Ansätzen ab:

HTAP kombiniert transaktionsorientierte (OLTP) und analytische (OLAP) Arbeitslasten in einem einzigen System und ermöglicht so die sofortige Analyse der Daten. HTAP eignet sich zwar gut für vereinheitlichte Analysen in einer in sich geschlossenen Umgebung, kann aber Schwierigkeiten haben, sich mit den vielfältigen und verteilten Datenquellen innerhalb eines Unternehmens zu synchronisieren. CDC hingegen eignet sich hervorragend, um die Datenkonsistenz über Systeme hinweg aufrechtzuerhalten und verteilte Workflows zu ermöglichen.

Föderierte Abfragen (und ein ähnlicher Ansatz namens „externe Tabellen“) ermöglichen es einem Data Warehouse oder einer Abfrage-Engine, Daten direkt aus einem externen Quellsystem, z. B. einer Transaktionsdatenbank, zu lesen, wenn eine Abfrage ausgeführt wird. Bei diesem Ansatz müssen Daten nicht kopiert oder verschoben werden, sondern es wird ein Live-Zugriff auf die Informationen dort ermöglicht, wo sie sich befinden.

Diese Methode eignet sich hervorragend für Ad-hoc-Analysen oder gelegentliche Abfragen, da sie sofortigen Zugriff ohne Einrichtung einer Replikationspipeline bietet. Für regelmäßig verwendete oder leistungssensitive Abfragen kann dies jedoch ineffizient sein, da jede Abfrage eine direkte Belastung des operativen Quellsystems darstellt. Im Gegensatz zu CDC, bei dem proaktiv ein Stream von Änderungen für optimierte Analysen an ein Ziel gesendet wird, ruft dieser Ansatz Daten bei Bedarf ab, was für Arbeitslasten mit hoher Frequenz möglicherweise nicht geeignet ist.

Kafka ist eine Open-Source-Plattform, die für Datenstreaming und ‑verarbeitung mit hohem Durchsatz entwickelt wurde. Kafka verwaltet zwar effizient große Datenströme, ergänzt CDC aber eher, als es zu ersetzen. CDC konzentriert sich auf die Erfassung präziser Datenbankänderungen in Echtzeit, während Kafka breitere Ereignisdaten streamt, z. B. Website-Klicks, IoT-Sensorwerte oder Artikel, die einem Einkaufswagen hinzugefügt werden. Zusammen können diese Technologien eine leistungsstarke Kombination für Echtzeit-Workflows bilden.

Während CDC einen No-Code-Ansatz zur Replikation von Daten verwendet, verbinden Integrationstechnologien, die auf der Anwendungsebene ansetzen, Systeme und SaaS-Plattformen mit einem Low-Code-Ansatz. Wenn Sie Daten beim Wechsel zwischen Plattformen transformieren möchten, können Produkte für die Einbindung auf Anwendungsebene wie Application Integration von Google Cloud besser geeignet sein.