Change Data Capture (CDC) für Streaming Ingestion

Entscheidungsträger in Unternehmen fordern immer mehr von Data Analytics. Data Engineers stehen unter ständigem Druck innovative und effektive Methoden zu entwickeln, um Daten aus operativen Betriebssystemen für BI- und KI-Initiativen verfügbar zu machen.

Für diese Entscheidungsträger ist die Aktualität der Daten, auf deren Basis sie ihre Entscheidungen treffen, ein Schlüsselelement zur effektiven Steuerung des Unternehmens. Batch Ingestion erfüllt diese Anforderung nicht, da sie keine Echtzeitreplikation von Daten oder keine Streaming Ingestion ermöglicht. Zusätzlich ist diese Herangehensweise ressourcenintensiv und muss außerhalb der Geschäftszeiten realisiert werden. Teilweise reicht diese Zeit nicht aus, um einen Overhead der Betriebssysteme während der Geschäftszeiten zu vermeiden.

Change Data Capture erfasst und repliziert Streaming-Daten mit minimalem Overhead für Echtzeiteinblick

Change Data Capture (CDC) ermöglicht eine andere Strategie: kontinuierliches Streaming, Aufnehmen und Replizieren von Daten aus Betriebssystemen inkrementell – wobei nur Änderungen an den Daten berücksichtigt werden - möglicherweise nach einmaliger erstmaliger Extraktion historischer Daten.

Der CDC-Ansatz bietet den Vorteil, dass Daten aus Betriebssystemen mit minimalem Overhead gestreamt werden können, lange Stapelfenster eliminiert werden, eine Echtzeitansicht der Daten für Analytics-Initiativen bereitgestellt wird und vor allem keine Änderungen an der Datenquelle erforderlich sind.

Es gibt jedoch viele Ansätze, potenzielle Fallstricke und Überlegungen auf dem Weg zur optimalen CDC-Ingestion.

Der CDC-Ansatz bietet den Vorteil, dass Daten aus Betriebssystemen mit minimalem Overhead gestreamt werden können, lange Stapelfenster eliminiert werden, eine Echtzeitansicht der Daten für Analytics-Initiativen bereitgestellt wird und vor allem keine Änderungen an der Datenquelle erfordert.

Es gibt jedoch viele Ansätze, potenzielle Fallstricke, Entscheidungspunkte, Optimierungen und Überlegungen auf dem Weg zur optimalen CDC-Ingestion.

Drei Kernaspekte für eine erfolgreiche CDC-Ingestion:

1) Wägen Sie zwischen Leistung, Latenz und Quellen-Overhead für verschiedene CDC-Monitoring-Mechanismen ab.

Abhängig vom Datenquellentyp gibt es normalerweise mehrere Möglichkeiten, Änderungen aus einem Datensatz zu extrahieren. Ein CDC-Replikationsprozess ist nur so schnell wie sein schwächster Punkt. Daher spielt es keine Rolle, wie skalierbar Ihre Replikations- oder Aufnahmepipeline ist, wenn die für die Quelle verwendete CDC-Extraktionsmethode langsam ist.

Beispiel:
In einer Oracle-Datenbank können wir CDC auf viele verschiedene Arten implementieren, z. B. durch Trigger, JDBC-Abfragen basierend auf einer Datumspseudospalte oder eine Redo-Log-Extraktion. Die ersten beiden sind äußerst ineffizient, sowohl aus Sicht der Leistung als auch vor allem hinsichtlich des Overheads der Datenbank.

Datenbank-Trigger sind extrem aufwändige, synchrone Vorgänge, die jede einzelne Datenbanktransaktion verzögern, um den Trigger auszuführen. Die auf JDBC-Abfragen basierende Extraktion umfasst umfangreiche Bereichsscans für die Datentabellen, die selbst dann einen erheblichen Overhead verursachen können, wenn die Tabelle korrekt indiziert und partitioniert ist.

CDC mit Redo-Log-Extraktion ist die effizienteste Methode, um Änderungen asynchron zu extrahieren, ohne den Betrieb zu verlangsamen und ohne zusätzliche E / A in den Datentabellen. Aber selbst dann gibt es mehr als eine Möglichkeit, Änderungen aus dem Redo-Protokoll zu extrahieren.

Wir können Log Miner für CDC verwenden, eine von Oracle bereitgestellte API, die ursprünglich für forensische Analysen und manuelle logische Wiederherstellungsszenarien vorgesehen war. LogMiner war jedoch nicht für die Erfassung von Änderungsdaten vorgesehen, kann jedoch vorerst verwendet werden, selbst wenn Oracle einige seiner Funktionen langsam ablehnt. Es ist wichtig zu beachten, dass Log Miner jedoch auf einen Kern in der Datenbank beschränkt ist, was ungefähr bis zu 10.000 Änderungen pro Sekunde entspricht. Mehr als das und Log Miner fängt an „Lag“ zu akkumulieren, der sich vergrößert bis ein „Re-Stream“ stattfindet.
Die effektivste verfügbare Methode (zehnmal komplizierter als LogMiner oder andere Ansätze) ist ein direktes Redo-Log-Parsing. Ein direktes Redo-Log-Parsing liest das Redo-Log binär und parst die Bytes basierend auf den Offset-Positionen, wobei quasi ein Reverse Engineering des Binär Outputs durchgeführt wird. Während nur eine Handvoll Lösungen über diese Funktion verfügen, bietet diese Methode Geschwindigkeiten von bis zu 100.000 Änderungen pro Sekunde bei noch geringerem Overhead für die Datenbank.

