Hadoopはキーを複数のレデューサープールに分割しますか？

Question

私は非常に大量のデータに対してハンプジョブを実行しようとしており、最大32のレデューサーを使用しています。しかし、各減速機の出力を見ると、複数の減速機が（もちろん異なる値の）キーを取得することがあります。より多くのレデューサーを使用している間、この現象を回避できますか？

LE：代わりにTextクラスを試してみましたが、正常に動作しますが、ヒープスペースが不足してjvmがクラッシュするという問題がありました。 compareToとは別に、キープールにデータを分割するためにhadoopが使用する基準は何ですか？

Answer 1

あなたは、あなたが（WritableComparableを実装）カスタムキーを持っていると言うあなたはhashCode()メソッドをオーバーライドしていますか？

HashPartitioner（デフォルト）を使用していて、カスタムキーのhashCode()メソッドをオーバーライドしていない場合、異なるマッパーからの2つの同一のキーは、おそらく異なるレデューサーになりますhashCode（）は、キー/値のペアを送るレデューサーを決定するためのレデューサーの数とモジュロされます）。これは、デフォルトではhashCode（）メソッドがネイティブであり、オブジェクトのメモリ内のアドレスを返します。

キーの単純なhashCode実装は、タプルフィールドのハッシュコードを一緒に追加するフィールドが）非ネイティブのhashCodeの実装そのものを持っている：

public int hashCode() { 
    return field1.hashCode() + field2.hashCode() 
} 

Answer 2

あなたが見ているのは投機的な実行であると思われます。通常、指定されたキーのすべての値は常にちょうど1つのレデューサーに移動します。 http://developer.yahoo.com/hadoop/tutorial/module4.htmlから：

投機的実行：一つのHadoopシステムに問題がいくつか遅い ノードがレート制限をするためのプログラムの残りの部分を多くのノード間でタスクを分割することによって、それが可能であるということです。たとえば、1つのノード に低速のディスクコントローラがある場合は、他のすべてのノードの速度の10％だけ で入力を読み取っている可能性があります。したがって、99のマップタスクがすでに 完了している場合、システムは最終的なマップタスクが をチェックするのを待っています。これは他のすべてのノードよりもはるかに時間がかかります。

タスクを互いに独立して実行することによって、個々の入力は入力がどこから来るのかを知りません。タスクは、Hadoop プラットフォームが適切な入力を行うだけであることを信頼します。したがって、同一の 入力を並列に複数回処理して、 マシンの機能の違いを利用することができます。ジョブ内のほとんどのタスクが終了すると、Hadoopプラットフォームは残りのタスクのうち冗長コピー を実行する他のタスクを持たないいくつかのノードにスケジューリングします。このプロセスは、投機的実行として知られています。 タスクが完了すると、この事実がJobTrackerに通知されます。どちらの場合であっても、最初に完了したタスクのコピーが確定コピーになります。他の のコピーが投機的に実行されていた場合、HadoopはTaskTrackersに にタスクを放棄して出力を破棄するよう指示します。その後、Reducersは、マッパーが正常に完了した時点から入力を で受信します。

投機実行は、デフォルトで有効になっています。 mapred.map.tasks.speculative.executionと mapred.reduce.tasks.speculative.execution JobConfオプションをそれぞれ偽（ ）に設定すると、マッパーとレデューサーの投機実行を無効にできます。