下記のHadoop糸では、MapReduceマップメモリがクラスタ上のブロックサイズよりも大きいのはなぜですか？
a）各InputSplitまたはブロックに対して、新しいマップがトリガーされます。
b）クラスタの典型的なブロックサイズは128 MBです。
c）MapReduce.map.memory.mbは、ほとんどのクラスタで1GBより大きく設定されています。
は、実際にはClouderaのブロックサイズの推奨は、128 MBで、ブロックサイズは、我々はマップメモリに1 GBを割り当てる必要があります理由だけで128メガバイト、あるときMapReduce.map.memory.mbはGB1であります（MapReduce.map.memory.mb）？理想的には、128 MBが最大限のニーズを満たす必要があります。なぜマップメモリのブロックサイズ以上を与えているのでしょうか？
それぞれのコンテナ（マッパーが実行されている）は別々のJVM上で実行されています。 mapreduce.map.memory.mbには、ヒープ、スタックなどのコンテナに必要なスペースがすべて含まれています。そのため、ブロックサイズ128MBの処理をロードするだけでなく、他のJVM関連プロセスも管理する必要があります。
MapReduceはマップ機能を使用してデータをストリーミングする必要があるため、128 MB入力ブロック全体をメモリにロードしません。
しかし、いくつかの出力とスピルバッファと並べ替えバッファは維持する必要があり、かなり大きくなります（最大64MB、mapreduce.task.io.sort.mbのデフォルトは100MBです）。
また、独自のマップ処理ロジックには、メモリが関連付けられている必要があります。たとえば、他の場所からロードされている追加のリソースです。結局のところ、1GBは安全なデフォルトであり、必ずしも入力ブロックサイズに結びついているわけではありません。
割り当てられたスピルバッファを割り引くフレームワークのオーバーヘッドは、非常に小さい（< 50MB）。
ありがとう@トーマスの説明。出力、スピルバッファ、ソートバッファにはメモリが必要であることが理にかなっています。出力として、スピルバッファとソートバッファは、128 MBのブロックで実行されるマップ関数からのデータからのものです。ブロックサイズが256 MBの場合、MapReduce.map.memory.mbに割り当てられるメモリが増えると思いますか？ – Premchand
@Premchand私は、入力ブロックサイズに基づいてマッパーのヒープメモリを変更するとは思わないでしょう。 –