4

我正在使用自定义输出格式，每个键的每个映射器输出一个新的序列文件，所以你最终会得到这样的东西..

输入

Key1     Value
Key2     Value
Key1     Value

文件

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

我注意到一个巨大的性能损失，通常需要大约 10 分钟来简单地映射输入数据，但是在两个小时之后，映射器甚至还没有完成一半。尽管他们正在输出行。我预计唯一键的数量大约是输入行数的一半，大约 200,000。

有没有人做过这样的事情，或者可以提出任何可能有助于表现的事情？我想将这个密钥拆分过程保留在可能的 hadoop 中。

谢谢！

4

2 回答 2

2

我相信你应该重新审视你的设计。我不相信 HDFS 可以扩展到超过 10M 的文件。我建议阅读更多关于 Hadoop、HDFS 和 Map/Reduce 的内容。一个好的起点是http://www.cloudera.com/blog/2009/02/the-small-files-problem/。

祝你好运！

编辑 8/26：根据@David Gruzman 的评论，我更深入地研究了这个问题。事实上，存储大量小文件的惩罚只针对 NameNode。数据节点没有额外的空间损失。我删除了答案的不正确部分。

于 2012-08-23T17:25:53.717 回答
1

听起来像输出到一些键值存储可能会有很大帮助。
例如，HBASE 可能适合您的需求，因为它针对大量写入进行了优化，并且您将重用部分 hadoop 基础架构。现有的输出格式可以写入 HBase：http ://hbase.apache.org/apidocs/org/apache/hadoop/hbase/mapreduce/TableOutputFormat.html

于 2012-08-26T14:02:14.093 回答