4

キーごとにマッパーごとに新しいシーケンス ファイルを出力するカスタム出力形式を使用しているので、このような結果になります。

入力

Key1     Value
Key2     Value
Key1     Value

ファイル

/path/to/output/Key1/part-00000
/path/to/output/Key2/part-00000

パフォーマンスが大幅に低下していることに気付きました。通常、入力データを単純にマッピングするのに約 10 分かかりますが、2 時間後にはマッパーは半分も完成していませんでした。行を出力していましたが。一意のキーの数は、入力行数の約半分、約 200,000 になると予想しています。

誰かがこのようなことをしたことがありますか、またはパフォーマンスに役立つ可能性のある何かを提案できますか? このキー分割プロセスを可能な限り Hadoop 内に保ちたいと思います。

ありがとう！

4

2 に答える 2

2

設計を再検討する必要があると思います。HDFS が 1,000 万ファイルを超えて拡張できるとは思えません。Hadoop、HDFS、および Map/Reduce について詳しく読むことをお勧めします。http://www.cloudera.com/blog/2009/02/the-small-files-problem/から始めるのがよいでしょう。

幸運を！

EDIT 8/26: @David Gruzman のコメントに基づいて、この問題を詳しく調べました。確かに、多数の小さなファイルを保存することによるペナルティは、NameNode だけです。データ ノードに追加のスペース ペナルティはありません。回答の間違った部分を削除しました。

于 2012-08-23T17:25:53.717 に答える
1

Key-Value ストアへの出力を作成すると、大いに役立つようです。
たとえば、HBASE は多数の書き込み用に最適化されているため、ニーズに合っている可能性があり、Hadoop インフラストラクチャの一部を再利用します。HBase に書き込む既存の出力形式があります: http://hbase.apache.org/apidocs/org/apache/hadoop/hbase/mapreduce/TableOutputFormat.html

于 2012-08-26T14:02:14.093 に答える