HDFSのデータブロックサイズ、なぜ64MBですか？
HDFS/hadoopのデフォルトのデータブロックサイズは64MBです。ディスクのブロックサイズは通常4KBです。 64MBブロックサイズとはどういう意味ですか？ ->ディスクからの読み取りの最小単位が64MBであることを意味しますか？
はいの場合、それを行うことの利点は何ですか？
ディスク内の元の4KBブロックサイズを使用して同じことを実行できますか？
What does 64MB block size mean?
ブロックサイズは、ファイルシステムが保存できるデータの最小単位です。 1kまたは60Mbのファイルを保存すると、1ブロックかかります。 64Mbの境界を越えたら、2番目のブロックが必要です。
If yes, what is the advantage of doing that?
HDFSは大きなファイルを処理するためのものです。 1000Mbファイルがあるとしましょう。ブロックサイズが4kの場合、そのファイルを取得するために256,000リクエストを行う必要があります（ブロックごとに1リクエスト）。 HDFSでは、これらの要求はネットワークを介して送信され、多くのオーバーヘッドが伴います。各リクエストは、Name Nodeで処理する必要があります。そのブロックがどこにあるかを判断します。大量のトラフィックです！64Mbブロックを使用すると、リクエストの数は16になります。オーバーヘッドとネームノードの負荷のコストを大幅に削減します。
HDFSの設計は、もともとGoogleファイルシステム（GFS）の設計に触発されました。元のGFS論文で述べられているように、ブロックサイズが大きい2つの理由を以下に示します（GFS用語とHDFS用語の注1：チャンク=ブロック、チャンクサーバー=データノード、マスター=名前ノード、注2：太字のフォーマットは私のものです）：
大きなチャンクサイズには、いくつかの重要な利点があります。 まず、同じチャンクでの読み取りと書き込みは、チャンクの位置情報に関するマスターへの最初の要求を1つだけ必要とするため、クライアントがマスターと対話する必要性を減らします。アプリケーションのほとんどは大きなファイルを順番に読み書きするため、この削減はワークロードにとって特に重要です。 [...]Second、大きなチャンクでは、クライアントが特定のチャンクで多くの操作を実行する可能性が高いため、ネットワークのオーバーヘッドを削減できる持続的にTCP長期間にわたってチャンクサーバーに接続します。3番目に、マスターに保存されているメタデータのサイズを縮小します。これにより、メタデータをメモリに保存できます。次に、2.6.1で説明する他の利点をもたらします。
最後に、 Apache Hadoopの現在のデフォルトサイズ は128 MBであることを指摘する必要があります。
HDFSでは、ブロックサイズがレプリケーションのクラスター解除のレベルを制御します。ブロックサイズが小さいほど、ブロックはDataNodeに均等に分散されます。ブロックサイズが大きいほど、クラスター内でデータが均等に分散されない可能性があります。
それでは、低い値の代わりに高いブロックサイズを選択するポイントは何ですか？理論上はデータを均等に分散することは良いことですが、ブロックサイズが小さすぎると重大な欠点があります。 NameNodeの容量は限られているため、128MBではなく4KBのブロックサイズを使用すると、保存する情報が32768倍になります。 MapReduceは、より多くのNodeManagerとより多くのCPUコアでより多くのマップタスクを起動することにより、均等に分散されたデータからも利益を得ることができますが、実際には、各マップタスクの遅延のため、シーケンシャルなバッファ読み取りを実行できないことで理論上の利点が失われます。
通常のOSブロックサイズは4Kで、Hadoopでは64 Mbです。 Namenodeのメタデータを簡単に維持するためです。
Hadoopに4Kのブロックサイズしかなく、この4Kに100 MBのデータをロードしようとしている場合、より多くの数の4Kブロックが必要になります。そして、namenodeは、これらすべての4Kブロックのメタデータを維持する必要があります。
64MBのブロックサイズを使用する場合、データは2つのブロック（64MBと36MB）のみにロードされます。したがって、メタデータのサイズは小さくなります。
結論：ネームノードの負担を軽減するために、HDFSは64MBまたは128MBのブロックサイズを好みます。ブロックのデフォルトサイズは、Hadoop 1.0では64MB、Hadoop 2.0では128MBです。
- ブロックサイズが64未満に設定されている場合、クラスター全体に膨大な数のブロックが存在することになり、NameNodeが膨大な量のメタデータを管理することになります。
- 各ブロックにマッパーが必要なので、多くのマッパーがあり、各マッパーがデータの断片を処理しますが、これは効率的ではありません。
HDD（ハードディスクドライブ）のディスクシークに関連しています。時間の経過とともに、ディスクのスループットと比較すると、ディスクのシーク時間はそれほど進んでいませんでした。そのため、ブロックサイズが小さい場合（ブロックが多すぎる場合）、ディスクシークが多すぎてあまり効率的ではありません。 HDDからSDDに進むと、SSDの可動部分であるため、ディスクのシーク時間はあまり意味がありません。
また、ブロックが多すぎると、Name Nodeに負担がかかります。 Name Nodeはメタデータ全体（ブロックに関するデータ）をメモリに保存する必要があることに注意してください。ApacheHadoopではデフォルトのブロックサイズは64 MBで、Cloudera Hadoopではデフォルトは128です。 MB。
Hadoopが64MBを選択した理由は、Googleが64MBを選択したためです。 Googleが64MBを選択した理由は、Goldilocksの議論によるものです。
ブロックサイズをはるかに小さくすると、シークのオーバーヘッドが増加します。
ブロックサイズを適度に小さくすると、マップタスクの実行速度が十分に速くなり、スケジューリングのコストが実行のコストと同等になります。
ブロックサイズを大幅に大きくすると、使用可能な読み取り並列処理が減少し始め、最終的にはタスクのローカルでタスクをスケジュールするのが難しくなります。
Google Research Publication：MapReduceを参照してください http://research.google.com/archive/mapreduce.html
以下は、第3版「Hadoop：The Definitive Guide」という本の説明です（p45）。
HDFSのブロックが非常に大きいのはなぜですか？
HDFSブロックはディスクブロックに比べて大きく、その理由はシークのコストを最小限に抑えるためです。ブロックを十分に大きくすることにより、ディスクからデータを転送する時間は、ブロックの先頭をシークする時間よりも大幅に長くなる可能性があります。したがって、複数のブロックで構成される大きなファイルを転送する時間は、ディスク転送速度で動作します。
簡単な計算では、シーク時間が約10ミリ秒で、転送速度が100 MB /秒の場合、シーク時間を転送時間の1％にするには、ブロックサイズを約100 MBにする必要があります。多くのHDFSインストールでは128 MBブロックが使用されますが、デフォルトは実際には64 MBです。この数値は、新しい世代のディスクドライブで転送速度が向上するにつれて、引き続き上方修正されます。
ただし、この議論をあまりに遠慮すべきではありません。 MapReduceのマップタスクは通常、一度に1つのブロックで動作するため、タスクが少なすぎる（クラスター内のノードより少ない）場合、ジョブの実行速度が遅くなります。