7

したがって、通常、20ノードのクラスターが3GB（200分割）のデータを処理するジョブを送信するには、約30秒かかり、実際の実行には約1mかかります。求人の提出プロセスのボトルネックを理解し、次の見積もりを理解したい

MapReduceごとのオーバーヘッドは重要です：MapReduceジョブの開始/終了には時間がかかります

私が知っているいくつかのプロセス：1。データ分割2.jarファイル共有

4

3 に答える 3

14

このレイテンシーを理解するのに役立つHDFSとM/Rについて理解すべきいくつかのこと：

  1. HDFSは、データノードと呼ばれる複数のマシンに分散されたデータチャンクとしてファイルを保存します
  2. M / Rは、データチャンクまたはブロックごとにマッパーと呼ばれる複数のプログラムを実行します。これらのマッパーの（key、value）出力は、レデューサーによって結果として一緒にコンパイルされます。（複数のマッパーからのさまざまな結果を合計することを考えてください）
  3. 各マッパーとレデューサーは、これらの分散システムで生成される本格的なプログラムです。何もしなかったと言っても、本格的なプログラムを作成するには時間がかかります（No-OPマップリデュースプログラム）。
  4. 処理されるデータのサイズが非常に大きくなると、これらのスポーン時間は重要ではなくなり、Hadoopが光ります。

1000行のコンテンツを含むファイルを処理する場合は、通常のファイル読み取りおよび処理プログラムを使用することをお勧めします。分散システムでプロセスを生成するHadoopインフラストラクチャはメリットをもたらしませんが、関連するデータチャンクを含むデータノードの検索、それらの処理プログラムの開始、結果の追跡と収集の追加のオーバーヘッドにのみ貢献します。

次に、それを100ペタバイトのデータに拡張します。これらのオーバーヘッドは、処理にかかる時間と比較して、まったく重要ではないように見えます。プロセッサー（マッパーとレデューサー）の並列化は、ここでの利点を示します。

したがって、M / Rのパフォーマンスを分析する前に、オーバーヘッドをよりよく理解できるように、まずクラスターのベンチマークを検討する必要があります。

クラスターで操作なしのmap-reduceプログラムを実行するには、どのくらいの時間がかかりますか？

この目的でMRBenchを使用します。

  1. MRbenchは小さなジョブを何度もループします
  2. 小さなジョブの実行が応答性があり、クラスター上で効率的に実行されているかどうかを確認します。
  3. HDFSレイヤーへの影響は非常に限られています

このプログラムを実行するには、次のことを試してください（最新バージョンの正しいアプローチを確認してください：

hadoop jar /usr/lib/hadoop-0.20/hadoop-test.jar mrbench -numRuns 50

驚いたことに、開発クラスターの1つでは22秒でした。

もう1つの問題はファイルサイズです。

ファイルサイズがHDFSブロックサイズよりも小さい場合、Map/Reduceプログラムにはかなりのオーバーヘッドがあります。Hadoopは通常、ブロックごとにマッパーを生成しようとします。つまり、5KBのファイルが30個ある場合、ファイルのサイズが小さくても、Hadoopは最終的にブロックごとに30個のマッパーを生成する可能性があります。小さなサイズのファイルの処理に費やす時間と比較して、各プログラムのオーバーヘッドが大きいため、これは実際の無駄です。

于 2012-07-06T21:00:36.967 に答える
5

私の知る限り、ジョブの実行遅延を引き起こす単一のボトルネックはありません。もしあったとしたら、それはずっと前に解決されていただろう。

時間がかかるステップがいくつかあり、プロセスが遅い理由があります。私はそれらをリストし、私ができる場所を推定しようとします：

  1. hadoopクライアントを実行します。Javaを実行しており、約1秒のオーバーヘッドが想定できると思います。
  2. ジョブをキューに入れ、現在のスケジューラーにジョブを実行させます。オーバーヘッドが何であるかはわかりませんが、プロセスの非同期性のため、ある程度の遅延が存在するはずです。
  3. 分割の計算。
  4. タスクの実行と同期。ここで、TaskTrackesがJobTrackerをポーリングし、反対ではないという事実に直面します。スケーラビリティのために行われていると思います。つまり、JobTrackerが何らかのタスクを実行する場合、タスクトラッカーは呼び出されませんが、適切なトラッカーがpingを実行してジョブを取得するのを待ちます。タスクトラッカーはJobTrackerに頻繁にpingを実行できません。そうしないと、大規模なクラスターでJobTrackerを強制終了します。
  5. タスクの実行。JVMを再利用しない場合は、約3秒かかります。オーバーヘッドがある場合、タスクごとに約1秒かかります。
  6. クライアントは結果についてジョブトラッカーをポーリングし（少なくとも私はそう思います）、ジョブが終了したという情報を取得するための待ち時間も追加します。
于 2012-07-07T09:56:23.157 に答える
1

私は同様の問題を見てきました、そして私は次のステップで壊れている解決策を述べることができます：

  1. HDFSが固定チャンクサイズの小さなファイルをあまりにも多く保存する場合、HDFSの効率に問題が発生します。最善の方法は、不要なファイルとデータを含む小さなファイルをすべて削除することです。再試行。

  2. データノードと名前ノードを試してみてください。

    • stop-all.shを使用してすべてのサービスを停止します。
    • フォーマット名-ノード
    • マシンを再起動します
    • start-all.shを使用してすべてのサービスを開始します
    • データを確認し、ノードに名前を付けます。

  3. 2つのケースで機能し、ヒットとトライアルで機能した下位バージョンのhadoop（hadoop 2.5.2）をインストールしてみてください。

于 2017-02-01T01:53:27.773 に答える