Interview mit Lars Pfannenschmidt und Frank Wisniewski

Use Cases für Apache Kafka: „Viele Data-Probleme sind gar nicht so big“

Kypriani Sinaris

Apache Kafka ist momentan in aller Munde. Der bei LinkedIn geborene Dienst ist besonders für große Big-Data-Projekte spannend, meinen die JAX Speaker Lars Pfannenschmidt und Frank Wisniewski. Wir haben sie im Interview gefragt, was genau hinter Apache Kafka steckt, für welche Use Cases der Dienst konzipiert ist und wo noch Verbesserungsbedarf besteht.

JAXenter: In eurer Session auf der JAX habt ihr über Apache Kafka gesprochen. Für alle die, die damit noch nicht viel zu tun hatten: Könnt ihr kurz umreißen, worum es sich dabei handelt?

Lars Pfannenschmidt, Frank Wisniewski: Apache Kafka ist ein verteilter, partitionierender und replizierender Dienst, der für jegliche Form von “Datenstrom” verwendbar ist. Oft wird Kafka mit einem verteilten commit log verglichen, d.h., einer persistenten Aufzeichnung aller Transaktionen, bekannt aus dem Bereich der Datenbanken. Im Fall von Kafka sind diese Transaktionen Nachrichten. Alle Nachrichten sind der Reihenfolge nach persistiert und können zu einem beliebigen Zeitpunkt konsumiert werden. Zusätzlich verfügt Kafka über Mechanismen, die erlauben, dieses Log auf mehrere Rechner zu verteilen und zu replizieren. Diese ermöglichen eine konfigurierbare Ausfallsicherheit innerhalb des Clusters und exzellente Skalierungsmöglichkeiten.

JAXenter: Kafka wird mit Messaging-Brokern wie ActiveMQ verglichen – wo liegen hier die Unterschiede?

Lars Pfannenschmidt, Frank Wisniewski: Es ist unserer Meinung nach keine gute Idee, die klassischen Messaging-Broker direkt mit Kafka zu vergleichen. Beim Messaging sind oft zwei Garantien für die Performance entscheidend:

  1. Die gewählte Zustellgarantie: a) at most once b) at least once c) exactly once. Die klassischen Broker bieten (oft) exactly once an, also das Zustellen einer Nachricht genau ein mal. Dies kann sich in verteilten Systemen als ziemlich kompliziert und somit teuer herausstellen. Im Gegensatz dazu benutzt Kafka at least once im Protokoll, sodass ein Konsument von Nachrichten diese entweder mehrfach verarbeiten können muss oder sich durch das “Merken” von Nachrichten-Revisionen, den sogenannten Offsets, exactly once simuliert. Aber auch at most once, also das einmalige Publizieren einer Nachricht, ist möglich.
  2. Reihenfolgegarantien: In klassischen Brokern gelten diese oft global pro Queue. Wenn also Nachrichten für ein Topic bzw. Queue an mehr als einem Broker publiziert und konsumiert werden, ist dies ein enormer organisatorischer Aufwand für die Broker. Dies trifft im speziellen für durable, also persistierte Nachrichten zu. Kafka löst dies durch die Partitionierung von Topics, was allerdings im Umkehrschluss bedeutet, dass es eine Reihenfolgegarantie nur innerhalb einer Partition gibt. Das ist gerade beim Entwurf einer Anwendung ein wesentliches Detail.

Vielleicht kann man es so erklären: Kafka ist für den Austausch von großen Datenmengen konzipiert und optimiert, es benutzt “rein zufällig” das Konzept von Messages dafür. Im Vergleich zu ActiveMQ oder RabbitMQ fehlt es Kafka beispielsweise an einer zentralen Admin-Oberfläche. Auch wird als Authentifizierungsmechanismus derzeit nur Kerberos unterstützt.

JAXenter: Von Big Data zu Fast Data: In welchen Szenarien ist der Einsatz von Kafka sinnvoll? Könnt ihr ein Beispiel nennen?

