我使用的是一种自定义输出格式,每个Map器每个键输出一个新的序列文件,所以最终会得到这样的结果。。
输入
Key1 Value
Key2 Value
Key1 Value
文件夹
/path/to/output/Key1/part-00000
/path/to/output/Key2/part-00000
我注意到一个巨大的性能冲击,它通常需要10分钟左右简单地Map输入数据,然而两个小时后Map程序甚至还没有完成一半。尽管他们正在输出行。我预计唯一键的数量大约是输入行数量的一半,大约200000。
有没有人做过这样的事,或者可以提出任何有助于表演的建议?我希望在hadoop中尽可能地保留这个密钥分割过程。
谢谢!
2条答案
按热度按时间svdrlsy41#
我认为你应该重新审视你的设计。我不相信hdfs的规模远远超过1000万个文件。我建议阅读更多关于hadoop、hdfs和map/reduce的内容。一个好的开始是http://www.cloudera.com/blog/2009/02/the-small-files-problem/.
祝你好运!
编辑8/26:根据@davidgruzman的评论,我深入研究了这个问题。实际上,存储大量小文件的代价只是namenode。数据节点没有额外的空间损失。我删除了我答案中不正确的部分。
lskq00tm2#
听起来,向某个键值存储进行输出可能会有很大帮助。
例如,hbase可能适合您的需要,因为它针对大量写操作进行了优化,您将重用hadoop基础结构的一部分。现有的输出格式可直接写入hbase:http://hbase.apache.org/apidocs/org/apache/hadoop/hbase/mapreduce/tableoutputformat.html