6

特定のフローで非同期にデータを消費および生成する必要がある分散処理ワーカーのセットを必要とするアプリケーションを設計しています。例えば：

  • コンポーネント A はページをフェッチします。
  • コンポーネント B は、A のページを分析します。
  • コンポーネント C は、B からの分析された断片を保存します。

明らかに、関連するコンポーネントは 3 つだけではありません。

その他の要件:

  • 各コンポーネントは、個別のプロセス (または一連のプロセス) である必要があります。
  • 生産者は消費者について何も知りません。つまり、コンポーネント A はデータを生成するだけで、どのコンポーネントがそのデータを消費するかはわかりません。

これは、 Stormのようなトポロジ指向のシステムによって解決される一種のデータ フローです。Storm は良さそうに見えますが、私は懐疑的です。これは Java システムであり、Thrift をベースにしていますが、どちらも好きではありません。

私は現在、AMQP をデータ トランスポートとして使用し、HTTP をデータ共有/ストレージのプロトコルとして使用するパブ/サブ スタイルのアプローチに傾いています。これは、AMQP キュー モデルがパブリック API になることを意味します。つまり、コンシューマーは、プロデューサーが使用する AMQP ホストとキューを知る必要があります。これについては特に満足しているわけではありませんが、妥協する価値はあるかもしれません。

AMQP アプローチのもう 1 つの問題は、各コンポーネントが次のように非常に類似したロジックを持つ必要があることです。

  • キューへの接続
  • 接続エラーの処理
  • データを共通の形式にシリアライズ/デシリアライズする
  • 実際のワーカーの実行 (ゴルーチンまたはフォーク サブプロセス)
  • ワーカーの動的スケーリング
  • 耐障害性
  • ノード登録
  • 処理指標
  • キューのスロットリング
  • キューの優先順位付け (一部のワーカーは他のワーカーよりも重要度が低い)

…そして、各コンポーネントが必要とする他の多くの詳細。

コンシューマーが論理的に非常に単純であっても (MapReduce ジョブ、テキストをトークンに分割するようなものを考えてください)、ボイラープレートがたくさんあります。確かに、私はこれらすべてを自分で行うことができます — 私は AMQP やキュー、その他すべてに精通しています — すべてのコンポーネントで共有される共通のパッケージにこれらすべてをラップしますが、その場合はすでにフレームワークを発明する途中です。

この種のもののための良いフレームワークは存在しますか?

Goについて具体的に尋ねていることに注意してください。Hadoop と Java スタック全体を避けたい。

編集：明確にするためにいくつかのポイントを追加しました。

4

3 に答える 3

1

GoにはCSPチャネルがあるため、Goは、単純で簡潔でありながら完全に一般的な並列処理のフレームワークを実装する特別な機会を提供することをお勧めします。かなり少ないコードで、ほとんどの既存のフレームワークよりもかなりうまくいくはずです。JavaとJVMはこのようなものを持つことができません。

構成可能なTCPトランスポートを使用したチャネルの実装のみが必要です。これはで構成されます

  • 読み取り側の対象サーバーの一般的な仕様を含む、書き込みチャネル側のAPI
  • リスニングポートの設定とサポートを含む、読み取りチャネルエンドAPIselect
  • データを転送するためのマーシャリング/アンマーシャリング接着剤-おそらくエンコーディング/ゴブ

このようなフレームワークの成功の受け入れテストは、チャネルを使用するプログラムが複数のプロセッサ間で分割可能でありながら、（パフォーマンスが異なっていても）同じ機能動作を維持する必要があることです。

Goにはかなりの数の既存のトランスポート層ネットワーキングプロジェクトがあります。注目すべきはZeroMQ（0MQ）（gozmq、zmq2、zmq3）です。

于 2013-03-18T22:40:00.247 に答える
0

Beanstalkd、RabbitMQ、またはØMQ（ゼロMQと発音）などのメッセージキューを探していると思います。これらすべてのツールの本質は、FIFO（または非FIFO）キューのプッシュ/受信メソッドを提供し、一部にはpub/subを備えていることです。

したがって、1つのコンポーネントがデータをキューに入れ、別のコンポーネントが読み取ります。このアプローチは、コンポーネントの追加または削除、および各コンポーネントのスケールアップまたはスケールダウンにおいて非常に柔軟です。

これらのツールのほとんどには、Go（ØMQはGopherの間で非常に人気があります）や他の言語用のライブラリがすでにあるため、オーバーヘッドコードはごくわずかです。ライブラリをインポートして、メッセージの受信とプッシュを開始するだけです。

また、このオーバーヘッドを減らし、特定のAPIへの依存を回避するために、これらのメッセージキューシステムの1つを使用して非常に単純なプッシュ/受信呼び出しを提供し、すべてのツールでこのパッケージを使用するシンパッケージを作成できます。

于 2013-03-16T16:51:58.070 に答える
0

Hadoop + Java を避けたいと考えていることは理解していますが、独自のフレームワークの開発に時間を費やす代わりに、Cascadingを検討することをお勧めします。基礎となる MapReduce ジョブを抽象化するレイヤーを提供します。

ウィキペディアで最もよく要約されています。[カスケーディング]は、データがソースからキャプチャされる「ソース-パイプ-シンク」パラダイムに従い、結果が出力ファイルまたは「シンク」に保存されるデータ分析プロセスを実行する再利用可能な「パイプ」に従います。 . パイプは、処理するデータから独立して作成されます。データ ソースとシンクに結び付けられると、それは「フロー」と呼ばれます。これらのフローは「カスケード」にグループ化でき、プロセス スケジューラは、すべての依存関係が満たされるまで特定のフローが実行されないようにします。パイプとフローを再利用したり並べ替えたりして、さまざまなビジネス ニーズをサポートできます。

Log Parser、Log Analysis、TF-IDF (特にこのフロー図)など、いくつかの例も参照してください。

于 2013-03-17T04:06:27.083 に答える