Daten aus unterschiedlichen Systemen zu verbinden, steht auf der To-Do-Liste im Anwendungs-Handling ganz oben. Dafür gibt es viele Lösungen, jeweils mit Vor- und Nachteilen. Das Thema so zu lösen, wie Anwender sich es schon immer gewünscht haben, verspricht die Big-Data-Technik "Apache Kafka".
Foto: optimarc - shutterstock.com
Aktuell wird Apache Kafka bei immer mehr Firmen eingesetzt. Das ist auch nicht verwunderlich, denn für Datenverteilungsaufgaben bildet es neben "Apache Avro" als Payload-Format eine solide Basis für jedwede Datenintegration - egal ob auf Tabellenebene, auf Business-Objekt-Ebene oder für Realtime Replication. Aus Sicht von Apache Kafka sind das nur verschiedene Use Cases. Auch komplexe Transformationen lassen sich auf vielseitige Art anflanschen, angefangen von herkömmlichen ETL Tools bis hin zu Streamprocessing-Werkzeugen.
Big Data Tools, die an Grenzen stoßen
Es wurden schon viele Technologien zum Thema Datenintegration erfunden. Etwa ETL (Extract-Transform-Load) Tools, deren Fokus in erster Linie darauf lag, Daten umzuformen. Dabei handelt es sich in aller Regel um mächtige Werkzeuge, die aber nur als Batchverarbeitung wirklich gut funktionierten. Das Heilsversprechen der EII (Enterprise Information Integration) Tools war, diesen Prozess einfacher zu machen, indem die Daten nicht mehr kopiert werden müssen, sondern zur Laufzeit miteinander verknüpft werden.
Lesen Sie mehr über Apache Kafka:
Enterprise Application Integration (EAI) setze wieder einen anderen Fokus: Nicht Tabellen sollten die Basis sein, sondern Applikationsobjekte. Schließlich ist die Kerninformation, dass zum Beispiel ein neuer Kundenstammsatz angelegt wurde und nicht, dass sich fünf Tabellen geändert haben. Realtime Replication wiederum kann Daten nur kopieren, dafür aber mit sehr geringer Latenz. Betrachtet man all diese Ansätze aus einer technischen Perspektive, stößt man ständig auf physikalische Limits und Widersprüche.
Ein Tool pro Daten-Use-Case
Die aktuelle Situation mit verschiedensten Ansätzen und Tools kann man schön bei SAP sehen. Mit SAP Data Services liefert der Softwarehersteller eines der besten ETL Tools, die am Markt verfügbar sind (siehe Gartner Magic Quadrant for Data Integration). Der EII Ansatz, also Data Federation, ist in allen Business Intelligence Tools (SAP Analytics Cloud, Business Objects) und der HANA-Datenbank (Smart Data Access, Smart Data Integration) implementiert. Für EAI gibt es SAP Process Orchestration. Realtime Replication kommt in Form von SAP SLT und Sybase Replication Server sowie HANA Smart Data Integration. Zusätzlich können Anwender noch SAP Graph als API Directory, Cloud Platform Integration, SCP Open Connectors und vieles mehr nutzen.
Für jeden Typ der Integration gibt es im SAP-Portfolio also mindestens ein Tool. Auf der anderen Seite steht der Anwender und fragt sich: "Ich wollte doch nur Daten von A nach B bringen, warum ist immer alles so kompliziert?". Verlässt man jedoch die ausgetretenen Denkpfade, gibt es durchwegs Möglichkeiten, das Ganze zu vereinfachen. Einen großen Anteil daran haben Techniken, die eigentlich aus der Big-Data-Welt stammen und für andere Zwecke gedacht sind.
Die richtige Big-Data-Technik?
Die erste Frage könnte sein: Was ist der Unterschied zwischen Tabellen und einem Applikationsobjekt? Auf abstrakter Ebene betrachtet stellt ein Applikationsobjekt ein logisches Datenmodell dar, und die Tabellen sind eine mögliche physikalische Implementierung. Eine viel direktere Darstellung wäre die Speicherung in Json oder XML, oder einem noch besser geeigneten Format. Hauptsache es erlaubt eine hierarchische Gliederung der Daten.
Im oben genannten Beispiel mit dem Kundenstamm, müsste dieses Objekt Kundennamen, die verschiedenen Adressen des Kunden, mögliche Kontaktinformationen und dergleichen beinhalten. Wenn die Datenintegration dieses Format perfekt unterstützt, gibt es keinen Grund mehr, je ein Tool für die Daten- beziehungsweise Applikationsintegration zu bauen. Eine Tabelle ist dann nur ein besonders triviales, flaches, Business-Objekt.
Viele weitere nützliche Informationen zum Thema Big Data finden Sie hier in unserem Online-Special
In der Big-Data-Welt sind derartige nicht-relationale Strukturen sogar üblich. Ein gut passendes Format dafür ist Apache Avro, weil es die Formatdefinition, eine effiziente Speicherung und eine schnelle Verarbeitung beinhaltet.
Die zweite grundsätzliche Entscheidung dreht sich um die Frage, wie viele Abnehmer es für die jeweiligen Daten gibt. In der Vergangenheit handelte es sich in aller Regel um eine 1:1 Beziehung: Das SAP-System liefert die Daten an das SAP BW Data Warehouse. Das Zeiterfassungssystem sendet die Daten an das HR Modul.
Im wirklichen Leben war die Situation jedoch nie so einfach. Außerdem werden heutige IT Landschaften immer komplexer. Macht es dann Sinn, dass beispielsweise zehn Zielsysteme alle paar Sekunden das Quellsystem mit der Frage quälen: "Was hat sich geändert?". Das erzeugt nur eine hohe Grundlast auf dem ERP-System. In so einer Landschaft wäre es viel geschickter, wenn es einen zentralen Verteiler gäbe. Dann muss das ERP-System die Daten nur an einen Service weiter reichen und alle Datenkonsumenten holen sich die Daten von dort.
Auch dieser Ansatz wurde schon mehrmals versucht. Man erinnere sich an die SOA-Bewegung (Service Orientated Architecture) oder an IBM MQ als den bekanntesten Vertreter aus der Enterprise Message Bus Kategorie. Diese Lösungen waren alle nicht schlecht, sind aber meist von den realen Anforderungen überfordert gewesen. Eigentlich einfache Dinge, die aber trotzdem den breiten Einsatz verhindert haben. Zwei Punkte möchte ich im Speziellen nennen: Das Payload Format und das Handling der Queues.
Koppelt man zwei Systeme, muss man sich auf eine Schnittstellendefinition einigen. Wie sieht ein Kundenstammsatz denn genau aus - Felder, Datentypen, erlaubte Werte, usw.? Jede Änderung in der Schnittstelle bedeutet, dass sowohl der Sender als auch der Empfänger synchron aktualisiert werden müssen. Bei zwei System ist das machbar - sind jedoch viele Systeme beteiligt, wird es schnell unübersichtlich und praktisch unmöglich.
Man benötigt also eine Technik, die einerseits eine feste Strukturdefinition vorschreibt und andererseits eine gewisse Toleranz erlaubt. Der klassische Weg dorthin führt über unterschiedliche Versionen der APIs. Doch das geht auch einfacher und wird bei Datenbanken ständig gemacht: Was passiert, wenn man eine zusätzliche Spalte an eine Tabelle hinzufügt? Bei sauberer Programmierung nichts - alle lesenden Zugriffe funktionieren weiterhin. In der Big-Data-Welt hat man diesen Ansatz weiterentwickelt und nennt das Schema Evolution. Apache Avro unterstützt das sehr schön.
Diesen Vorteil bringt Apache Kafka
Für Messaging wurde in der Vergangenheit meist ein Publish/Subscribe Modell verwendet. Dabei wird eine Änderung versendet. Alle, die sich als Datenempfänger registriert haben, bekommen die entsprechenden Daten. Klingt im ersten Moment einleuchtend, entspricht jedoch nicht den realen Anforderungen. Als Konsument möchte ich(!) entscheiden, welche Daten ich haben möchte und wann ich sie bekomme. In vielen Fällen wird es sofort - also Realtime - sein, aber es gibt auch andere Szenarien:
Das Data Warehouse liest nur einmal am Tag.
Im Falle eines Fehlers in der Verarbeitungslogik, müssen die letzten paar Stunden nochmals verarbeitet werden.
Während der Entwicklung möchte man beim Testen die gleichen Daten immer und immer wieder bekommen.
Genau hier liegt der Vorteil von Apache Kafka. Es ermöglicht all das, ohne andere Nachteile zu erzeugen und in einer Art und Weise, die einfach, komfortabel und schnell funktioniert.
Vom logischen Prinzip her gesehen werden alle Änderungsdaten hinten an ein Log-File angehängt. Jeder Consumer sagt, von wo weg gelesen werden soll und Kafka übergibt dementsprechend diese Daten. Die Verbindung wird aber weiter offen gelassen, so dass neue Datensätze mit einer Latenz im Millisekundenbereich nachgereicht werden.
Damit schlägt man zwei Fliegen mit einer Klappe: Der Consumer bekommt die von ihm angeforderten Daten - er hat die Kontrolle - und er bekommt die Daten in Realtime. Zumindest so lange, bis er selbst die Verbindung schließt. Des Weiteren können auch mehrere Instanzen des gleichen Consumers parallel laufen. Kafka kümmert sich dabei um das Load Balancing. Wird eine weitere Consumer-Instanz gestartet, oder reagiert eine bestehende Instanz nicht mehr, wird jede dieser Situationen von Kafka automatisch behandelt. Das macht die Programmierung von Consumern einfach und robust.
Sollten Sie sich also sich mit Datenintegration beschäftigen müssen, achten Sie darauf wie Ihre Architektur und die eingesetzten Tools mit Apache Kafka harmonieren. Kleine Anekdote zum Schluss: Was erzählte SAP auf der TechEd 2019, um den Kunden ihre Sorgen rund um die Datenintegration zu nehmen? Man setzt auf EII (HANA Data Fabric) und Publish/Subscribe, harmonisiert die Datenmodelle und unterstützt Strukturänderungen über API Versionen. (ba)