0

生成された map() の数は、入力データの 64MB ブロックの数と同じです。サイズが 1MB の入力ファイルが 2 つあるとします。両方のファイルが 1 つのブロックに格納されます。しかし、1 つの namenode と 2 つの jobnode を使用して MR プログラムを実行すると、各ファイルに 1 つずつ、2 つの map() が生成されます。これは、システムが 2 つのノード間でジョブを分割しようとしたためです。つまり、

Number of map() spawned = number of 64MB blocks of input data * number of jobnodes ?

また、mapreduce のチュートリアルでは、ブロックサイズが 128KB の 10TB のファイルに対して 82000 個のマップが生成されると書かれています。ただし、マップの数はブロック サイズのみに依存するというロジックに従って、78125 ジョブを生成する必要があります (10TB/128MB)。余分なジョブがどれだけ生成されたか理解できませんか? 誰かがこれについてあなたの考えを共有できれば素晴らしいことです? ありがとう。:)

4

3 に答える 3

0

マッパーの数は、使用しているによって作成された InputSplits の数のみに依存しInputFormatます (デフォルトは、\n を区切り文字として取る分割を作成する TextInputFormat です)。いいえに依存しません。ノード数、ファイル、ブロックサイズ (64MB など)。分割がブロックに等しい場合は非常に良いです。しかし、これは単なるideal状況であり、cannot be guaranteed常にです。MapReudce フレームワークは、プロセスを最適化するために最善を尽くします。そして、このプロセスでは、ファイル全体に対して 1 つのマッパーのみを作成するようなことが起こります (ファイルサイズがブロック サイズよりも小さい場合)。もう 1 つの最適化は、分割数より少ない数のマッパーを作成することです。For exampleファイルに 20 行があり、TextInputFormat を使用している場合、20 個のマッパーが得られると考えるかもしれません (マッパーの数 = 分割の数であり、TextInputFormat は \n に基づいて分割を作成します)。しかし、これは起こりません。このような小さなファイルに対して 20 個のマッパーを作成すると、不要なオーバーヘッドが発生します。

また、分割のサイズがブロック サイズよりも大きい場合、残りのデータは別のマシン上の他のリモート ブロックから移動されて処理されます。

MapReduce チュートリアルについて:

10 TB のデータがある場合、- (10*1024*1024)/128 = 81,920 マッパー、ほぼ = 82,000

これでいくつかの問題が解決することを願っています。

于 2013-06-11T07:07:45.627 に答える
0

さらに、入力の分割サイズとブロック サイズが常に考慮されるとは限りません。入力ファイルが gzip の場合、分割できません。そのため、gzip ファイルの 1 つが 1500MB の場合、分割されません。Snappy または LZO でブロック圧縮をシーケンス ファイル形式と共に使用することをお勧めします。

また、入力が HBASE テーブルの場合、入力分割サイズは使用されません。HBase テーブルの場合、分割するだけで、テーブルの正しい領域サイズを維持できます。テーブルが適切に分散されていない場合は、手動でテーブルを複数のリージョンに分割します。

于 2013-06-11T00:35:42.193 に答える
0

デフォルトでは、入力ファイルごとに1つのマッパーが生成され、入力ファイルのサイズが分割サイズ（通常はブロックサイズと同じに保たれます）より大きい場合、そのファイルのマッパーの数はファイルサイズ/分割サイズのceilになります。

ここで、5 つの入力ファイルがあり、分割サイズが 64 MB に保たれているとします。

file1 - 10 MB
file2 - 30 MB
file3 - 50 MB
file4 - 100 MB
file5 - 1500 MB

起動されたマッパーの数

file1 - 1
file2 - 1
file3 - 1
file4 - 2
file5 - 24

合計マッパー - 29

于 2013-06-10T07:19:50.650 に答える