我在Hadoop中对reduce文件合并过程的理解存在问题，因为它在＆＃34; Hadoop：The Definitive Guide＆＃34; （汤姆怀特）。引用它：
复制完所有地图输出后，reduce任务将进入 排序阶段（应该恰当地称为合并阶段，如 排序是在地图一侧进行的，它合并了地图 输出，保持排序顺序。这是轮次完成的。对于 例如，如果有50个地图输出，并且合并因子是10（ 默认值，由io.sort.factor属性控制，就像在 地图的合并），将有五轮。每轮合并10 文件合为一个，所以最后会有五个中间文件。 而不是最后一轮将这五个文件合并为一个 单个排序文件，合并通过直接馈送保存到磁盘的行程 减少功能在最后阶段：减少阶段。这个 最终合并可以来自内存和磁盘段的混合。
每轮合并的文件数实际上比微妙更精细 这个例子暗示。目标是合并最小数量 文件以获得最后一轮的合并因子。所以，如果有的话 40个文件，合并不会合并四个中的每个文件中的10个文件 轮数来获得4个文件。相反，第一轮只合并4 文件，以及随后的三轮将合并完整的10个文件。 4个合并文件和6个（尚未合并）文件共计 最后一轮的10个文件。该过程如图所示 6-7。请注意，这不会改变轮数;它只是一个 优化以最小化写入磁盘的数据量， 因为最后一轮总是直接合并到reduce。
在第二个例子中（有40个文件）我们真正得到了最后一轮的合并因子。在第5轮10个文件没有写入磁盘，它们直接减少。但在第一个例子中，实际上有6轮，而不是5.在前五轮的每一轮中，10个文件被合并并写在磁盘上，然后在第6轮中我们有5个文件（不是10！）直接减少。为什么？如果坚持＆＃34;目标是合并最小数量的文件以获得最后一轮的合并因子＆＃34;那么对于这50个文件，我们必须在第一轮合并5个文件，然后在随后的4轮中每个合并10个文件，然后我们在最后的第6轮合并因子10。
考虑到，我们每轮不能合并10个以上的文件（对于这两个例子，由io.sort.factor指定）。
在合并了50个文件的第一个示例中，我错误地理解了什么？
答案 0 :(得分：3)
这就是我的理解。如果你仔细阅读，重要的是要记住：
请注意，这不会改变轮数;它只是一种优化，可以最大限度地减少数据量 写入磁盘，因为最后一轮总是直接合并到reduce。
无论是否进行优化，合并轮次数都保持不变（第一种情况下为5次，第二种情况下为4次）。
在这两种情况下，合并轮次数由配置mapreduce.task.io.sort.factor确定，设置为10.
因此合并轮次的数量不会改变（优化是否完成）。但是，每轮合并的文件数量可能会发生变化（因为Hadoop框架可能会引入一些优化来减少合并次数，从而将数量泄漏到磁盘上）。
所以，在第一种情况下，没有优化， 50个文件的内容（合并到最终的5个文件中）溢出到磁盘并从磁盘读取这些文件，在“减少”阶段。
在第二种情况下，通过优化，将34个文件的内容（合并到最终的4个文件中）溢出到磁盘，并从磁盘读取这些文件，并直接读取剩余的6个未合并文件在“减少”阶段，内存缓冲区。
优化的想法是尽量减少合并和泄漏。