9

ストームの導入を検討していますが、少し心配です。現在、Hadoop MapReduce を実行しており、処理の一部を MapReduce から Storm プロセスに移行したいと考えています。これは一部であり、すべてではないことに注意してください。MapReduce 機能はまだいくつかあります。

同じハードウェア上で Storm と Hadoop の展開を (潜在的に) 維持できる Mesos を見つけましたが、他にもいくつかの問題がありました。

  • Storm と Hadoop の間で任意にスロットを「借りる」ことができるのが理想的な状況だと思います。元。どちらも必要に応じて同じリソースを使用します。残念ながら、これは固定展開であり、EC2 などのような「クラウド ベース」ではありません。

  • Storm 環境でのボトルネックを回避したいと考えています。理想的なケースは、必要に応じてより多くのボルトのインスタンスを "スピンアップ" (またはその逆) することです。これは可能/現実的ですか?

  • トポロジの「再起動」は、かなり費用のかかる操作のように思えますが、それが実際にオプションであるかどうかはわかりません。理想的には、可能な限りシームレスにしたいと思います。

この問題に正しく取り組んでいますか? 基本的に、Storm トポロジは MapReduce バッチ ジョブを「フィード」します。一部の処理はストリーミング方式で処理でき、Storm トポロジとしてははるかに優れていますが、一部はバッチ処理が必要です。

私の特定の質問に対応していなくても、一般的なフィードバックは大歓迎です。現時点では、これは探索的な段階であり、完全に間違った方法でアプローチしている可能性があります。

4

1 に答える 1

5

いくつかの考えと、同様の実験を行ったこれまでの私の経験（スプリント中にスパイクで実行された）：

  • 私の経験から（私は間違っている可能性があります）、需要が増えるにつれて実際にはボルトを増やすのではなく、トポロジ内の各ボルトの並列構成を調整します。トポロジは、ボルトを追加することによってスケーリングされるのではなく、ボトルネックとなるボルトの並列処理を増やすことによってスケーリングされます。単語数の問題の例を見てみましょう。
builder.setBolt(4, new MyBolt(), 12)
    .shuffleGrouping(1)
    .shuffleGrouping(2)
    .fieldsGrouping(3, new Fields("id1", "id2"));

その最後のパラメータ（「12」）は、そのボルトの平行度です。トポロジのボトルネックであり、需要を満たすためにスケールアップする必要がある場合は、これを増やします。12の並列処理は、ストームクラスター全体で12のスレッドがボルトを並列に実行する結果になることを意味します。

  • 0.8.0では、「エグゼキュータ」を使用できます。これにより、「オンザフライ」で調整して、ボルトなどをスケールアップ/スケールダウンすることもできます。例：

builder.setBolt（new MyBolt（）、3）.setNumTasks（64）.shuffleGrouping（ "someSpout"）;

ここで、のエグゼキュータ（スレッド）の数MyBolt()は3であり、トポロジに影響を与えることなく、スレッドの数を動的に変更できます。 storm rebalanceこれに使用されます：

$ storm rebalance someTopology -n 6 -e mySpout=4 -e myBolt=6

これにより、「someTopology」トポロジのワーカーの数が6に、mySpoutのエグゼキューター/スレッドの数が4に、myBoltのエグゼキューター/スレッドの数が6に変更されます。

  • ストームトポロジがストリーミングデータを処理するようです。バッチ処理が必要なデータは、使用しているデータストア（HDFS）に永続化された後、開始されます。その場合、必要なデータが何であれ、データストアに永続化するためにボルトをラップします。
  • 一方、既存のデータストアに加えて何らかの増分処理を実行する（そしてステートフルのままにする）場合は、Trident（https://github.com/nathanmarz/storm/wiki/Trident-tutorial ）を使用します。 ）。トライデントは実際にあなたが持っている多くの質問を解決するかもしれません。
于 2013-01-10T19:37:48.260 に答える