Wir evaluieren Storm für einen Einsatz, aber ich bin etwas besorgt. Wir führen derzeit Hadoop MapReduce aus und möchten einige unserer Prozesse von MapReduce auf Storm-Prozesse umstellen. Beachten Sie, dass dies einige, aber nicht alle sind. Wir hätten immer noch eine MapReduce-Funktionalität.
Ich hatte Mesos gefunden, die (möglicherweise) uns erlauben, eine Storm- und Hadoop-Bereitstellung auf derselben Hardware aufrechtzuerhalten, aber einige andere Probleme hatten:
Ich stelle mir die ideale Situation vor, weil ich beliebig Slots zwischen Storm und Hadoop "ausleihen" kann. Ex. Beide würden die gleichen Ressourcen wie benötigt verwenden. Leider ist dies eine feste Bereitstellung, und ist nicht "cloud-basiert" wie EC2 oder die ähnliche.
Ich möchte Engpässe in unserer Storm-Umgebung vermeiden. Ein idealer Fall wäre es, mehr Instanzen von Schrauben "hochzufahren" (oder umgekehrt), wenn die Nachfrage es erfordert. Ist das möglich / realistisch?
"Neustart" einer Topologie scheint eine ziemlich teure Operation zu sein, und ich bin mir nicht sicher, ob es wirklich eine Option ist. Idealerweise möchte ich, dass es so nahtlos wie möglich ist.
Nähern wir uns diesem Problem richtig? Im Wesentlichen würde eine Storm-Topologie einen MapReduce-Stapeljob "füttern". Einige unserer Verarbeitungen können stream verarbeitet werden und wären viel besser als eine Storm-Topologie, während einige davon eine Stapelverarbeitung erfordern.
Ein allgemeines Feedback, auch wenn es meine spezifischen Fragen nicht anspricht, wäre willkommen. Dies ist eher eine Erkundungsphase an diesem Punkt, und ich könnte mich dem völlig falsch nähern.
Einige Gedanken und meine bisherigen Erfahrungen in einem ähnlichen Experiment (in einem Spike während eines Sprints):
%Vor%
Dieser letzte Parameter (die "12") ist die Parallelität dieses Bolzens. Wenn es sich um einen Engpass in der Topologie handelt und Sie den Bedarf erhöhen müssen, erhöhen Sie dies. Eine Parallelität von 12 bedeutet, dass 12 Gewinde den Bolzen parallel über den Sturmhaufen ausführen.
builder.setBolt (neues MyBolt (), 3) .setNumTasks (64) .shuffleGrouping ("someSpout");
Hier ist die Anzahl der Executoren (Threads) für MyBolt()
gleich 3 und Sie können die Anzahl der Threads dynamisch ändern, ohne die Topologie zu beeinflussen. storm rebalance
wird dafür verwendet:
Dies ändert die Anzahl der Worker für die Topologie "someTopology" auf 6, die Anzahl der Executoren / Threads für mySpout auf 4 und die Anzahl der Executoren / Threads für myBolt auf 6.
Tags und Links java hadoop mapreduce distributed-computing apache-storm