3

8 つのノードを持つクラスター セットアップがあり、20 GB のテキスト ファイルを mapreduce で解析しています。通常、私の目的は、マッパーによってすべての行を取得し、入力ファイルの行の列の 1 つであるキーを使用して送信することです。レデューサーがそれを取得すると、キー値に基づいて別のディレクトリに書き込まれます。例を挙げると：入力ファイル：

test;1234;A;24;49;100

test2;222;B;29;22;22

test2;0099;C;29;22;22

したがって、これらの行は次のように記述されます。

/output/A-r-0001

/output/B-r-0001

/output/C-r-0001

レデューサーで MultipleOutputs オブジェクトを使用していますが、小さなファイルを使用する場合はすべて問題ありません。しかし、20GBのファイルを使用すると、152個のマッパーと8個のリデューサーが初期化されています。マッパー側ではすべてが非常に高速に終了しますが、1 つのレデューサーが継続します。減速機の 7 つは最大 18 分で終了しますが、最後の減速機は 3 時間かかります。まず、そのレデューサーの入力が他のレデューサーよりも大きいと思われますが、そうではありません。1 つの Reducer は遅いものよりも 3 倍の入力があり、17 分で終了します。

また、reducer の数を 14 に増やそうとしましたが、これにより、さらに 2 つの遅い reduce タスクが発生しました。

多くのドキュメントをチェックしましたが、なぜこれが起こっているのかわかりませんでした。手伝ってくれませんか？

編集済み

この問題は、データセット内の一部のデータが破損していたことが原因でした。マッパー側で入力データにいくつかの厳密なチェックを行いましたが、現在は正常に機能しています。

みんなありがとう。

4

3 に答える 3

6

歪んだデータを扱うときに頻繁に発生するのを見てきました。したがって、データセットが歪んでいると推測されます。つまりMapper、同じキーを持つ多くのレコードを発行し、同じリデューサーに送られ、オーバーロードされます。通過する多くの値。

これには簡単な解決策はありません。実際には、ジョブのビジネス ロジックに依存します。おそらく、ReducerN 個を超える値がある場合は、N の後のすべての値を無視するようにチェックすることができます。

また、論文で説明されているように、Hadoop 環境で歪んだデータを管理しやすくすることになっているSkewReduceに関するドキュメントもいくつか見つけましたが、自分で試したことはありません。

于 2013-05-30T16:42:26.200 に答える
0

これは、低速実行レデューサーと高速実行レデューサーのカウンターです。

task_201403261540_0006_r_000019 の実行速度は非常に遅く、task_201403261540_0006_r_000000 は非常に速く完了しました

私のレデューサーの1つが膨大な数のキーを取得していることは非常に明らかです。カスタム パーティショナーを最適化する必要があります

ここに画像の説明を入力

ここに画像の説明を入力

于 2014-03-27T13:06:57.500 に答える