Hadoop 0.21.0を考えると、フレームワークは、個々のマップに関連する開いているファイル記述子の数に関してどのような仮定を行い、操作を減らしますか？具体的には、ジョブの実行中にHadoopが新しいファイル記述子を開いたり、ディスクにスピルしたりする原因となるサブオペレーションは何ですか？
MultipleOutputs（これは、システムによって提供される保証に非常に明確にねじ込まれているため、意図的にの使用を無視しています。）
ここでの私の理論的根拠は単純です。Hadoop用に作成する各ジョブが、各マッパーまたはレデューサーに必要な有限数のファイル記述子を保証するようにしたいのです。Hadoopは、これをプログラマーから元気に抽象化します。これは、サーバー管理中にドロップする他の靴がなければ、通常は良いことです。
私はもともと、サーバー障害についてクラスター管理側からこの質問をしていました。私はプログラミングも担当しているので、この質問はここでも同様に適切です。
問題への洞察を提供する投稿は次のとおりです。
これは、クラスを使用すると、より多くの小さなファイルが作成されるために発生します
MultipleOutputs。50個のマッパーがあり、偏ったデータがないと仮定すると、Test1は常に正確に50個のファイルを生成しますが、Test2は50〜1000個のファイル（50Mappers x 20TotalPartitionsPossible）を生成し、これによりI/Oのパフォーマンスが低下します。私のベンチマークでは、Test1用に199個の出力ファイルが生成され、Test2用に4569個の出力ファイルが生成されました。
これは、通常の動作では、マッパーの数が開いているファイル記述子の数とまったく同じであることを意味します。MultipleOutputs明らかに、この数をマッパーの数に使用可能なパーティションの数を掛けたもので歪めます。その後、レデューサーは通常どおりに続行し、リデュース操作ごとに1つのファイル（したがって、1つのファイル記述子）を生成します。
問題は次のようになります。spill操作中、出力が分割によって元気に武装されているため、これらのファイルのほとんどは各マッパーによって開いたままになっています。したがって、利用可能なファイル記述子の問題。
したがって、現在想定されている最大ファイル記述子の制限は次のようになります。
マップフェーズ：
number of mappers * total partitions possibleフェーズを減らす：
number of reduce operations * total partitions possible
そして、私たちが言うように、それはそれです。