mapreduce 作业中的中间键值对mapred.local.dir在被打乱到将运行reduce 任务的tasktracker 节点之前被写入。
我知道HFDS 已针对写入大块数据进行了优化，因此与常规文件系统相比，可以最大限度地减少硬盘的寻道时间。
现在我很好奇 hadoop 是否也针对将中间 kev-value 对流式传输到本地文件系统进行了优化？
我问这个是因为我的应用程序的输入数据很少，但有大量的中间数据和中等大小的输出数据。hadoop 在我的情况下是有益的还是我应该考虑使用不同的框架？（请注意，我的软件与 WordCount 密切相关，但我发出的是所有子字符串而不是所有单词）
非常感谢您的帮助！
编辑：我重新表述了这个问题，因为乍一看，我给人的印象是中间 kv 对被发送到 HDFS，它们被发送到 tasktracker 节点的本地文件系统！
HDFS 是否针对中间数据进行了优化？
就像@Tariq 提到的，HDFS 不用于中间数据（尽管有些人已经成功地探索了这个想法）。
所以，让我重新表述你的问题：
Hadoop是否针对中间数据进行了优化？
是的，有一些优化（例如，参见MAPREDUCE-3289 JIRA）。
即使有了这些优化，重洗牌的作业在这个阶段也会遇到瓶颈。调整配置参数（如mapreduce.reduce.shuffle.input.buffer.percent）可以在一定程度上帮助缓解这个问题。使用组合器（如@Tariq 建议的那样）也是一个好主意。
hadoop 在我的情况下是有益的还是我应该考虑使用不同的框架？
是的，Hadoop 在您的情况下仍然有用（假设您没有在单节点模式下运行）。您可以更好地编写针对您的特定用例优化的自己的代码，但这将是太多的工作（您必须自己处理故障等）来证明这样做是合理的（在大多数情况下）。
中间输出存储在本地 FS而不是 HDFS 上。因此，优化 HDFS 的程度并不重要。但是，如果您想分散磁盘 i/o 以提高效率，您可以使用不同设备上以逗号分隔的目录列表作为mapred.local.dir属性的值。这将分散负载，从而提高性能。
你也可以使用组合器来让事情变得更好。