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