web-dev-qa-db-ja.com

ストームトポロジ構成

ストームトポロジにカスタム構成をどのように提供しますか？たとえば、MySQLクラスターに接続するために構築したトポロジがあり、再コンパイルせずに接続する必要のあるサーバーを変更できるようにしたい場合、どうすればよいですか？私の好みは構成ファイルを使用することですが、私の懸念は、ファイル自体がクラスターにデプロイされていないため、実行されないことです（クラスターの動作の理解に欠陥がない限り）。実行時に構成オプションをストームトポロジに渡すためにこれまで見てきた唯一の方法は、コマンドラインパラメーターを使用することですが、パラメーターの数が多いと面倒です。

シェルスクリプトを利用してファイルを変数に読み込み、その変数の内容を文字列としてトポロジに渡すことも考えられましたが、可能であれば、もう少しクリーンなものが必要です。

他の誰かがこれに遭遇しましたか？もしそうなら、どのようにそれを解決しましたか？

編集：

より明確にする必要があるようです。私のシナリオは、トポロジを再コンパイルせずにさまざまな環境にデプロイできるようにしたいというものです。通常、データベース接続パラメーターなどを含む構成ファイルを作成し、それを渡します。Stormでそのようなことを行う方法を知りたいです。

apache-storm
17
blockcipher

トポロジとともに送信する構成を（通常はyamlファイルを介して）指定できます。独自のプロジェクトでこれを自分で管理する方法は、開発用と本番用に別々の構成ファイルを用意し、その中にサーバー、redis、db IP、ポートなどを保存することです。次に、コマンドを実行してjarをビルドし、送信します。ストームするトポロジには、デプロイメント環境に応じた正しい構成ファイルが含まれています。ボルトと注ぎ口は、ボルトのprepare（）メソッドで渡されるstormConfマップから必要な構成を読み取るだけです。

から http://storm.Apache.org/documentation/Configuration.html ：

すべての構成には、Stormコードベースのdefaults.yamlで定義されたデフォルト値があります。 Nimbusとスーパーバイザーのクラスパスでstorm.yamlを定義することで、これらの構成をオーバーライドできます。最後に、StormSubmitterを使用するときに、トポロジーとともに送信するトポロジー固有の構成を定義できます。ただし、トポロジ固有の構成では、プレフィックスが「TOPOLOGY」の構成のみをオーバーライドできます。

Storm 0.7.0以降では、ボルトごと/注ぎ口ごとに構成をオーバーライドできます。

http://nathanmarz.github.io/storm/doc/backtype/storm/StormSubmitter.html でも、submitJarとsubmitTopologyにconfというマップが渡されることがわかります。

これで始められることを願っています。

8
veroxii

コードで構成を提供するだけで、この問題を解決しました。

config.put(Config.TOPOLOGY_WORKER_CHILDOPTS, SOME_OPTS);

トポロジ固有のstorm.yamlを提供しようとしましたが、機能しません。 storm.yamlを使用できるようになったら、修正してください。

更新：
SOME_OPTSが何であるかを知りたい人のために、これはStormメーリングリストのSatishDugganaからのものです。

Config.TOPOLOGY_WORKER_CHILDOPTS：トポロジのWORKER_CHILDOPTSをオーバーライドできるオプション。メモリ、gcなどの任意のJavaオプションを構成できます

あなたの場合それはすることができます

config.put(Config.TOPOLOGY_WORKER_CHILDOPTS, "-Xmx1g");
2
Adrian Liu

実際に最も役立つのは、構成を可変キー値ストア（s3、redisなど）に保存し、それをプルしてデータベース接続を構成し、それを使用することです（ここでは、方法を制限することをすでに計画していると思います）多くの場合、この構成を取得するオーバーヘッドが大した問題にならないように、データベースと通信します）。この設計により、トポロジを再デプロイする必要なしに、データベース接続をオンザフライで変更できます。

1
G Gordon Worley III

同じ問題を確認し、トポロジごとに以下を追加することで解決しました

config.put(Config.TOPOLOGY_WORKER_CHILDOPTS, "-Xmx4096m -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:NewSize=128m -XX:CMSInitiatingOccupancyFraction=70 -XX:-CMSConcurrentMTEnabled -Djava.net.preferIPv4Stack=true");

また、Nimbus UIを使用して確認すると、次のように表示されます。

topology.worker.childopts   -Xmx4096m -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:NewSize=128m -XX:CMSInitiatingOccupancyFraction=70 -XX:-CMSConcurrentMTEnabled -Djava.net.preferIPv4Stack=true
0
Lokendra Chauhan

私はあなたがしたのと同じ問題に直面しています、そしてここに私のトリッキーな解決策があります：

構成ファイルとして単純なJavaファイル、たとえばtopo_config.Javaを使用すると、次のようになります。

package com.xxx
public class topo_config {
    public static String zk_Host = "192.168.10.60:2181";
    public static String kafka_topic = "my_log_topic";
    public static int worker_num = 2;
    public static int log_spout_num = 4;
    // ...
}

このファイルはconfigureフォルダーに置かれ、compile.shと言うスクリプトを記述します。これにより、適切なパッケージにコピーされ、コンパイルが実行されます。次のようになります。

cp config/topo_config.Java src/main/Java/com/xxx/
mvn package

構成は直接行われます。

Config conf = new Config();
conf.setNumWorkers(topo_config.worker_num);
0
flowyi

私も同じ問題に直面しました。クラスターでNFSを構成することで解決し、その構成ファイルを共有の場所に置いて、すべてのクラスターマシンで使用できるようにしました。LinuxシステムでNFSを構成するのは非常に簡単です リンク 。

0
user2435082

トポロジを構築するときに、（とりわけ）注ぎ口とボルトのインスタンスを作成し、これらのインスタンスをシリアル化して、クラスター内の適切な場所に配布するという考え方です。注ぎ口またはボルトの動作を構成する場合は、トポロジを作成するときに送信する前に構成し、ボルトまたは注ぎ口にインスタンス変数を設定して、必要な構成可能な動作を駆動します。

0
Chris Gerken