Die Kompromisse zwischen Leistung, Latenz und Quell-Overhead sind die Schlüsselfaktoren bei der Auswahl der richtigen CDC-Strategie.

3) Synchronisieren Sie den aktuellen Status (Initial Capture) der Daten mit CDC-Änderungen, um eine Replikation nahezu in Echtzeit zu erreichen

Für eine Replikation muss häufig zuerst die aktuelle „Version“ der Daten abgerufen und dann alle CDC-Änderungen darauf angewendet werden. Wir nennen den ersten Schritt „Initial Capture“. Es gibt einige Optimierungsprobleme bei Initial Capture und der Synchronisation zwischen Initial Capture und CDC:

• Initial Capture sollte robust sein und Daten mithilfe von Massenparallelverarbeitung (Bulk Parallel Processing) extrahieren:
  Initial Capture, der Vorgang des Extrahierens des aktuellen Status des Datensatzes, sollte robust sein und den Datensatz mithilfe von Massenparallelverarbeitungsmethoden extrahieren. Es gibt normalerweise mehrere Möglichkeiten, Daten aus einer Quelle zu extrahieren, entweder über JDBC oder über APIs. Die Auswahl und Optimierung des besten Ansatzes ist der Schlüssel, um sicherzustellen, dass bei einer Replikation mit mehreren Objekten akzeptable Service-Levels beibehalten werden. Jede Quelle verfügt über eine einzigartige, optimierte Methode zur Massenextraktion. Das Re-Streaming ist aus vielen möglichen Gründen, wie z. B. nächtlichen Ladevorgängen, nicht synchronisierten Objekten, Fehlern und vielem mehr, sehr häufig. Daher ist Initial Capture kein einmaliger Vorgang.

• Identifizieren Sie automatische, zuverlässige Möglichkeiten, um eine ordnungsgemäße Synchronisierung sicherzustellen. Vermeiden Sie manuelle Synchronisierung:
  Ein Replikationsprozess erfordert eine Kombination aus dem vorhandenen Status des Datensatzes sowie der Erfassung aller Änderungen ab diesem Zeitpunkt. Der Zeitpunkt wird als Synchronisationsversatz bezeichnet. Dieser Punkt wird normalerweise entweder durch einen Zeitstempel verfolgt, genauer jedoch durch Betrachten einer internen Änderungssequenznummer. Der Synchronisationsversatz ist erforderlich, um unabhängig vom Quelltyp eine erfolgreiche, genau einmalige Datenreplikation für jeden Quelltyp zu erzielen, in dem Daten statisch gespeichert werden. Initial Capture und die CDC-Änderungen manuell zu synchronisieren, ist eine mühsame Aufgabe, die aufgrund der hohen Häufigkeit von Änderungen im Datensatz fehleranfällig ist. Es ist wichtig sicherzustellen, dass es automatische und zuverlässige Möglichkeiten gibt, um eine ordnungsgemäße Synchronisierung sicherzustellen.
  
  
• Entkoppeln Sie die Abhängigkeit von Initial Capture und CDC-Prozess, um die Leistung zu verbessern:
  Initial Capture kann, selbst wenn sie optimiert ist, aufgrund der Größe des Datensatzes immer noch sehr lange dauern. Deshalb sollte die Abhängigkeit zwischen dem Abschluss der beiden Prozesse beseitigt werden, indem beide Prozesse parallel ausgeführt werden. Auf diese Weise kann der Gesamtprozess zum Erreichen einer Echtzeitreplikation viel schneller einen „synchronisierten“ Status erreichen. In den meisten Quellen werden die Initial-Capture-Daten und die CDC-Änderungen ohnehin nicht aus demselben logischen Speicher extrahiert, sodass diese Kapazität zur Verbesserung der Gesamtleistung genutzt werden können, um die Synchronisation schneller zu realisieren. Dies ist besonders wichtig, wenn viele Objekte in einer Warteschlange behandelt werden, da sich die „Zeit bis zur Synchronisierung“ für jedes aufeinanderfolgende Objekt in der Warteschlange weiter verzögern kann.
  

Dies sind nur einige der Herausforderungen und Überlegungen zur Optimierung, die für die Streaming-Ingestion mit CDC von entscheidender Bedeutung sind. Das Erlernen der Grundlagen kann sich relativ einfach anfühlen, aber wie alles im Leben steckt der Teufel im Detail. Ein schlechter CDC-Service, ob selbst entwicklet oder kommerziell erworben, kann nicht nur Ihr Analytics-Projekt gefährden, sondern vor allem das Betriebssystem, wodurch wiederum das gesamte Unternehmen gefährdet ist. Wenn Sie diese Überlegungen für Innovationen bei der Data Ingestion aus Betriebssystemen berücksichtigen, sollten Ihre BI- und KI-Projekte immens profitieren.

Der Beitrag basiert auf dem Buch "Top Design & Implementation Challenges für Change Data Capture (CDC) - Strategische Überlegungen für eine erfolgreiche Streaming-Ingestion."

> Hier können Sie das komplette eBook CDC kostenfrei herunterladen

Dieser Beitrag ist zuerst hier erschienen. Mit freundlicher Genehmigung des Autors

Der Beitrag basiert auf dem Buch "Top Design & Implementation Challenges für Change Data Capture (CDC) - Strategische Überlegungen für eine erfolgreiche Streaming-Ingestion." > Hier können Sie das komplette eBook CDC kostenfrei herunterladen