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.