Hadoop 中大量多个输出文件的性能答案

【问题标题】：Performance with a large number of multiple output files in HadoopHadoop 中大量多个输出文件的性能
【发布时间】：2012-08-23 14:26:27
【问题描述】：

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

输入

Key1     Value
Key2     Value
Key1     Value

文件

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

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

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

谢谢！

【问题讨论】：

我是否正确理解您的文件平均包含 2 行？为什么要将输出拆分为大量小文件？这会扼杀 Hadoop 集群的性能。当您的文件数量与集群支持的 reducer 数量一样多并且这些文件的大小大致相同时，您可以获得最佳性能。
我想为我拥有的每种类型的数据都有一个输出文件，例如它可以是访问日志，我希望将每个 IP 地址的访问数据作为一个单独的文件使用作为非 Hadoop 相关内容的输入。
如果您要处理 200K 或 400K 行，我相信您在独立计算机上可以获得比在 Hadoop 集群上更好的性能。
嗯，这是一个例子，在生产中我们将输出 8-15 百万个不同的文件位置。我刚开始看到甚至 200,000 的性能问题，因此几乎可以肯定它无法应对任何大于此的数字。

【解决方案1】：

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

祝你好运！

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

【讨论】：

我支持这一点，Hadoop 不能很好地处理大量小文件。您可以通过在将所有文件导入 HDFS 时连接所有文件，然后将 MR 作业写入较少数量的文件来规避此限制。然后，您可以将此输出 Sqoop 到关系数据库以进行非 Hadoop 访问，或者使用 Hive 或 HBase 之类的东西直接查询 HDFS。
感谢您的反馈，我已经阅读了那篇文章，只是有点希望我可以通过 hadoop 压缩这部分数据处理，尽管它显然不是为此而设计的。再次感谢！
小文件没有空间损失。数据节点仅存储我们确实拥有的数据。唯一的打击是 NameNode 内存占用

【解决方案2】：

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

【讨论】：