CDC mit Qlik in der Praxis Datenintegration mit Change Data Capture
Anbieter zum Thema
Datenintegration in Echtzeit kann ein Erfolgsfaktor sein. Change Data Capture (CDC) überträgt und repliziert Daten aus verschiedenen Datenquellen in analytische Anwendungen und Reports in Echtzeit. Dabei werden nur Änderungen gegenüber der vorhergehenden Übertragung neu erfasst. Das reduziert die Datenmenge auf ein Minimum und erhöht die Geschwindigkeit des Prozesses. Wenn es sich nämlich um ein Cloud Data Warehouse handelt, ist die Übertragung von Daten ein Kostenfaktor. Drei Unternehmen haben mit Qlik Erfahrungen im CDC-Einsatz gemacht.

Moderne Analyse-Anwendungen bauen nicht mehr nur auf traditionellen Data Warehouses oder auf jüngeren Data Lakes auf, sondern beschleunigen die Datenintegration mithilfe von Change Data Capture (CDC), besonders wenn die Datenbereitstellung mit Streaming (Kafka, Azure Event Hub, Spark, Amazon Kinesis usw.) optimiert wird.
Weil die Geschäftsprozesse, die von den Analysen gestützt werden, mit CDC schlanker und schneller sein können, erhöht sich die Kundenzufriedenheit. Diese Anwendererfahrung lässt sich mit einer effizient gestalteten CDC-Pipeline personalisieren, was ebenfalls die Kundenzufriedenheit steigert.
Datenanalyse ist ein Prozess, der die Produktivsysteme neben der Transaktion und Storage zusätzlich belastet. Indem CDC die Rohdaten durch Replikation auf Pipelines umleitet, die an den Transaktionssystemen vorbeiführen, wird das Gesamtsystem entlastet, während die angepeilte Analyse-Anwendung in Data Warehouse oder Data Lake oder im Cloud-nativen Microservice zuverlässig ihre Daten in Echtzeit erhalten.
Dabei kann ein ETL-Prozess (ETL: Extraktion, Transformation, Laden) des Filterns und der Transformation zum Einsatz kommen. Die Erzeugung von Metadaten versorgt alle datenverarbeitenden Anwendung im System mit beschreibenden Informationen, die das Auffinden und Auswerten von erfassten Daten erleichtern. Zudem lassen sich mit diesen Informationen die automatisierten Abläufe im CDC anreichern und sicherstellen.
Daten-Pipelines sind zerbrechlich und störanfällig, besonders in Zeiten ständiger, globaler Cyberattacken. Im Batch-Betrieb sind sie zudem langsam. Mit CDC stehen dem Dateningenieur drei verschiedene Erfassungsmethoden und drei verschiedene Bereitstellungsmethoden zur Verfügung. Mit diesem Werkzeugkasten lässt sich die Zuverlässigkeit einer Datenpipeline gewährleisten.
Änderungen, Quellen und Ziele
CDC identifiziert und erfasst nur die neuesten Änderungen an Produktiv- und Metadaten, die die Quelle innerhalb einer bestimmten Zeitspanne (normalerweise Sekunden oder Minuten) verzeichnet. Zu den erfassten Zeilenänderungen zählen Inserts, Deletes und Updates. Bei Änderungen an Metadaten ist die Sache komplizierter: Mithilfe der Data Definition Language (DDL) werden Datenobjekte selbst, wie etwa Spalten, Tabellen oder Datentypen, erstellt, geändert und/oder entfernt.
Die Zielsysteme sind, wie erwähnt, Datenbanken aller Art, Ziele in der Public Cloud, Data Warehouses, Data Lakes, Streaming- und Messaging-Plattformen sowie Microservices in Containern.
Funktionsweise
Es gibt drei Methoden, Änderungen an Daten bzw. Metadaten in CDC zu erfassen. Die jeweilige Methode belastet das Gesamtsystem unterschiedlich stark, sollte also mit Sorgfalt ausgewählt werden. Das gleiche gilt für die drei Methoden der Bereitstellung.
- 1. Trigger: Das Kopieren von Daten zu Change-Capture-Tabellen wird durch Quelltransaktionen „ausgelöst“. Das ist eine bewährte Methode, wenn nicht auf Transaktionsprotokolle zugegriffen werden kann. Die Belastung ist „mittelhoch“.
- 2. Query (Abfrage): Die Software kennzeichnet neue Transaktionen in den Tabellenspalten mit Zeitstempeln, Versionsnummern usw., und die CDC-Engine fragt die Produktiv-Datenbank regelmäßig nach Updates. Die Systembelastung ist „niedrig“, aber keineswegs minimal, denn jede Abfrage beansprucht Ressourcen.
- 3. Log Reader: Änderungen werden durch Scannen der Backup/DR-Transaktionsprotokolle erkannt. Diese Methode wird bevorzugt, wenn auf Log-Dateien zugegriffen werden kann. Die Mehrzahl aller Anwendungen erzeugt Logfiles.
Methoden der Bereitstellung
- 1. Transaktionsbezogen: CDC kopiert Updates (also Transaktionen) in derjenigen Reihenfolge, in der sie an der Datenquelle vorgenommen wurden. Diese Methode eignet sich, wenn die Integrität der der Sequenz wichtiger ist als eine besonders hohe Performance. Use Case: terminierte Finanzberichte.
- 2. Aggregiert (Batch-optimiert): CDC sendet Updates aus unterschiedlichen Quellen gebündelt an das Ziel. Diese Methode eignet sich, wenn die Performance wichtiger ist als die Integrität der Sequenz im Zielsystem. Use Case: Aggregierte Trendanalysen mit möglichst vielen Datenpunkten.
- 3. Stream-optimiert: CDC repliziert Quell-Updates in einen von Plattformen wie Apache Kafka, Azure Event Hub und Amazon Kinesis gesteuerten Messaging-Stream. Anders als bei anderen Methoden steuern die Ziele Data in Motion und nicht Data at Rest. Hierfür gibt es viele neue Anwendungsfälle, darunter standortspezifische Echtzeit-Kundenangebote und die Analyse von laufenden Börsendaten.
Agent oder nicht?
Für den Aufbau einer CDC-Architektur gibt es zwei Optionen. Agenten-basiertes CDC ist auf dem Quellserver gespeichert und interagiert direkt mit der Produktivdatenbank. CDC-Agenten sind nicht optimal, weil sie CPU-Zyklen, Memory und Speicherplatz von den Produktiv-Workloads der Quelle abziehen und so die Performance negativ beeinflussen.
Agentenlose Architekturen, die ohne die Installation eines Agenten auskommen, sind moderner und belasten weder Quelle noch Ziel. Die Software interagiert über einen separaten, zwischengeschalteten Server. Das minimiert Störungen und verbessert die Anwenderfreundlichkeit. Letzteres macht beispielsweise die Plattform des Software-Anbieters Qlik.
CDC mit Qlik
Qlik ist ein langjähriger Anbieter von Data Discovery- und Datenintegrations-Software. Die Lösung „Qlik Data Integration für CDC-Streaming“ bietet eine umfassende Lösung zum Umwandeln von Produktivdatenbanken in Live-Datenstreams für moderne Analysen und Microservices. Für die Streams kommen die drei erwähnten Tools infrage: Apache Kafka (Confluent), Azure Event Hub und Amazon Kinesis.
Mit Qlik können Data Engineers nach Herstellerangaben die End-to-End-Übertragung von Daten von unterschiedlichen Quellen zu unterschiedlichen Zielen vollständig automatisieren – in Echtzeit. Die agentenlose Konfiguration und eine einfache grafische Benutzeroberfläche sollen das Einrichten, Steuern und Überwachen von Datenpipelines erleichtern. Der Footprint ist durch die Verwendung von Log Readern minimal.
Die Software ist auf einem zwischengeschalteten Server gespeichert, der sich zwischen einer oder mehreren Quellen und einem oder mehreren Zielen befindet. Mit Ausnahme von SAP-Quellen, die spezielle, native Anforderungen stellen, wird weder an der Quelle noch am Ziel Agentensoftware benötigt. Mit den Qlik-Lösungen zur Data-Warehouse-Automatisierung und Data-Lake-Erstellung sollen Kunden ihre Datenpipelines sogar noch weiter beschleunigen können. Ein Datenkatalog stellt die Metadaten allen befugten Mitarbeitern im Unternehmen zur Verfügung.
Anwender
Aggreko ist ein globaler Anbieter mobiler Mietanlagen für Stromerzeugung und für Kälte-/Klimatechnik-Lösungen. Das Unternehmen wollte Entscheidungen künftig stärker datenbasiert treffen. Dafür mussten zuerst die operativen Daten aus der ganzen Welt zentralisiert werden.
Aggreko wollte einen klaren und einheitlichen Prozess für das Erfassen von Daten aus seinen Quellsystemen einführen, hatte aber Schwierigkeiten mit den unterschiedlichen Pipeline- Anforderungen. Es sah so aus, als müsste das Unternehmen für jede Datenquelle eine individuelle Lösung entwickeln, was schnell unkontrollierbar werden würde.
Die Mitarbeiter machten sich auf die Suche nach einem Produkt, das das Management aller Erfassungs-Pipelines übernehmen konnte. Die Wahl fiel aus zwei Gründen auf Qlik: Die Software arbeitet besonders ressourcenschonend und belastet die Produktivsysteme nur minimal. Die einfache Implementierung würde dem kleinen Data-Engineering-Team von Aggreko erlauben, dieses große Projekt schnell umzusetzen.
In einer Woche war das CDC-Streaming von Qlik für das ERP-System von Aggreko installiert, ohne die Produktivsysteme zu beeinträchtigen. Aggreko kann jetzt Erkenntnisse in Echtzeit realisieren und plant, die Lösung auch auf andere Datenquellen auszuweiten
Generali Schweiz
Generali Schweiz, die Schweizer Niederlassung des weltweit agierenden Versicherungskonzerns, beschäftigt 1.800 Mitarbeiter an 56 Standorten und betreut über eine Million Kunden. Als zentrale Legacy-Anwendungen die Kunden-Apps und Channel-Anwendungen immer stärker belasteten, beschloss das Unternehmen, seine Datenarchitektur zu modernisieren. Die IT-Mitarbeiter wollten erstens über verschiedene Kanälen aktuelle, qualitativ hochwertige Daten verfügbar machen und zweitens die Bereitstellung des IT-Service verbessern.
Gleich zu Beginn musste eine riesige Datenmenge repliziert und somit eine umfangreiche Integration durchgeführt werden. Das Team entwickelte eine hybride Verbindungsplattform auf Basis von Qlik und Confluent (Apache Kafka), unter anderem weil diese beiden Lösungen reibungslos zusammenarbeiten. Die Qlik-Software des CDC-Servers befindet sich zwischen den Datenquellen und den Zielsystemen. Sie liest und interpretiert die Informationen und sendet sie an das von Generali festgelegte Ziel.
Statt Tage dauert es jetzt weniger als zehn Sekunden, um Daten von Quell- in Zielsysteme zu übertragen. Die Datenextraktion erfolgt ohne Beeinträchtigung des Tagesgeschäfts oder der Anwendungen. Von vielen Applikationen oder Kanälen kann jetzt auf eine konsistente Informationsbasis zugegriffen werden. Durch den Zugang zu präzisen Echtzeit-Daten wurden Kundenservice und -bindung verbessert. Außerdem kann Generali jetzt auch die Entwicklung von agilen Lösungen unterstützen.
Veritix
Veritix, eine Tochter von AXS, entwickelt digitale Ticketing-, Eventmarketing und CRM-Anwendungen für den Profisport und Veranstaltungen auf der ganzen Welt. Mit ihren Analyseberichten können ihre Kunden demografische Gruppen gezielter ansprechen, die Zahl der verlängerten Dauerkarten verbessern und neue Fans in die Stadien holen.
Die Transaktionsdatenbank von Veritix wurde sowohl für Produktivdaten als auch das Reporting verwendet. Folglich war sie nicht für Analysen optimiert, und die Performance war ein zusätzliches Problem. Das Team beschloss, ein separates Data Warehouse mit Amazon Redshift zu erstellen.
Anfangs gingen die Data Engineers bei Veritix davon aus, dass sie maßgeschneiderte Tools oder Standardlösungen zur Replikation der Daten in die Cloud verwenden müssten. Sie starteten einen ersten Versuch, der 21 Stunden dauerte. Dann entdeckten sie Qlik. In nur zwei Stunden hatten sie die Software installiert, konfiguriert und Hunderte Millionen von Datensätzen nach Redshift überführt.
Das Data Warehouse enthält jetzt circa drei Terabyte an Informationen. Milliarden von Datensätzen stehen für Kundenanalysen zur Verfügung. Doch Qlik hat nicht nur die Performance-Anforderungen von Veritix erfüllt: Es hat auch die Erwartungen des Teams in puncto Benutzerfreundlichkeit übertroffen.
(ID:49205324)