11

3 桁の GB または 1 桁または 2 桁の TB の大きさのデータ セットがあります。したがって、入力ファイルはファイルのリストであり、それぞれのサイズは 10GB 程度です。私の Hadoop での map reduce ジョブは、これらすべてのファイルを処理し、1 つの出力ファイル (集約された情報を含む) のみを提供します。

私の質問は次のとおりです。

  1. Hadoop/mapreduce フレームワークを Apache からチューニングするための適切なファイル サイズはどれくらいですか? 小さいファイルサイズよりも大きいファイルサイズの方が好まれると聞きました。アイデアはありますか？私が確かに知っている唯一のことは、hadoop がデフォルトでそれぞれ 64MB のブロックを読み取るということです。したがって、ファイル サイズが 64 MB の乗数のようなものであるとよいでしょう。

  2. 現時点では、アプリケーションは出力ファイルを 1 つのファイルにのみ書き込んでいます。ファイルサイズはもちろん3桁のギガビットです。ファイルをどれだけ効率的に分割できるか疑問に思っています。もちろん、この仕事をするためにいくつかの UNIX ツールを使用することもできます。しかし、hadoop で直接これを行う方が好ましいのでしょうか?

コメントありがとうございます！

PS: ファイルを圧縮していません。入力ファイルのファイル形式は text/csv です。

4

3 に答える 3

7

ファイルを圧縮していない場合、hadoop はファイルのブロック サイズに関連する多数のマッパーを使用して、大きなファイル (たとえば 10G) を処理します。

ブロック サイズが 64M だとすると、この 10G ファイル (160*64 ~= 10G) を処理するマッパーが最大 160 になります。マッパー ロジックの CPU 集中度によっては、これが許容可能なブロック サイズである可能性がありますが、マッパーが 1 分未満の時間で実行されていることがわかった場合は、各マッパーが実行する作業を増やしたい場合があります (ブロック サイズを大きくすることによって)。 128、256、512m - 実際のサイズは、データの処理方法によって異なります)。

ブロック サイズを大きくすると、10G ファイルの処理に使用されるマッパーの数が減ります。もちろん、TextInputFormat で使用される最小分割サイズを大きくすることはできますが、マッパーが 2 つ以上のブロックを処理している可能性があり、そのすべてがそのノードにローカルに存在するとは限らないため、おそらくデータ ローカリティが低くなります。

出力に関しては、これも処理ロジックが何をしているかに依存します。より多くのレデューサーを導入するだけで分割できますか? これにより、より多くの出力ファイルが作成されますが、これらのファイルに必要なパーティション分割ロジックは何ですか (デフォルトでは、キーによってハッシュ分割されます)

于 2012-06-13T13:07:36.973 に答える
5

入力ファイルのサイズ:

これを調整する 1 つの方法は、マップ タスクの完了速度を確認することです。各マップ タスクは入力として 1 つのファイルを受け取り、30 ～ 40 秒未満で完了する場合は、各マッパーがより多くの作業を行えるように、各ファイルのサイズを大きくすることを検討する必要があります。これは、マップ タスクが実際の作業を行う前に、初期化に約 30 秒かかるためです。

また、クラスターが一度に実行できるマップ タスクの数にも依存します。できるだけ多くのマップ タスクを利用できるように、ファイルとブロックのサイズを調整してみてください。その他のアイデアについては、次のブログ投稿を参照してください: http://www.cloudera.com/blog/2009/12/7-tips-for-improving-mapreduce-performance/

出力ファイルのサイズ:

これを行う簡単な方法は、複数のレデューサーを指定することです (各レデューサーは単一の出力ファイルを生成します)。結果を何らかのキー (年月など) で分割したい場合は、マップ タスクの出力キーにそれを含めることができ、それらは同じリデューサーに並べ替えられます。次に、各ファイルをチェックして、ファイルに含まれる年月キーを確認するだけです。

圧縮：

ファイルの圧縮を検討することをお勧めします。これを行うと、入力ファイルが「大きく」なります。これは、1 つのマップ タスクを操作するためのより多くのデータが各ファイルに含まれるためです。また、クラスターで使用するディスクの量も削減されます。どちらかといえば、ファイルの読み取りと移動によって発生するディスク I/O とネットワーク トラフィックが少なくなるため、クラスターでの mapreduce のパフォーマンスも向上する可能性があります。

また、map タスクの中間出力 (reducer に送られる前の map タスクからの出力) を圧縮します。同様の方法でパフォーマンスが向上します。これは、設定によって行われますmapred.compress.map.output=true。

于 2012-06-13T13:11:00.417 に答える
3

Hadoop は、入力分割サイズに基づいて作業を分割します。合計データ サイズを分割サイズで割ると、発生するマップ ジョブの数が決まります。一般的なコンセンサスは、マシンごとに 10 ～ 100 のマップが必要だということです。http://hadoop.apache.org/common/docs/r0.18.3/mapred_tutorial.htmlから

マップの数は通常、入力の合計サイズ、つまり入力ファイルのブロックの合計数によって決まります。マップの並列処理の適切なレベルは、ノードあたり約 10 ～ 100 マップのようですが、非常に CPU 負荷の低いマップ タスクでは最大 300 マップに設定されています。タスクのセットアップには時間がかかるため、マップの実行に少なくとも 1 分かかる場合に最適です。

一部の入力フォーマットでは、分割サイズを設定できます。デフォルトでは、ほとんど (TextInputFormat を含む) がブロックごとに 1 つのマップを作成します。そのため、いくつかの異なるファイルがある場合、マップの無駄である不完全な 64 MB ブロックがさらに増えることになります。

1 つの巨大なファイルを処理する方が、複数のファイルを処理するよりもはるかに効率的です。複数のファイルを考慮する必要がある場合、ジョブのセットアップに時間がかかります。Hadoop の中核は、少数の大きなファイルに集中していました。また、HDFS は少数の大きなファイルを処理するように設定されており、ファイルが多いほど、それらを追跡するために namenode が消費する RAM が増えます。

于 2012-06-13T13:05:44.133 に答える