これはばかげた質問のように思えるかもしれませんが、Hadoop では、ブロックサイズが X (通常は 64 または 128 MB) で、ローカル ファイルサイズが Y (Y は X より小さい) であると仮定します。ファイル Y を HDFS にコピーすると、1 つのブロックが消費されます。または、hadoop はより小さいサイズのブロックを作成しますか?
1 に答える
1 つのブロックが Hadoop によって消費されます。これは、ストレージ容量が同じように消費されるという意味ではありません。
Web から HDFS を参照する際の出力は次のようになります。
filename1 file 48.11 KB 3 128 MB 2012-04-24 18:36
filename2 file 533.24 KB 3 128 MB 2012-04-24 18:36
filename3 file 303.65 KB 3 128 MB 2012-04-24 18:37
各ファイル サイズが 128 MB のブロック サイズよりも小さいことがわかります。これらのファイルの単位は KB です。HDFS 容量は実際のファイル サイズに基づいて消費されますが、ファイルごとに 1 ブロックが消費されます。
HDFS の容量に応じて、使用できるブロックの数が制限されます。実際のストレージ容量をすべて利用する前にブロックを使い果たしてしまうため、ブロックを浪費しています。Unix ファイルシステムにもブロックサイズの概念がありますが、512 バイト前後の非常に小さい数値であることを思い出してください。この概念は HDFS では逆になり、ブロック サイズは 64 ~ 128 MB 程度に大きく保たれます。
もう 1 つの問題は、map/reduce プログラムを実行すると、ブロックごとにマッパーを生成しようとするため、この場合、3 つの小さなファイルを処理しているときに、最終的にそれらを処理するために 3 つのマッパーを生成することになる可能性があることです。ファイルのサイズが小さい場合、これはリソースを浪費します。また、各マッパーがスポーンするのに時間がかかり、最終的には非常に小さなサイズのファイルで動作するため、レイテンシも追加されます。より少ない数のファイルで動作するマッパーを利用するには、それらをブロックサイズに近いファイルに圧縮する必要があります。
多数の小さなファイルのさらに別の問題は、各ブロックのマッピング (メタデータ) とメイン メモリ内のチャンク マッピングを保持する namenode をロードすることです。ファイルが小さいほど、このテーブルが早くいっぱいになり、メタデータが大きくなるにつれて、より多くのメイン メモリが必要になります。
以下を参照してください。