2

Hadoop を少し異なる方法で使用しています。私の場合、入力サイズは非常に小さいです。ただし、計算時間は長くなります。入力のすべての行で実行する複雑なアルゴリズムがあります。したがって、入力サイズが 5 MB 未満であっても、全体の計算時間は 10 時間以上になります。ここでは Hadoop を使用しています。NLineInputFormat を使用して、ブロック サイズではなく行数でファイルを分割しています。私の最初のテストでは、約 1500 行 (200 行ずつ分割) があり、1 台のマシンでシリアルに実行した場合と比較して、4 ノード クラスターでは 1.5 倍の改善しか見られませんでした。VM を使用しています。それが問題なのか、それとも小さなサイズの入力の場合、hadoop の利点はあまりないのでしょうか? どんな洞察も本当に役に立ちます。

4

2 に答える 2

0

私にとって、あなたのワークロードは SETI@Home のワークロードに似ています。小さなペイロードですが、何時間もの処理時間です。

Hadoop (具体的には HDFS) は、多数の小さなファイル用に設計されていません。しかし、それがMapReduce（あなたが使用している処理フレームワーク）の問題であるとは思えません。

ワークロードをまとめておきたい場合: 1) ファイルがブロックサイズよりも小さい場合、それらを個々のファイル (1 つのワークロード、1 つのファイル) に分割し、1 つのマッパーに移動します。一般的なブロック サイズは 64MB または 128MB です。

2) FileInputFormat のラッパーを作成し、'isSplitable()' メソッドを false にオーバーライドします。これにより、hadoop が行ごとに分割しようとするのではなく、ファイルの内容全体が 1 つのマッパーに供給されるようになります。

参照: http://hadoopilluminated.com/hadoop_book/HDFS_Intro.html

于 2013-03-11T02:59:11.340 に答える
-1

Hadoop は大量の小さなファイルを処理するのが得意ではないため、マッパーの数を減らすために、多数の小さな入力ファイルを少数の大きなファイルに結合することが望まれることがよくあります。

Hadoop MapReduce プロセスへの入力として、 によって抽象化されInputFormatます。FileInputFormatHDFS のファイルを処理するデフォルトの実装です。を使用すると、各ファイルは、通常は上限が で区切られたFileInputFormat1 つ以上に分割されます。これは、入力分割数が入力ファイル数によって下限されることを意味します。これは、多数の小さなファイルを処理するときの MapReduce プロセスにとって理想的な環境ではありません。これは、分散プロセスを調整するオーバーヘッドが、比較的多数の小さなファイルがある場合よりもはるかに大きいためです。InputSplitsblock size

スピット サイズを駆動する基本パラメータはmapred.max.split.sizeです。

このパラメーターを使用CombineFileInputFormatして、マッパーの数を制御できます。

ここで別の答えを得るために私が持っていた実装をチェックアウトしてください。

于 2013-03-11T19:22:26.623 に答える