Knowhow und Erfahrungen gesammelt in unserem Blog
01.09.2022 Peter Peltzer
Warum investieren so viele Unternehmen in Ihre Datenarchitektur?
Datengetriebene Unternehmen generieren kontinuierlich Mehrwert durch ihre strategische Nutzung oder erkennen zumindest ihr Potential. Bevor man beginnen kann Daten zu analysieren, um datengetriebene Entscheidungen zu treffen, müssen diese konstant verfügbar und abrufbar sein. Will man Daten in Echtzeit auswerten, stellt dies eine noch größere Herausforderung dar. Hat man zusätzlich auch noch mehrere Quellen, die man gleichzeitig, getrennt oder in Kombination analysieren will, kann das erstmal völlig überwältigend sein. Eines ist zumindest klar: Die Datenarchitektur muss so aufgebaut sein, dass Transfers reibungslos und in Echtzeit stattfinden. Eine Möglichkeit diese Herausforderung zu meistern bietet Apache Kafka.
Kafka ist eine Software welche event-driven Data-Streaming ermöglicht. Damit wird nichts anderes als Live-Kommunikation zwischen Systemen aktiviert. Kommunikation zwischen Systemen findet häufig in Form von Batch-Processing statt. Der Unterschied zum Event-Streaming liegt darin, dass sogenannte Jobs stapelweise bzw. in Batches ausgeführt werden und die Kommunikation nicht fließend stattfindet. Bei zunehmender Datenkomplexität wird die Anzahl an Jobs, die Daten in Batches transferiert, nicht mehr überschaubar und man stößt an ein Limit, von dem aus nicht weiter skaliert werden kann. Kafka beseitigt dieses Problem, indem es auf reine Simplizität setzt.
In Kafka werden alle Datenquellen “Producers” genannt und generieren Events. Jedes Mal, wenn ein Event ausgelöst wird, beispielsweise wenn ein Kunde ein Produkt bestellt, werden Daten produziert. Diese werden an Kafka gesendet und Consumer können sie dann konsumieren. Um eine adäquate Übersicht zu gewährleisten, benutzt Kafka sogenannte Topics. Topics sind Container für zusammengehörige Events und demnach wird jedes Event einem bestimmten Topic zugeordnet. Ein Topic könnte somit beispielsweise Bestellungen oder Retouren darstellen. Anhand dieses Beispiels würden alle Bestellungen (Events) in das Topic “Bestellungen” fließen und alle Retouren (ebenfalls ein Event) in das Topic “Retouren”. Diese wiederum werden in Kafka in sogenannte Partitionen aufgeteilt. Ein Event wird in Kafka als Message bezeichnet und einer Partition eines Topics zugewiesen. Eine Partition kann beispielsweise eine Kunden-ID sein. So gelangen alle Bestellungen (Topic) von dem gleichen Kunden in dieselbe Partition und lassen sich als Bestellverlauf eines Kunden speichern.
Was ist Apache Kafka?
Beispiel von Events in Log form:
[01.01.22] Kunde Nr. 101 bestellt Artikel Nr. 001.[10.03.22] Kunde Nr. 101 bestellt Artikel Nr. 002.[15.03.22] Kunde Nr. 101 schickt Artikel Nr. 002 zurück.Dies ist eine sehr elegante Lösung, um Daten zu transferieren. Aber warum sollte man diesen Weg gehen, wenn man alle Daten wie gewöhnlich in ein Data Lake exportieren kann? Kafka ist ein Message Broker und ersetzt somit keine Datenbank. Um genau zu sein ist eine Datenbank ein mögliches Zielsystem, wohin produzierte Daten, nachdem sie durch Kafka gelaufen sind, ankommen können. Der Mehrwert liegt in der Skalierbarkeit und in der Reduzierung der Code Base und Komplexität. Angenommen BI Spezialisten wollen die Daten zu den Bestellungen analysieren, dann müssen die Daten diesen Data Consumern bereitgestellt werden. Data Engineers bauen Data Pipelines zu einem bestimmten Zielsystem, um diese Daten bereitzustellen. Anhand dieses Beispiels müsste -wenn die Buchhaltung auch alle Bestelldaten erhalten möchte- erneut eine Data Pipeline für die Needs dieser Data Consumer entwickelt werden. Anschließend kommen weitere Data Consumer wie ML Engineers oder die Warenlogistik, die diese Daten erneut auf unterschiedlichen Systemen benötigen, ins Spiel. So entwickelt man schnell eine hohe Abhängigkeit an ein hoch spezialisiertes Data Engineering Team und eine komplexe Code Base für alle verschiedenen Systeme. Kafka hilft dieses Bottleneck zu vermeiden, indem es von allen Producern (Datenquellen) die Daten als Events aufnimmt und beliebig viele Consumer füttert. So werden aus einer großen Monolith App mehrere Microservices, die leichter zu handhaben sind.
Data Engineers bauen mit Kafka skalierbare und schnelle Daten-Pipelines, die aufgrund der hohen Simplizität, die Kafka bietet, leicht zu verstehen und zu bearbeiten sind. Die Producer API sendet Messages aus verschiedenen Quellen an Topics in einem Kafka Cluster. Ein Cluster, oder auch Broker, ist eine Computer-Instanz oder ein Container zur Berechnung von Kafka Prozessen. Mit der Consumer API werden die Messages aus den Topics gezogen und gelesen. Die Stream API zieht Messages aus einem Topic, transformiert sie und lädt diese in einem anderen Topic in den Kafka Cluster. Dies ist besonders hilfreich, wenn ein Consumer die Daten in anderer Form benötigt und sich aus einem anderen Topic bedient. Connect API bezeichnet genau diese Schnittstelle zwischen Kafka Cluster und Zielsystem der Consumer. Das Zielsystem kann z. B. eine SQL-Datenbank, eine ordinäre CSV Datei oder eine Cloud Plattform sein. Die Connect API ermöglicht es direkte Verbindungen zu den Zielsystemen aufzubauen.
Die hohe Simplizität von Kafka ist zwar einer der Hauptgründe und Vorteile, warum es bei vielen Unternehmen Anwendung findet, diese hat aber ihren Preis. Kafka bietet einige Features und kann sehr nützlich für die Entwicklung von Daten-Pipelines sein, dennoch ist es keine Universallösung. Wer vor hat größere Datenmengen zu speichern, sollte nicht planen Kafka langfristig für die Datenspeicherung zu verwenden. Dadurch, dass Daten in Kafka nicht gelöscht und ersetzt werden, häufen sich viele redundante Datensätze, die irgendwann ein kostspieliger Faktor werden können. Was die Speicherung von Daten angeht ist es somit besser auf relationale und nicht relationale Datenbanken zu migrieren. Einen weiteren Nachteil stellen hohe Aufwände in der Datentransformation dar. Kafka wurde in erster Linie für den Message Transfer entwickelt. Wird der Zweck des Message Transfers eingehalten, können Performance oder Ressourcen Probleme ausgeschlossen werden. Messages zu modifizieren, bevor sie einem Consumer gesendet werden, verlangsamt nicht nur die gesamte Plattform, sondern ist auch mit hohen Aufwänden bei der Entwicklung von Daten-Pipelines verbunden, da diese die Kommunikation zwischen Producern und Consumern verwalten. Die Schwächen von Kafka überschatten somit keinesfalls die vielen Vorteile, die es bringt, und wird daher auch von viele führenden Firmen wie LinkedIn, Cisco und Goldman Sachs genutzt.
Daten in Echtzeit zur Verfügung zu stellen, wird für viele Unternehmen zunehmend wichtiger. Um den Analysebedürfnissen und der wachsenden Anzahl an Datenquellen gerecht zu werden, braucht es einfache und skalierbare Lösungen. Eine Anwendung kann nicht gleichzeitig skalierbar und einfach sein, sowie unzählige Features besitzen. Es wird immer einen Trade-off geben, der bei der Wahl einer Softwarelösung bedacht werden sollte. Kafka bietet eine einfache und schnell umsetzbare Lösung und kann die Anwendungsentwicklung zum Event-Stream-Processing für Unternehmen beschleunigen. “Easy to operate, easy to set up and very easy to deploy” sind die Grundmerkmale von Kafka. Wem Features fehlen und wer auf die leichte Handhabbarkeit verzichten kann, braucht eher eine Full-Stack Solution und ist somit mit umfassenderen Alternativen wie z. B. Apache Pulsar besser bedient. Der Einstieg in eine event-basierte Streaming Architektur kann sich durchaus lohnen, um die Qualität und Performance der Datenverteilung voranzutreiben. Dies ermöglicht nicht nur schneller an hochwertige und zeitlich aktuelle Ergebnisse bei Datenanalysen zu gelangen, sondern auch hoch komplizierte Architekturen der Datenverteilung zu abstrahieren.