Von Big Data zu Fast Data mit Apache Kafka

Bisher waren die operativen und die analytischen Daten immer voneinander getrennt. Durch neue Anwendungsfälle wie IoT oder Echtzeitauswertungen im Bereich Marketing oder Industrie 4.0, steigt nicht nur die Datenmenge, sondern auch die erforderliche 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 (Data Lake) dafür verwendet.

Damit sich dieser 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 FastData um das dritte V (Velocity). Auch hier gibt es mit Apache Spark und Flink entsprechende Produkte, um eine Streaming-Architektur umzusetzen.

Nachrichten oder Ströme?

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 Rückstau 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 Realzeitverarbeitung eher ungeeignet. Hinzu kommt, dass sie auch neuere, effizientere Protokolle oft nicht unterstützen.

Warum Apache Kafka?

Vor ähnlichen Herausforderungen stand das soziale Businessnetzwerk LinkedIn. Diese entwickelten Apache Kafka als verteilte Daten-Streaming-Plattform, die sie 2012 an die Apache Software Foundation übergaben. 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, Mongo DB oder Standards wie MQTT, JMS, JDBC und CoAP, gibt es OpenSource oder offiziell unterstützte Konnektoren.

Daten werden bei Kafka automatisch partitioniert und verteilt abgelegt. Dadurch kann die Verarbeitung parallelisiert werden 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 Lernmodell 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 Nachrichten- 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 Auswertemö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's who des Internets und auch die Partnerliste von Confluent wird immer länger.

Die Möglichkeit bei neuen eventbasierten Architekturen einen Ort der Wahrheit (Single source of truth) 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.