在reduce端理解Hadoop中的merge

Question

我对 Hadoop 中 reduce 端的文件合并过程的理解存在问题，正如“Hadoop：权威指南”(Tom White) 中所述。引用它：

当所有的 map 输出都被复制后，reduce 任务进入 排序阶段（应该正确地称为合并阶段，如 排序是在地图端进行的），它合并了地图 输出，保持它们的排序顺序。这是轮流进行的。为了 例如，如果有 50 个地图输出并且合并因子为 10（ 默认值，由 io.sort.factor 属性控制，就像在 地图的合并），将有五轮。每轮将合并 10 文件合二为一，所以最后会有五个中间文件。 而不是最后一轮将这五个文件合并成一个 单个排序文件，合并通过直接馈送节省了一次磁盘之旅 最后一个阶段的reduce函数：reduce阶段。这个 最终合并可以来自内存和磁盘段的混合。

每一轮合并的文件数量实际上比 这个例子表明。目标是合并最小数量的 文件以获取最后一轮的合并因子。所以如果有 40 个文件，合并不会合并四个文件中的每一个中的 10 个文件 回合获得4个文件。相反，第一轮只会合并 4 文件，随后的三轮将合并完整的 10 个文件。 4 个合并的文件和 6 个（尚未合并的）文件总共 10个文件为最后一轮。该过程如图所示 6-7。请注意，这不会改变轮数；这只是一个 优化以最小化写入磁盘的数据量， 因为最后一轮总是直接合并到reduce中。

在第二个示例（有 40 个文件）中，我们真正得到了最后一轮的合并因子。在第 5 轮中，10 个文件没有写入磁盘，它们直接去减少。但是在第一个示例中，确实有 6 轮，而不是 5 轮。在前五轮中，每轮有 10 个文件被合并并写入磁盘，然后在第 6 轮中，我们有 5 个文件（不是 10 个！）直接去 reduce。为什么？如果坚持“目标是合并最少数量的文件以达到最后一轮的合并因子”，那么对于这 50 个文件，我们必须在第一轮合并 5 个文件，然后在随后的 4 轮中分别合并 10 个文件，然后然后我们在最后的第 6 轮中获得 10 的合并因子。

考虑到，我们不能在每轮中合并超过 10 个文件（这两个示例都由 io.sort.factor 指定）。

在第一个合并 50 个文件的示例中，我对什么理解有误？

Answer 1

这是我的理解。如果你仔细阅读，要记住的重要一点是：

请注意，这不会改变轮数；这只是一种优化，以最大限度地减少数据量 写入磁盘，因为最后一轮总是直接合并到 reduce 中。

无论是否优化，合并轮数保持不变（第一种情况为 5，第二种情况为 4）。

• 第一种情况：50 个文件合并到最后的 5 个文件中，然后直接送入“减少”阶段（总轮数为 5 + 1 = 6）
• 第二种情况：34 个文件合并到最后的 4 个文件中，其余 6 个文件直接从内存中读取并送入“减少”阶段（总轮数为 4 + 1 = 5）

在这两种情况下，合并轮数由配置mapreduce.task.io.sort.factor 确定，该配置设置为 10。

所以合并轮数不会改变（无论优化是否完成）。但是，每轮合并的文件数量可能会发生变化（因为 Hadoop 框架可以引入一些优化来减少合并次数，从而减少溢出到磁盘的数量）。

所以，在第一种情况下，没有优化，50个文件的内容（合并为最后5个文件）溢出到磁盘，这些文件从磁盘中读取 strong>，在“减少”阶段。

第二种情况，经过优化，将34个文件（合并为最后4个文件）的内容溢出到磁盘，这些文件从磁盘中读取，其余6个未合并的文件直接从磁盘中读取内存缓冲区，在“减少”阶段。

优化的思想是尽量减少合并和溢出。