Elastische Sturmtopologie / Storm-Hadoop koexistierend

9

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.

    
jon 03.01.2013, 04:01
quelle

1 Antwort

5

Einige Gedanken und meine bisherigen Erfahrungen in einem ähnlichen Experiment (in einem Spike während eines Sprints):

  • Nach meinen Erfahrungen (ich könnte falsch liegen), schleudern Sie nicht wirklich mehr Schrauben mit steigender Nachfrage, sondern Sie passen die Parallelitätskonfigurationen jedes einzelnen in der Topologie an. Topologien werden nicht skaliert, indem mehr Schrauben hinzugefügt werden, sondern sie werden skaliert, indem die Parallelität erhöht für jede Schraube, die den Engpass darstellt. Nehmen wir das Problem mit dem Wortanzahl-Beispiel:
%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.

  • In 0.8.0 können Sie "Executors" verwenden, die auch "on the fly" Anpassungen erlauben, um eine Schraube / etc hoch / runter zu skalieren. Beispiel:
  

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:

%Vor%

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.

  • Es hört sich an, als würde Ihre Sturm-Topologie die Streaming-Daten verarbeiten. Daten, die eine Stapelverarbeitung erfordern, werden gestartet, nachdem sie in dem von Ihnen verwendeten Datenspeicher (HDFS) beibehalten wurden. In diesem Fall würden Sie eine Schraube einfügen, um Persistenzen für den Datenspeicher durchzuführen, für welche Daten auch immer Daten benötigt werden.
  • Wenn Sie auf der anderen Seite eine inkrementelle Verarbeitung über den Datenspeicher hinaus durchführen möchten, den Sie bereits haben (und weiterhin statusbehaftet bleiben), verwenden Sie Trident ( Ссылка ). Trident könnte tatsächlich eine Menge der Fragen lösen, die Sie haben.
Jack 10.01.2013, 19:37
quelle