Daten sammeln, auswerten und verteilen

Von Big Data zu Fast Data mit Apache Kafka

03.08.2018
Von 


Frank Pientka arbeitet als Principal Software Architect bei der MATERNA GmbH. Als Software Architect sorgt er für mehr Qualität in der Software und kümmert sich, als Gründungsmitglied des iSAQB, um eine verbesserte Ausbildung und Zertifizierung von Architekten. Seit mehr als zwei Jahrzehnten unterstützt er Firmen bei der Umsetzung  und Modernisierung ihrer Software-Architekturen. Dabei führt er externe Reviews und Architekturbewertungen als Gutachter durch. Dazu hat er auch schon mehrere Bücher, Fachartikel veröffentlicht und Vorträge gehalten.
Bei Microservices und Fast Data führt kein Weg an lose gekoppelten Systemen und der ereignisbasierten Verarbeitung vorbei. Apache Kafka verspricht die beiden bisher getrennten Welten asynchrone Nachrichten- und Datenverarbeitung näher miteinander zu verbinden.

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.

Apache Kafka lässt die gesamte Datenverarbeitung von Grund auf neu denken.
Apache Kafka lässt die gesamte Datenverarbeitung von Grund auf neu denken.
Foto: Apache Foundation

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.

Von Big Data zu Fast Data mit der Lambda-Architektur
Von Big Data zu Fast Data mit der Lambda-Architektur
Foto: MATERNA GmbH

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.

Kafka benötigt zur Ausführung nur eine Java-Laufzeitumgebung und den bereits integrierten Cluster-Manager Apache Zoogener.
Kafka benötigt zur Ausführung nur eine Java-Laufzeitumgebung und den bereits integrierten Cluster-Manager Apache Zoogener.
Foto: Apache Foundation

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.

Der Konsument kontrolliert die Datenverarbeitung
Der Konsument kontrolliert die Datenverarbeitung
Foto: Apache Kafka ASF 2.0 licence