我在Hadoop中减少文件合并过程的理解方面存在问题,如“Hadoop:权威指南”(Tom White)中所述。引用它:了解在Hadoop中减少合并
当所有的地图输出已被复制,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!),直接减少。为什么?如果要坚持“目标是合并最小数量的文件以达到最后一轮的合并因子”,那么对于这50个文件,我们必须在第一轮中合并5个文件,然后在随后的4轮中合并10个文件,并且那么我们会在最后的第6轮中合并10个因子。考虑到我们不能在每一轮中合并超过10个文件(这两个例子都是由io.sort.factor指定的)。
我在第一个例子中错误地理解了50个文件的合并?