#Java #Kafka #DataStreaming
Der Trend zu immer mehr und immer schneller stellt hohe Anforderungen an dynamisch reagierende Systeme. Bei Microservices und Fast-Data führt kein Weg an losgekoppelten Systemen und der ereignisbasierten Verarbeitung vorbei. Apache-Kafka verspricht, die beiden bisher getrennten Welten, asynchrone Nachrichtenverarbeitung und Datenverarbeitung, näher miteinander zu verbinden.
Immer schneller, immer kleiner
Bisher waren die operativen und die analytischen Daten immer getrennt voneinander. Durch neue Anwendungsfälle, wie IoT oder Realzeitauswertungen im Bereich Marketing oder Industrie 4.0,
steigt nicht nur die Datenmenge, sondern auch die Geschwindigkeit. Da die Daten aus unterschiedlichen Quellen kommen, müssen diese einheitlich verarbeitet und integriert werden. Letztendlich, ist nicht nur aus Zeit-, sondern auch aus Kostengründen fraglich, ob diese Daten bei der Weiterarbeitung wirklich mehrfach abgespeichert werden müssen. Dabei wird im Bereich Business-Intelligence die Metapher des Datensees dafür verwendet. Damit dieser sich nicht zu einem Datensumpf entwickelt, sind dann wieder Datenvereinigungs- und Governance-Prozesse nötig, die das Ganze nicht nur verlangsamen, sondern auch verteuern. Um die Datenverarbeitung wieder etwas zu beschleunigen, wurde von Nathan Marz die Lambda-Architektur vorgeschlagen.
Diese bietet neben der langsamen Batch-Verarbeitung eine schnellere Verarbeitung für eine Untermenge an. Als eine Alternative, die auf zwei getrennte Verarbeitungswege verzichtet, schlug Jay Kreps eine Streaming-Architektur vor, die er einfach, mit dem Folgebuchstaben von Lambda im griechischen Alphabet, Kappa nannte.
Haben sich die ersten Big-Data-Systeme rund um Hadoop zunächst auf die effizientere Batch-Verarbeitung konzentriert und sich auf die zwei V‘s von Big-Data (Volume, Variety) gekümmert, geht es bei Fast-Data um das dritte V: Velocity. Auch hier gibt es mit Apache-Spark und -Flink entsprechende Produkte, um eine Streaming-Architektur umzusetzen.
Nachrichten oder Daten
Manchmal hat man jedoch keine Datenströme, sondern eher kleinere Eimer, die als Nachrichten zwar auch kontinuierlich aber oft unvorhersehbar auftreten. Das kann schnell zu einem Stau bei der Weiterverarbeitung führen. Um diesen zu vermeiden, braucht man entweder genügend Zwischenspeicher oder einen Mechanismus (Backpressure), um mit solchen Überlastungen umzugehen. Da die meisten Messaging-Systeme schon etliche Jahrzehnte auf dem Buckel haben und ursprünglich auch eher für Unternehmensanwendungen mit planbarer Last gedacht waren,
sind diese für eine Realtime-Verarbeitung eher ungeeignet.
Hinzu kommt, dass sie auch neuere, effizientere Protokolle oft nicht unterstützen.
Warum Apache-Kafka
Vor ähnlichen Herausforderungen stand das soziale Business-Netzwerk LinkedIn. Diese entwickelten Apache-Kafka als verteilte Daten-Streaming-Plattform, die sie 2012 an die Apache Software Foundation übergaben. Seit 2014 haben die ursprünglichen Entwickler mit Confluent ein Unternehmen gegründet, das sich um die Weiterentwicklung und den professionellen Support kümmert. Die beiden Hauptkomponenten von Kafka sind die Streams und die Konnektoren. Dienen die Streams zu Verarbeitung, sind die Konnektoren dafür zuständig, die Verbindung mit externen Datenlieferanten und -abnehmern herzustellen. Für viele bekannte Produkte, wie ElasticSearch, HDFS, Amazon-S3, Amazon-Dynamo-DB, Amazon-Kinesis, Cassandra, Couchbase, Splunk, IBM-MQ, Oracle-CDC, MongoDB oder Standards wie MQTT, JMS, JDBC und CoAP, gibt es Open-Source oder offiziell unterstützte Konnektoren.
Kafka selbst ist in Java und Scala programmiert und benötigt zur Ausführung nur eine Java-Laufzeitumgebung und den bereits integrierten Cluster-Manager Apache-Zoogener.
Daten werden bei Kafka automatisch partitioniert und verteilt abgelegt. Dadurch kann die Verarbeitung parallelisiert und die Ausfallsicherheit erhöht werden. Nachrichten werden zu Topics an den Broker gesendet und sofort weiterverarbeitet. Wenn diese nicht sofort weiterverarbeitet werden können, werden diese in einen Zwischenpuffer geschrieben und zu einem späteren Zeitpunkt transparent weiterverarbeitet. Deswegen braucht Kafka keinen Backpressure-Mechanismus, wie er bei anderen reaktiven Stream-Verarbeitungen benötigt wird. Die Konsumenten kontrollieren
dezentral, welchen letzten Datensatz sie verarbeitet haben und können so immer dort (gemerkter Offset) wieder weitermachen, wenn die Verarbeitung kurzzeitig unterbrochen wurde oder sich an einen bei Überlast noch freien Thread zuteilen lassen. Dadurch, dass die Steuerung dezentral erfolgt, ist ein Kafka-Cluster sehr robust, ausfallsicher und skalierbar.
Anwendungsfälle
Die Verarbeitung von zeitbezogenen Ereignissen sind ein naheliegender Anwendungsfall für Kafka. Hierzu zählen auch Protokolldateien oder Sensordaten aus dem Bereich IoT.
Auch für neuronale Netze bietet sich Kafka an, um z. B. neue Lernmodelle mit produktiven Daten in Realzeit zu trainieren. Das hat den Vorteil, dass die Daten nicht doppelt gespeichert werden, sondern dass die Ergebnisse zwischen zwei parallel arbeitenden Modellen schneller verglichen und angepasst werden können, was letztendlich die Ergebnisqualität und das Lernen verbessert.
Gerade für eine große Anzahl von Geräten mit einer stark schwankenden Last ist Kafka gut geeignet, da die Information über den Verarbeitungszustand nicht zentral, sondern bei den Clients gehalten wird. Dadurch ist ein Wiederaufsetzen im Fehlerfall oder ein Nachfahre von verpassten Informationen einfacher möglich.
Fazit:
Bisher wurden die Themen asynchrone Nachrichtenverarbeitung und Datenverarbeitung immer getrennt betrachtet. Durch die Notwendigkeit, immer mehr Daten in immer schnellerer Zeit verarbeiten zu müssen, werden neue Anforderungen an die Near-Realtime-Verarbeitung von Daten und Nachrichten gestellt. Mit Apache-Kafka können beide Welten miteinander verbunden werden. Dabei ist die Einstiegshürde geringer als bei vergleichbaren Produkten, da diese einfach in die Entwicklung integriert und zu einem skalierbaren Betrieb ausgebaut werden kann. Über Konnektoren können viele typische Systeme schnell eingebunden werden. Mit KTable und KSQL existieren in Confluent einfache Auswertungsmöglichkeiten, sodass viele Berechnungen direkt auf dem Datenstrom stattfinden können, ohne den Umweg über Zwischenspeicher zu gehen. Dadurch, dass inzwischen Konnektoren bekannter Hersteller, wie IBM, ORACLE, SAP und Microsoft für Kafka existieren, wird es noch einfacher Kafka nicht nur in der Cloud, sondern auch in Unternehmen zu nutzen. Die Liste der Firmen die Kafka nutzen, liest sich deswegen wie das Who-is-who des Internets und auch die Partnerliste von Confluent wird immer länger. Die Möglichkeit bei neuen event basierten Architekturen einen Ort der Wahrheit (Single-source-of-truths) zu haben, macht die Datenaktualität bei gleichzeitiger Historisierung einfacher. Insofern ist Kafka, nicht nur für IoT, die Log-Verarbeitung oder KI, eine interessante Option, sondern lässt die gesamte Datenverarbeitung von Grund auf neu denken. Realtime von Daten wird generell immer wichtiger, da der Wert der Daten oft mit dem Zeitraum sinkt, bis daraus Informationen und damit Entscheidungen gewonnen werden können.
Frank Pientka arbeitet als Principal-Software-Architect bei der MATERNA GmbH in Dortmund und sorgt für mehr Qualität in der Software. Als Gründungsmitglied des iSAQB sorgt er für eine verbesserte Ausbildung und Zertifizierung von Architekten.
Seit mehr als zwei Jahrzehnten unterstützt er Firmen bei der Umsetzung tragfähiger Software-Architekturen und begleitet sie auf ihrem Weg in die Cloud.
http://blog.materna.de/author/frank-pientka/
Frank.Pientka@materna.de
https://mobile.twitter.com/fpientka
