.net分散マップ/reduceフレームワークを探しています。これをリアルタイムのデータクエリに使用し、複数のノードでクエリを並列処理する予定です。現在、Web層とアプリ層の間の通信にWCFを使用しています。

たとえば、メモリデータに5つのノードがあるとします。5つのノードにフィルターを渡すと。フィルタはノードが持つデータのチャンクに対して実行され、結果は最終的な答えに還元されます。

ジョブをマップして結果を元に戻すことができるフレームワークがすでにあるかどうか疑問に思っています。私は嵐のニンバスのように見えました（Twitterのリアルタイムマップ/リデュース）。多くの合併症のためにニンバスを使用することはできません。また、Zookeeperのオーバーヘッドが多すぎます。

フレームワークを使用して次のことを達成しようとしています1）ジョブ（主に使用可能なすべてのノードに送信されるリクエスト）を使用可能なノードにマップし、結果を減らします。2）フェイルオーバー時に、ジョブを新しいノードにマップします。3）クラスターを管理します。（ノードがダウンしている場合は、使用可能なサーバーのリストからノードを削除します）

データはメモリ内にあるので、分散ファイルシステムは必要ありません。WCFを下に通信する.NETが理想的ですが、他のフレームワーク（任意の言語）がある場合はお知らせください。

任意のヘルプ（フレームワーク、コードプロジェクト、研究論文、実際のコード:)）をいただければ幸いです。

データ ストリームがあります。基本的には、毎分 30 ～ 50 のレコードが追加される SQL テーブルです。リアルタイムに近い速度で処理する必要があります（レコードがデータベースに表示されてから約 10 分で処理されるはずです）。ここでは、ワークフローのようなソリューションを使用して、すべてのレコードを簡単に処理できるようにしたいと考えています。高可用性を実現するには、このソリューションが必要です。システムは別のハードウェア ノードで動作し、ノードの 1 つがダウンした場合にフォールト トレラントである必要があります。基本的に何が起こるかは次のとおりです。

• 新しいレコードがデータベースに追加されます
• ワークフローはそれを処理し始めます
• その処理の結果としていくつかの処理を行います (電子メールの送信、データベースへの挿入など)。
• フレームワークは、レコードが処理されたことを記憶する必要があります

もう 1 つの要件は、レコードの 1 つの処理中にエラーが発生した場合、フレームワークが他のレコードの処理を停止してはならないということです。この特定のレコードには再処理が必要であることを覚えておく必要があります。

twitter-storm がこれと似たようなことをすると聞いたことがありますが、ここで使用するのはやり過ぎではありませんか? 私が理解しているように、その主な目的は、ここではまったく必要のない膨大な量のデータを同時に処理することです。

Nimbus と Supervisor は同じマシン上にあります。「bin/storm XX.jar XX.XX」を使用してストームで jar を実行していますが、stdout はこのトポロジが正常に実行されていることを示しています。

しかし、「ビン/ストーム リスト」を使用している間、トポロジの情報は表示されません。

私は Storm の世界に初めて参加し、使いやすく、優れたパフォーマンスを発揮する優れた Vertica Bolt を探しています。

Stormは、無料のオープンソースの分散型リアルタイム計算システムです。データのストリームを受信し、処理を行います。Stormがダウンし、データの一部がStormを通過しない場合、つまり計算が同期されない場合はどうなりますか？

Stormはこの問題をどのように解決できますか？それができない場合、どうすればこの問題を解決できますか？

同様の質問は次のようになります。Stormが追加される前に存在していた古いデータを読み取るにはどうすればよいですか？

複数のデータセンターの多数のマシンに多数のアプリケーションが分散されています。

1 日を通して、シグナル (内部または外部のいずれか) を受信し、各アプリケーション全体でイベントのカスケードを引き起こします。

したがって、各シグナルは膨大な量のイベント ログ データを生成します。ログライン自体は特に構造化されておらず、アプリケーション間でもかなり異なります。ただし、基本的な規則に従います。

ログラインには、イベントをシグナルにリンクするのに役立つ ID 番号がありますが、これらは絶対確実というわけではなく、イベントをつなぎ合わせるために他の方法を使用する必要がある場合もあります。

私は Twitter の Storm システムについて読んでいて、この大量のログ データをリアルタイムで分析し、それらをつなぎ合わせるために試してみることに非常に興味があります。

