对Hadoop在约简端合并的理解
我在理解Hadoop中减少端的文件合并过程方面有问题，正如在"Hadoop:权威指南“( The )中描述的那样。引用如下：
当所有映射输出都已被复制时，减少任务将进入排序阶段(由于排序是在映射端执行的，因此应该正确地称为合并阶段)，该阶段合并映射输出，保持它们的排序顺序。这是分回合完成的。例如，如果有50个映射输出，合并因子为10 (默认情况下，由io.sort.factor属性控制，就像在映射的合并中一样)，那么将有五轮。每一轮将10个文件合并为一个，因此在结束时将有5个中间文件。与其进行最后一轮合并，将这五个文件合并到一个排序文件中，不如通过在最后一个阶段--减少阶段--直接输入还原函数来保存到磁盘的旅程。这个最终的合并可以来自内存和磁盘段的混合. 在每一轮合并的文件数量实际上比这个例子所显示的更微妙。目标是将最小文件数合并到最后一轮的合并因子。因此，如果有40个文件，合并将不会在每轮合并10个文件，以获得4个文件。相反，第一轮将只合并4个文件，随后的三轮将合并完整的10个文件。这4个合并的文件和6个(尚未合并的)文件为最后一轮总共10个文件。这个过程如图6-7所示.请注意，这不会改变回合的数量；这只是一个优化，以最小化写入磁盘的数据量，因为最后一轮总是直接合并到减缩中。
在第二个例子(有40个文件)中，我们真正得到了最后一轮的合并因子。在第5轮中，10个文件没有写入磁盘，它们直接去减少。但在第一个例子中，实际上有6轮，而不是5轮。在前5轮中，每一轮10个文件被合并并写入磁盘，然后在第6轮中我们有5个文件(不是10个！)直接减少。为什么？如果要坚持“目标是合并最小数量的文件以达到最后一轮的合并因子”，那么对于这50个文件，我们必须在第一轮合并5个文件，然后在随后的4个回合中每个合并10个文件，然后在最后第6轮中合并因子为10。
考虑到，我们不能在每一轮合并超过10个文件(这两个例子都由io.sort.factor指定)。
在第一个合并了50个文件的示例中，我错误地理解了什么？
回答 1
Stack Overflow用户
发布于 2015-12-16 17:29:20
这就是我所理解的。如果你仔细阅读，重要的是要记住：
请注意，这不会改变轮数；这只是将写入磁盘的数据量最小化的一种优化，因为最后一轮总是直接合并到减缩中。
不管有没有优化，合并轮的数量都是相同的(第一种情况是5次，第二种情况是4次)。
- 第一种情况:将50个文件合并到最后的5个文件中，然后直接输入到“减少”阶段(总回合为5+1= 6)
- 第二种情况:将34个文件合并到最后4个文件中，其余6个文件直接从内存中读取并输入到“减少”阶段(总计4+1= 5)。
在这两种情况下，合并轮的数量都由设置为10的配置mapreduce.task.io.sort.factor确定。
因此合并轮的数量不会改变(不管是否进行了优化)。但是，每一轮合并的文件数量可能会发生变化(因为Hadoop框架可以引入一些优化，以减少合并的数量，从而减少溢出到磁盘的数量)。
因此，在第一种情况下，没有优化的，50个文件的内容(合并到最终的5个文件)溢出到磁盘中，这些文件在“减少”阶段从磁盘中读取。
在第二种情况下，优化的将34个文件(合并为最后4个文件)的内容溢出到磁盘中，这些文件从磁盘中读取，其余6个未合并的文件在“还原”阶段直接从内存缓冲区读取。
优化的思想是将合并和溢出最小化。
https://stackoverflow.com/questions/26015678
复制相似问题
腾讯云开发者