Lars Pfannenschmidt, Frank Wisniewski: Kafka ist in aller Munde: Eine Firma wurde um das Apache Projekt gegründet, es entwickelt sich zum Industriestandard für Daten-Pipelines. Dennoch, folgende Fragen sollte man sich stellen:

  • Will man die ausgetauschten Daten ggf. mehrfach konsumieren?
  • Sollen verschiedene Clients identische Daten lesen?
  • Sollen Topics/Queues persistiert werden?
  • Ist die anfallende Datenmenge überhaupt so umfangreich, dass ein klassisches System wie RabbitMQ nicht mehr ausreichend ist?
  • Will man dem Client mehr Verantwortung beim Konsumieren von Daten übertragen?

Kafka ist bei LinkedIn aus dem “Activity Tracking”-Anwendungsfall entstanden und ist somit sicherlich ideal für ähnliche Problemstellungen. Darüber hinaus ist es für große Messaging-Applikationen sowie zum Transport von Metriken oder System-Logs geeignet. Durch die breite Unterstützung in Spark, Storm, Samza, oder der für Kafka 0.10 angekündigten Kafka-Streams-Bibliothek ist es auch bestens für Streamverarbeitung und -persistierung (bspw. nach Hadoop) geeignet.

JAXenter: Wo seht ihr noch Verbesserungsbedarf?

Lars Pfannenschmidt, Frank Wisniewski: Eine der größten Schwächen vor Version 0.9 war die Java Consumer API. Die in 0.9 vorgestellte API ist deutlich klarer, aber offiziell noch im Beta-Status. Da Kafka ein Binärprotokoll benutzt, sind Clients in jeder erdenklichen Sprache verfügbar, aber gerade bei den Implementierungen der Consumer variieren die bereitgestellten Features stark.

Wie bereits angesprochen, wären zusätzlich zu Kerberos noch andere Authentifizierungsmechanismen wünschenswert. Im Betrieb eines Kafka-Clusters ist insbesondere das Monitoring der Broker aber auch seiner Consumer essentiell. Hier können zwar Open-Source-Projekte wie Prometheus Abhilfe schaffen, allerdings besteht unserer Meinung nach sowohl beim Treiber als auch beim Broker noch Nachholbedarf.

JAXenter: Welche Botschaft möchtet ihr den Besuchern eurer Session für ihre Big-Data-Projekte mitgeben?

Lars Pfannenschmidt, Frank Wisniewski: Erst denken, dann rechnen, dann entscheiden. Viele Data-Probleme sind gar nicht so big. Falls doch, ist es zwingend notwendig, sich einen ausreichenden Überblick zu verschaffen und Lösungsansätze zu probieren, am besten in einer realistischen Größenordnung. Auch sollte man sich bei Technologieentscheidungen bewusst sein, dass diese ggf. den Anforderungen irgendwann nicht mehr gerecht werden und neu getroffen werden müssen.

Außerdem gilt es zu beachten, dass der Mehrwert für einen Benutzer bei “Echtzeit”-Verarbeitung von Daten deutlich höher als bei nächtlicher Verarbeitung ist, daher sollte eine “Batch”-Lösung nur ein letzter Ausweg sein!

 

PfannenschmidtLars Pfannenschmidt setzt sich vorrangig mit Themen rund um Internet of Things, mobilen Applikationen, Machine Learning, Big Data und agilen Vorgehensmodellen wie Scrum und Kanban auseinander. Lars arbeitet als Principal Software Engineer bei Intuit Data Engineering Analytics an Echtzeitlösungen und ist Mitgründer der mobile.cologne User Group Köln.Wisniewski
Frank Wisniewski (@ultraknackig) arbeitet als Senior Software Engineer im Bereich Echzeitlösungen bei Intuit Data Engineering & Analytics. Sein Erfahrungshorizont umfasst außerdem 3-D-Visualisierung und -Rendering (C++/OpenGL, 3-D-PDFs), moderne Webentwicklung und Big Data in Echtzeit sowie agilen Vorgehensmodellen wie Scrum oder Kanban.
Geschrieben von
Kypriani Sinaris
Kypriani Sinaris
Kypriani Sinaris studierte Kognitive Linguistik an der Goethe Universität Frankfurt am Main. Seit 2015 ist sie Redakteurin bei JAXenter und dem Java Magazin.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.