3

再帰的に適用する必要があるフィルタリング アルゴリズムがあり、MapReduce がこのジョブに適しているかどうかわかりません。あまり多くを与えることなく、フィルタリングされている各オブジェクトは、順序付けられたリストまたはキューのコレクションによって特徴付けられると言えます。

  1. SQLからCSVにエクスポートすると、データはそれほど大きくなく、約250MBです。
  2. マッピングの手順は簡単です。リストの先頭には、リストをN 個のマッピング ノードの 1 つに属するものとして分類できるオブジェクトが含まれています。各ノードのフィルタリング アルゴリズムは、ノードに割り当てられたリストのコレクションに対して機能し、フィルタリングの最後に、リストがフィルタリング前と同じままであるか、リストの先頭が削除されます。
  3. reduce 関数も単純です。すべてのマップ ジョブのリストがまとめられ、ディスクに書き戻す必要がある場合があります。
  4. N 個のノードすべてが出力を返すと、この新しいデータ セットを使用してマッピング ステップが繰り返されます。

注: Nは最大 2000 ノードです。シンプルですが、アルゴリズムの終了条件が満たされるまでに、おそらく最大 1000 回の再帰が必要です。

私の質問は、この仕事は Hadoop に適しているでしょうか? そうでない場合、どのような選択肢がありますか?

4

3 に答える 3

1

Hadoop の主な強みは、多数のマシンに作業を透過的に分散できることです。Hadoop を最大限に活用するには、少なくとも次の 3 つの点でアプリケーションを特徴付ける必要があります。

  1. 大量のデータ (マシンのクラスターに分散されたデータ) を扱う - 1 台のマシンに保存するのは不可能です。
  2. データを並列化できる (つまり、元のデータのチャンクを他のチャンクから独立して操作できる)
  3. アプリケーションが解決しようとしている問題は、MapReduce (スキャッター - ギャザー) モデルに適しています。

これら3つのうち、アプリケーションには最後の2つの特徴しかないようです（スキャッターを再帰的に使用しようとしているという観察があります-収集手順-これは、再帰の深さに等しい多数のジョブを意味します;最後の段落を参照してくださいこれが Hadoop には適切ではない理由)。

処理しようとしているデータの量を考えると、単一のマシンで完全にメモリ内で処理しない理由はわかりません。その少量のデータを並列処理することでメリットが得られると思われる場合は、分散データ集約型処理よりもマルチコア処理に重点を置くことをお勧めします。もちろん、ネットワーク化されたクラスターの処理能力を使用することは魅力的ですが、これにはコストがかかります。主に、ネットワーク通信 (ネットワークは Hadoop クラスターで最も競合するリソースです) と I/O によってもたらされる時間の非効率性です。Hadoop フレームワークに適したシナリオでは、データの分散とそのデータに関連する作業によって効率が向上するため、これらの非効率性は無視できます。

ご覧のとおり、1000 個のジョブが必要です。これらすべてのジョブのセットアップとクリーンアップは、シナリオにとって不要なオーバーヘッドになります。また、私の意見では、ネットワーク転送のオーバーヘッドは必要ありません。

于 2012-08-06T21:56:31.367 に答える
0

再帰的アルゴは、すぐに飢餓につながる可能性があるため、分散システムでは困難です。そのために機能するミドルウェアは、分散継続をサポートする必要があります。つまり、呼び出し側のリソース（スレッドなど）を保持せずに「再帰的」呼び出しを行う機能です。

GridGainは、分散継続をネイティブにサポートする1​​つの製品です。

分散継続に関するリトマス試験：再帰呼び出しを使用して、分散コンテキストでナイーブなフィボナッチ実装を開発してみてください。これは、継続を使用してこれを実装するGridGainの例です。

それが役に立てば幸い。

于 2012-08-07T16:19:07.590 に答える
-1

Q&D ですが、MongoDB と Hadoop の比較を読むことをお勧めします: http://www.osintegrators.com/whitepapers/MongoHadoopWP/index.html

もっと知らなければ、それを言うのは難しいです。両方試してみるのもいいかもしれません。もしそうなら、あなたの結果を投稿してください！

于 2012-08-06T21:33:55.197 に答える