Datenströme nach Hadoop richtig kanalisieren

Fallstricke

Neben den vielen Vorteilen von Apache Storm gibt es jedoch auch einige Nachteile, welche sich oftmals erst in der direkten Nutzung ergeben und vorher leider ohne Erfahrung nicht erkennbar sind. Während die Skalierbarkeit des Systems kein Problem darstellt, ist das Debuggen eine der mühseligsten und abenteuerlichsten Herausforderungen. Nicht nur, dass verteilte Systeme per se eine hohe Komplexität in der Suche nach Fehlern mitbringen, auch die Möglichkeiten der Fehlersuche sind sehr stark eingeschränkt. Beim Auftreten von Fehlern muss man schnell in der Lage sein, die Ursache zu identifizieren.

Hinsichtlich Apache Storm kann dies mit einer Veränderung der Menge der in das System fließenden Daten zusammenhängen oder mit fehlerhaftem Code beziehungsweise fehlerhafter Hardware. Da sich in Storm viele Komponenten einer Topologie einen Prozess teilen, ist es oftmals schwierig die Ursache zu ergründen. Weiterhin benötigt Storm dedizierte Hardware mit viel Arbeitsspeicher, welche zwangsläufig zu einer ineffizienten Nutzung des Clusters führt und auch bei der Skalierung problematisch werden kann.

Dementsprechend gestaltet sich auch die Bereitstellung und Wartung von Maschinen als eine schwierige Angelegenheit. Effizienz in der Auslastung von Ressourcen ist immer direkt mit den Kosten von Infrastruktur gekoppelt und damit ein erstrebenswertes Ziel, welches unter Storm indes schwer zu erreichen ist. All die zuvor angeführten Fallstricke machen es für Anwenderunternehmen nicht gerade einfach, im produktiven Einsatz eine Storm-Topologie zu nutzen.

Evolution von Storm

Der größte Nutzer von Storm ist Twitter. Das Unternehmen hatte im Juli 2011 Nathan Marz samt seiner Firma Backtype akquiriert. Bei Twitter leitete Marz ein Entwickler-Team, das wichtige Kern-Infrastruktur entwickelte und betreute - unter anderem Storm. Im März 2013 verließ Marz Twitter und gründete ein eigenes Unternehmen, das sich momentan allerdings noch im Stealth-Modus befindet.

Da Twitter zunehmend an Grenzen stieß und die Fehlersuche ein sehr hartes Stück Arbeit ist, wurde ein neuer Ansatz gewählt, um die Stärken von Storm weiterhin nutzen zu können und die Schwächen zu eliminieren. Das dabei entstandene Produkt trägt den Namen "Heron" und wird vermutlich dieses Jahr noch als Open-Source Projekt veröffentlicht werden. Die neue Lösung versucht, ein sauberes Mapping von logischen Einheiten auf physikalische Ressourcen oder Prozesse zu ermöglichen und eine Nutzung und Teilung von Clusterressourcen mit anderen Technologien zu gewährleisten. Einzelne logische Komponenten werden nun als einzelne Tasks ausgeführt, wodurch eine effizientere Fehleranalyse ermöglicht wird.

Ferner ermöglicht das neue Design eine genauere Lokalisierung der Fehlerstelle innerhalb der Topologie. Dies wird durch eine bessere Bereitstellung von Metriken aus der laufenden Topologie ermöglicht. Während in Storm nur eine sehr grobe Spezifikation der zu verwendenden Ressourcen möglich ist, bietet Heron eine sehr feingranulare Zuteilung von Ressourcen, welche es einfacher macht, eine übermäßige Ressourcenzuteilung zu verhindern. Durch die Bereitstellung von je einem Topologie-Master je ausgeführter Anwendung, ist die Gefahr, eine andere Topologie bei einem Fehlverhalten zu beeinflussen, beseitigt.

In Storm hatten Anwender nur zwei Alternativen: man konnte "die Daten fließen lassen" oder "die Daten nicht fließen lassen" - also eine binäre Möglichkeit zur Datenflusssteuerung. Innerhalb von Heron ist nun eine dynamische Anpassung der Datenrate möglich. Diese Eigenschaft hilft auch bei der Migration auf neue Maschinen oder beim Upgrade der bestehenden.