0

Hadoop GUIを確認したところ、reduceタスクの一部が66.66％に達しており、それらは長期間そこにとどまっていることがわかりました。カウンターを調べてみると、違います。入力レコードの数はゼロとして表示されます。

久しぶりに入力レコードを取得し、処理を開始します。いくつかは、より長い時間でも0の入力レコードを表示し、タスクの試行によって強制終了され、600ミリ秒間ステータスを報告できませんでした。

ただし、一部のレデューサーは、入力レコードをカウンターにすぐに表示し、すぐに処理を開始します。

一部のレデューサーの入力レコードの取得になぜこれほどの遅延があるのか​​、私にはわかりません。これはこのプログラムでのみ発生し、他のプログラムでは発生しません。

このmapreduceジョブでは、reduceのreduceメソッドの前のconfigureメソッドで、分散キャッシュから大量のデータを読み取りました。これが理由ですか？私はわかりません。

4

1 に答える 1

1

はい、分散キャッシュからの読み取りが遅延の理由であると思います。configure()ただし、の前または後に保持しても違いはありませんreduce()。最終的にconfigure()はメソッドを最初に呼び出す必要がrun()あるため、レデューサーのを見ると次のようになります（新しいAPI）。

public void run(Context context) throws IOException, InterruptedException {

    setup(context); // This is the counterpart of configure() from older API

    while (context.nextKey()) {
        reduce(context.getCurrentKey(), context.getValues(), context);
    }
    cleanup(context);
}

ご覧のとおり、setup()は前reduce()に呼び出され、同様に古いAPIでは、終了しない限りconfigure()実際のreduceタスクは開始されません（これは、入力レコード数が表示されないことを説明しています）。

ここで、パーセンテージ66%について：、reduceフェーズには実際に次のサブパートがあることがわかります。

  1. コピー
  2. 選別
  3. 減らす

したがって、最初の2つのステップが完了し、3番目のステップが開始されたが、configure()終了（分散キャッシュの読み取り）が完了するのを待っていたため、削減率は66％でした。

于 2013-03-16T18:58:59.523 に答える