Apache Storm 2.0 wechselt von Clojure zu Java

Inhaltsverzeichnis

Die Entwickler von Apache Storm haben gut drei Jahre nach der ersten Hauptversion nun Storm 2.0 veröffentlicht. Dabei haben sie den zuvor in Clojure programmierten Kern des Frameworks zum Verarbeiten von Streaming Data vollständig in Java geschrieben. Außerdem gibt es eine neue Stream-API und Verbesserungen beim Verwalten der Fenster in der Windowing-API. Darüber hinaus findet man Änderungen in der Anbindung an Apache Kafka.

Java statt Clojure

Für das Verwerfen des bisherigen Clojure-Kerns zugunsten einer Neuentwicklung in Java gab es zwei wesentliche Beweggründe. Zum einen hat das Neuschreiben der Kernfunktionialität auf der technischen Seite wohl die Wartbarkeit, Erweiterbarkeit und Performance deutlich erhöht. Außerdem galt Clojure als Hürde für potenzielle Contributors, sich in Apache Storm einzubringen. Auch wenn der auf der JVM aufsetzende, funktionale Lisp-Dialekt Clojure bei seinen Verfechtern äußerst beliebt ist, finden sich weit mehr Java-Entwickler.

Der neue Kern setzt auf ein schlankeres Threading-Modell und ein verbessertes Messaging-Subsystem. Beim Entwickeln lag der Fokus auf hohem Durchsatz, niedriger Latenz und geringerem Stromverbrauch. Gleichzeitig sollten die Verbesserungen nicht zu Lasten der Rückwärtskompatibilität gehen. Laut den Angaben der Entwickler ist Apache Storm 2.0 die erste Streaming-Engine, die unter einer Mikrosekunde Latenz aufweist.

APIs für Streams und Windowing

Apache Storm hat eine neue, typisierte Streams-API an Bord. Sie setzt auf die Spouts-and-Bolts-APIs auf, die im Kern von Storm verankert sind. Spouts und Bolts gehören neben Streams zu den wesentlichen Komponenten des Konzepts der Datenverarbeitung in Storm. Spouts sind die Quelle der Datenströme, die Tupel aus externen Quellen einlesen und sie in die Topologie überführen. Dort findet die Verarbeitung und Transformation dann über die Bolts statt, die die Daten unter anderem filtern, aggregieren oder zusammenführen. Die neue Streams-API verbindet mehrere Operationen in den Aufrufen und soll so die Verarbeitung vereinfachen und die Pipeline optimieren.

Die Windowing-API bringt ebenfalls einige Verbesserung. Sie verwaltet die Fenster, die beim Verarbeiten von Data Streams dazu dienen, einen bestimmten Ausschnitt der kontinuierlich anfallenden Daten zu betrachten. Die API kann nun den Zustand von Fenstern speichern und wiederherstellen.

Wenn die Quellen einen monoton steigenden Identifier als Teil der Nachricht liefern, kann Storm sie beim Stateful Windowing nutzen, um Checkpoints für die zuletzt abgelaufene und die zuletzt berechnete Nachricht zu verwalten. Auf die Weise vermeidet das Frameworks bei Fehlern oder Neustarts eine doppelte Verarbeitung der Fenster. Bei der Wiederherstellung ignoriert Storm alle Tupel vor der abgelaufenen Nachricht und überträgt die Tupel danach bis zu dem zuletzt verarbeiteten in das System, ohne zuvor aktivierte Fenster erneut zu aktivieren.

Veränderte Anbindung an Kafka

Storm verändert die Zusammenarbeit mit Apache Kafka, das ebenfalls Datenströme verarbeitet, allerdings mit einem etwas anderen Fokus. Das Modul storm-kafka gilt bereits seit geraumer Zeit als überholt (deprecated) und entfällt in Storm 2.0. Stattdessen kommt das Modul storm-kafka-client zum Tragen, das die kafka-clients-Biblitohek von Kafka setzt. Die KafkaConsumer.subsribe-API im storm-kafka-client entfällt ebenfalls, stattdessen sollen Entwickler auf KafkaConsumer.assign setzen.

Weitere Details sowie die neue Aufteilung der Maven-Artefakte für Storm 2.0 lassen sich der offiziellen Ankündigung entnehmen. Mit dem Release der Version 2.0 hat Apache Storm 1.0.x End of Life (EOL) erreicht, wird also nicht weiter gepflegt. Nutzer sollten entweder auf das frische Release oder Storm 1.1.x beziehungsweise 1.2.x umsteigen. Mit Apache Storm 2.0 gilt Java 8 als Mindestvoraussetzung, während der Vorgänger sich mit Java 7 zufrieden gegeben hat. (rme)