「Hadoop 決定版ガイド」より [各 map タスクには、出力を書き込む循環メモリ バッファがあります。バッファはデフォルトで 100 MB ですが、このサイズは io.sort.mb プロパティを変更することで調整できます。バッファーの内容が特定のしきい値サイズ (io.sort.spill.percent、デフォルトは 0.80 または 80%) に達すると、バックグラウンド スレッドが内容をディスクにスピルし始めます]
ここでの問題は、各マップ タスクが 1 つの入力分割 (HDFS ブロックのサイズ、つまり 64 MB にほぼ等しい) で動作するため、ディスクにスピルバックする条件が発生しないことです。私は何かが欠けていますか？助けてください。
分割サイズまたはブロック サイズが 64 MB になると想定するのはなぜですか? 実際には、ブロックサイズが小さいとパフォーマンスが低下することがわかりました（分析するデータの規模について）。私のユース ケースでは、256MB のブロック サイズ/分割サイズでパフォーマンスが向上しました。
質問に戻りますが、マッパーが多すぎると、フレームワークのオーバーヘッドにもなります。質問に記載されている使用例では、100 MB の循環バッファーからキーや値をこぼしていない可能性があります。ただし、分割サイズが 64MB で、Mapper が入力に基づいていくつかの計算を行い、Map 出力の一部として追加の計算結果を出力する場合を考えてみてください。Map 出力が構成された循環バッファー サイズを超える可能性があります。別のユース ケースでは、64 MB のブロック圧縮データがあり、処理中にデータのサイズがバーストします。マップ フェーズで「サイド データ配布」、「分散キャッシュ」から追加データをフェッチするマッパーを考慮します。
追加のメモ: 私の経験から、フレームワークに取り組んでいるとき、またはフレームワークを使用して作業しているとき、デフォルトの構成が要件に合わないことは明確に言えます。可能な限り最高のパフォーマンスを実現するには、システムを微調整して調整する必要があります。