Hadoop入力分割サイズとブロックサイズ
入力分割について明確に説明しているhadoopの決定的なガイドを通過します。それは次のようになります
入力スプリットには実際のデータは含まれず、HDFS上のデータへの保存場所があります
そして
通常、入力分割のサイズはブロックサイズと同じです
1） 64MBのブロックがノードAにあり、他の2つのノード（B、C）間で複製され、map-reduceプログラムの入力分割サイズが64MBであるとしましょう。ノードAの？または、3つのノードA、b、Cのすべての場所がありますか？
2）データは3つのノードすべてにローカルであるため、フレームワークが特定のノードで実行するmaptaskを決定（選択）する方法は？
）入力分割サイズがブロックサイズより大きいか小さい場合、どのように処理されますか？
@ user1668782による回答は、質問に対する優れた説明であり、それを図で表現しようと思います。
400MBのファイルがあり、4レコード（eg：400MBのcsvファイルで、4行、各100MBです）
- HDFSBlock Sizeが128MBとして構成されている場合、4つのレコードブロック間で均等に分散されません。こんな感じになります。
- ブロック1には、最初のレコード全体と2番目のレコードの28MBチャンクが含まれています。
- Block 1でマッパーを実行する場合、2番目のレコード全体がないため、マッパーは処理できません。
これはinput splitsが解決する正確な問題です。 Input splitsは、論理レコードの境界を尊重します。
入力スプリットサイズが200MBであると仮定しましょう
したがって、入力スプリット1にはレコード1とレコード2の両方が必要です。また、レコード2が割り当てられているため、入力スプリット2はレコード2で開始されません。入力スプリット1へ。入力スプリット2はレコード3から始まります。
これが、入力分割がデータの論理チャンクにすぎない理由です。開始位置と終了位置をブロックで示します。
お役に立てれば。
ブロックは、データの物理的な表現です。分割は、ブロックに存在するデータの論理表現です。
ブロックと分割のサイズはプロパティで変更できます。
マップはスプリットを通じてブロックからデータを読み取ります。つまり、スプリットはブロックとマッパーの間のブローカーとして機能します。
次の2つのブロックについて考えます。
ブロック1
aa bb cc dd ee ff gg hh ii jj
ブロック2
ww ee yy uu oo ii oo pp kk ll nn
マップはaaまでJAにブロック1を読み取り、ブロック2の読み取り方法を知りません。つまり、ブロックは異なる情報ブロックを処理する方法を知りません。これが分割され、ブロック1とブロック2の論理グループを単一のブロックとして形成します。次に、inputformatとレコードリーダーを使用してオフセット（キー）と行（値）を形成し、マップを送信してさらに処理を行います。
リソースが制限されていて、マップの数を制限したい場合は、分割サイズを増やすことができます。例：10ブロックの640 MB、つまり各ブロックが64 MBでリソースが制限されている場合、スプリットサイズを128 MBとすると、128 MBの論理グループが形成され、サイズが5のマップのみが実行されます128 MB。
分割サイズをfalseに指定すると、ファイル全体が1つの入力分割を形成し、1つのマップによって処理されます。ファイルが大きい場合は、処理に時間がかかります。
入力分割はレコードの論理的な分割であり、HDFSブロックは入力データの物理的な分割です。同じ場合は非常に効率的ですが、実際には完全に調整されることはありません。レコードはブロックの境界を越える場合があります。 Hadoopはすべてのレコードの処理を保証します。特定のスプリットを処理するマシンは、「メイン」ブロック以外のブロックからレコードのフラグメントをフェッチし、リモートに存在する場合があります。レコードフラグメントをフェッチするための通信コストは、比較的まれにしか発生しないため、重要ではありません。
Hadoopフレームワークの強みはそのデータの局所性です。そのため、クライアントがhdfsデータを要求するときはいつでも、フレームワークは常に局所性をチェックし、それ以外の場合はほとんどI/O使用率を探しません。
HDFSブロックサイズは正確な数値ですが、入力分割サイズはデータロジックに基づいており、構成された数値とは少し異なる場合があります
1）と2）へ：私は100％確実ではありませんが、タスクが完了できない場合（入力スプリットに問題があるかどうかなど、何らかの理由で）終了し、別のタスクがその場所で開始されます。 maptaskは、ファイル情報を含む1つの分割を取得します（ローカルクラスターをデバッグして、入力分割オブジェクトに保持されている情報を確認することで、これが当てはまるかどうかをすばやく確認できます。私はそれが1つの場所にすぎないことを思い出します）。
3）に：ファイル形式が分割可能な場合、Hadoopはファイルを「inputSplit」サイズのチャンクに切り詰めようとします。そうでない場合は、ファイルサイズに関係なく、ファイルごとに1つのタスクです。 minimum-input-splitの値を変更すると、各入力ファイルがブロックサイズに分割されている場合に生成されるマッパータスクが多すぎるのを防ぐことができますが、combineしかできませんあなたがコンバイナクラスで魔法をかけた場合の入力（私はそれが呼ばれていると思います）。
入力スプリットは、各マッパーに供給される論理データユニットです。データは有効なレコードに分割されます。入力スプリットには、ブロックのアドレスとバイトオフセットが含まれます。
たとえば、4つのブロックにまたがるテキストファイルがあるとします。
ファイル：
- あいうえお
e f g h
i j k l
m n o p
ブロック：
block1：a b c d e
block2：f g h i j
block3：k l m n o
block4：p
分割：
分割1：a b c d e f h
分割2：i j k l m n o p
分割がファイルの境界（レコード）と一致していることを確認します。現在、各スプリットはマッパーに送られます。
入力分割サイズがブロックサイズよりも小さい場合、no.ofマッパーをより多く使用することになります。逆も同様です。
お役に立てば幸いです。