Performance Hadoop中大量多输出文件的性能

我使用的是一种自定义输出格式，它会根据映射器的每个键输出一个新的序列文件，因此最终会得到如下结果

输入

Key1     Value
Key2     Value
Key1     Value

文件

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

我注意到一个巨大的性能打击，它通常需要大约10分钟来简单地映射输入数据，但两个小时后，映射程序甚至还没有完成一半。虽然他们正在输出行。我预计唯一键的数量大约是输入行数量的一半，大约200000

有没有人做过类似的事情，或者可以提出任何可能有助于表演的建议？我希望尽可能在hadoop中保持这个密钥分割过程

---

谢谢

我认为你应该重新审视你的设计。我不相信HDFS可以扩展超过10万个文件。我建议阅读更多关于Hadoop、HDFS和Map/Reduce的内容。一个好的起点是

祝你好运

---

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

听起来向某个键值存储输出可能会有很大帮助
例如，HBASE可能适合您的需要，因为它针对大量写操作进行了优化，并且您将重用hadoop基础设施的一部分。

---

存在可直接写入HBase的现有输出格式：

我是否正确理解您的文件平均包含两行？为什么要将输出拆分为成吨的小文件？这将扼杀Hadoop集群的性能。当您拥有的文件数量与群集支持的还原器数量相同时，以及当这些文件大小相同时，您可以获得最佳性能。我希望为我拥有的每种类型的数据都有一个输出文件，例如，它可以是访问日志，我希望将每个ip地址的访问数据作为一个单独的文件，用作与hadoop无关的内容的输入。如果您处理的是200K或400K行，我相信在独立计算机上可以比在hadoop群集上获得更好的性能。例如，在生产中，我们将输出800-1500万个不同的文件位置。我刚刚开始看到性能问题，甚至是200000个，所以几乎可以肯定，它不会处理任何超过这个数字的问题。我支持这一点，Hadoop不能处理大量的小文件。您可以通过在将所有文件导入HDFS时将其连接起来，然后将MR作业写入较少的文件，从而绕过此限制。然后，您可以将此输出Sqoop到关系数据库以进行非Hadoop访问，或者使用诸如Hive或HBase之类的工具直接查询到HDFS。感谢您的反馈，我已经阅读了这篇文章，希望我可以通过Hadoop压缩这部分数据处理，尽管它显然不是为此而设计的。再次感谢！对于小文件，没有空间限制。数据节点只存储我们确实拥有的数据。唯一的成功是NameNode内存占用