私は次のようなことをしたいと思います:

• リアルタイムのデータからの傾向に基づいて、レポートとストリーミング グラフを生成します。
• 信号をクエリし、チェーン内のステップ間の遅延を含め、すべてのアプリケーションでその信号に関連するイベントのチェーン全体を表示します。（これは重要）。
• 相関するイベントを表示し、特定のイベントの前後にアプリケーションが何をしていたかを掘り下げます。

データを取得しますか？

ログ データはローカルのログ ファイルに格納されます (これが変更される可能性はほとんどありません)。そのため、Storm 自体にデータを丸呑みする方法が必要になります。ログファイルは圧縮されている場合もあります。私は Flume や Logstash の使用について検討しましたが、これらについて人々はどのように考えていますか? または、Storm でうまく機能する別の方法はありますか?

イベントの保存？

また、イベント データ自体だけでなく、ライブ レポートとグラフのデータを保存する方法も必要です。

少しトリッキーだと思う 2 番目の部分です。ストレージ イベントに適したストレージ バックエンドと、それらの間のリンクは何ですか? ある種のグラフ データベース、新しいスキーマレス NoSQL のいずれか、またはもう少し従来型のグラフ データベースが適切でしょうか?

ストームは適していますか？

最後に、Storm はこの役割に適していますか、それとも他に適した役割がありますか?

また、Storm を使用する場合、これに取り組むためにどのようなアプローチを取ることができますか? 他の人が同様の問題セットを経験したことを願っています。

乾杯、ビクター

テストとシミュレーションの目的で、ストームプロジェクト全体を単一のマシンにセットアップできるかどうかを調べようとしているので、この質問は主にこれを試した人に向けられています.Hadoop（ストームのベースとなったもの）でそれを知っています）クラスターをシミュレートする機能を許可します。Mavenとそれを使用してStormをローカルで実行する方法について読んだことがありますが、Mavenとは何か、実際にどのように機能するかはわかりません。このあたりの誰かが私を助けてくれることを願っています。

KafkaSpout を使用している Storm トポロジのバランスを取り直そうとしています。私のコードは：

ただし、再調整中に、次のエラー トレースが表示されます。

何が問題なのか教えてください。リバランス時に適切にシャットダウンしてから再起動するように、kafkaSpout でさらに何かを定義する必要がありますか?

Linux マシンで Storm Topology を実行するための Maven プロジェクトをコンパイルしています。

以下はBoltクラスのメソッドです。ここでは、バッファリングされたリーダーが入力からデータを収集してファイルに書き込むファイルを実行時に作成したいと考えています。

タプル入力オブジェクト: 書き込まれるデータが含まれます。
/root/data/javacode/top_output.csv : ファイル名。
すべての IO パッケージは既にコードにインポートされています。

mvn パッケージを使用してプロジェクトをコンパイルするたびに、コンパイル エラーが発生します。

Filewriter 関連のコードにコメントを付けるたびに、正常に動作します。行番号は上記のコードに記載されています。コードのどこが間違っていますか?

私はStormを使用していますが、多くのユース ケースで問題ありません。最近、Storm の高レベルの抽象化であるTridentを調べました。1 回限りの処理をサポートし、ステートフルな処理を容易にします。

しかし今、私は疑問に思っています.なぜ、ストームの代わりに常にトライデントを使用できないのですか?

これまでに読んだこと：

• Trident はメッセージをバッチで処理するため、スループット時間が長くなる可能性があります。
• Trident はまだトポロジ内のループを処理できません。

ストームの代わりにトライデントを使用する場合、他に不利な点はありますか? 現時点では、上に挙げた欠点はわずかだと思います。

Trident で実装できないユースケースは?

余波：

私が質問をしたので、私の会社は最初にトライデントに行くことにしました。パフォーマンスに問題がある場合にのみ純粋な Storm を使用します。悲しいことに、これは積極的な決定ではなく、デフォルトの動作になっただけです (その時は私はいませんでした)。

彼らの仮定は、ほとんどのユースケースで状態または一度だけの処理が必要であるか、近い将来に必要になるというものでした。Storm から Trident へ、またはその逆に移行することは簡単な変換ではないため、彼らの理由は理解できますが、私の個人的な意見では、状態のないストリーム処理の概念はすべての人に理解されておらず、それが Trident を使用する主な理由でした。