MapReduce中的shuffle和排序

MapReduce确保每个reducer的输入都是按键排序的。系统执行排序、将map输出作为输入传给reducer的过程称为shuffle。在此，我们将学习shuffle是如何工作的，因为它有助于我们理解工作机制（如果需要优化MapReduce程序）。shuffle属于不断被优化和改进的代码库的一部分，因此下面的描述有必要隐藏一些细节（也可能随时间而改变，目前是0.20版本）。从许多方面看，shuffle是MapReduce的“心脏”，是奇迹发生的地方。

1、map端

map函数开始产生输出时，并不是简单地将它写到磁盘。这个过程更复杂，它利用缓冲的方式写到内存并出于效率的考虑进行预排序。如下图所示：

每个map任务都有一个环形内存缓冲区用于存储任务输出。在默认情况下，缓冲区的大小为100MB，这个值可以通过改变mapreduce.task.io.sort.mb属性来调整。一旦缓冲内容达到阈值（mapreduce.map.sort.spill.percent，默认为0.80，或80%），一个后台线程便开始把内容溢出（spill）到磁盘。在溢出写到磁盘过程中，map输出继续写到缓冲区，但如果在此期间缓冲区被填满，map会被阻塞直到写磁盘过程完成。溢出写过程按轮询方式将缓冲区中的内容写到mapreduce.cluster.local.dir属性在作业特定子目录下指定的目录中。

在写磁盘前，线程首先根据数据最终要传的reducer把数据划分成相应的分区（partition）。在每个分区中，后台线程按键进行内存中排序，如果有一个combiner函数，它就在排序后的输出上运行。运行combiner函数使得map输出结果更紧凑，因此减少写到磁盘的数据和传递给reducer的数据。

每次内存缓冲区达到溢出阈值，就会新建一个溢出文件（spill file），因此在map任务写完其最后一个输出记录之后，会有几个溢出文件。在任务完成之前，溢出文件被合并成一个已分区且已排序的输出文件。配置属性mapreduce.task.io.sort.factor控制着一次最多能合并多少流，默认值是10。

如果至少存在3个溢出文件（通过mapreduce.map.combine.minspills属性设置）时，则combiner就会在输出文件写到磁盘之前再次运行。前面曾讲过，combiner可以在输入上反复运行，但并不影响最终结果。如果只有1或2个溢出文件，那么由于map输出规模减少，因而不值得调用combiner带来的开销，因此不会为该map输出再次运行combiner。

在将压缩map输出写到磁盘的过程中对它进行压缩往往是个很好的主意，因为这样写磁盘的速度会更快，节约磁盘空间，并且减少传给reducer的数据量。在默认情况下，输出是不压缩的，但只要将mapreduce.map.output.compress设置为true，就可以轻松启用此功能。使用的压缩库由mapreduce.map.output.compress.codec指定。

reduce通过HTTP得到输出文件的分区。用于文件分区的工作线程的数量由任务的mapreduce.shuffle.max.threads属性控制，此设置针对的是每一个节点管理器，而不是针对每个map任务。默认值0将最大线程数设置为机器中处理器数量的两倍。

2、reduce端

现在转到处理过程的reduce部分。map输出文件位于运行map任务的tasktracker的本地磁盘（注意，尽管map输出经常写到map tasktracker的本地磁盘，但reduce输出并不这样），现在，tasktracker需要为分区文件运行reduce任务。并且，reduce任务需要集群上若干map任务的map输出作为其特殊的分区文件。每个map任务的完成时间可能不同，因此在每个任务完成时，reduce任务就开始复制其输出。这就是reduce任务的复制阶段。reduce任务有少量复制线程，因此能够并行取得map输出。默认值是5个线程，但这个默认值可以修改设置mapreduce.reduce.shuffle.parallelcopies属性即可。

reducer如何知道要从哪台机器取得map输出呢？

map任务成功完成后，它们会使用心跳机制通知他们的application master。因此，对于指定作业，application master知道map输出和主机位置之间的映射关系。reducer中一个线程定期询问master以便获取map输出主机的位置，直到获得所有输出位置。

由于第一个reducer可能失败，因此主机并没有在第一个reducer检索到map输出时就立即从磁盘上删除它们。相反，主机会等待，直到application master告知它删除map输出，这是作业完成后执行的。

如果map输出相当小，会被复制到reduce任务JVM的内存（缓冲区大小由mapreduce.reduce.shuffle.input.buffer.percent属性控制，指定用于此用途的堆空间的百分比），否则，map输出会被复制到磁盘。一旦内存缓冲区达到阈值大小（由mapreduce.reduce.shuffle.merge.percent决定）或达到map输出阈值（由mapreduce.reduce.merge.inmem.threshold控制），则合并后溢出写到磁盘中。如果指定combiner，则在合并期间运行它以降低写入硬盘的数据量。

随着磁盘上副本增多，后台进程会将它们合并为更大的、排好序的文件。这会为后面的合并节省一些时间。注意，为了合并，压缩的map输出（通过map任务）都必须在内存中被解压缩。

复制完所有map输出后，reduce任务进入排序阶段（更确切的说法是合并阶段，因为排序是在map端进行的），这个阶段将合并map输出，维持其顺序排序。这是循环进行的。比如，如果有50个map输出，而合并因子是10（10为默认值，由mapreduce.task.io.sort.factor属性设置，与map的合并类似），合并将进行5趟。每趟将10个文件合并成一个文件，因此最后有5个中间文件。

在最后阶段，即reduce阶段，直接把数据输入reduce函数，从而省略了一次磁盘往返行程。最后的合并可以来自内存和磁盘片段。

每趟合并的文件数实际上比上面示例中展示有所不同。目标是合并最小数量的文件以便满足最后一趟的合并系统。因此如果有40个文件，我们不会在四趟中每趟合并10个文件从而得到4个文件。相反，第一趟只合并4个文件，随后的三趟合并完整的10个文件。在最后一趟中，4个已合并的文件和余下的6个（未合并的）文件合计10个文件。该过程如下图所述。

注意，这并没有改变合并次数，它只是一个优化措施，目的是尽量减少写到磁盘的数据量，因为最后一趟总是直接合并到reduce。

在reduce阶段，对已排序输出中的每个键调用reduce函数。此阶段的输出直接写到输出文件系统，一般为HDFS。如果采用HDFS，由于节点管理器也运行数据节点，所以第一个块副本将被写到本地磁盘。

3、配置调优

现在我们已经有比较好的基础来理解如何调优shuffle过程来提高MapReduce性能。以下总结了相关设置和默认值，这些设置以作业为单位（除非有特别说明），默认值适用于常规作业。

map端的调优属性：

属性名称	类型	默认值	说明
mapreduce.task.io.sort.mb	int	100	排序map输出时所使用的内存缓冲区的大小，以兆字节为单位
mpareduce.map.sort.spill.percent	float	0.80	map输出内存缓冲和用来开始磁盘溢出写过程的记录边界索引，这两者使用比例的阈值
mapreduce.task.io.sort.factor	int	10	排序文件时，一次最多合并的流数。这个属性也在reduce中使用。将此值增加到100是很常见的
mapreduce.map.combine.minspills	int	3	运行combiner所需的最少溢出文件数（如果已指定combiner）
mapreduce.map.output.compress	Boolean	false	是否压缩map输出
mapreduce.map.output.compress.codec	Class name	org.apache.hadoop.io.compress.DefaultCodec	用于map输出的压缩编解码器
mapreduce.shuffle.max.threads	int	0	每个节点管理器的工作线程数，用于将map输出到reducer。这是集群范围的设置，不能由单个作业设置。0表示使用Netty默认值，即两倍于可用的处理器数

总的原则是给shuffle过程尽量多提供内存空间。然而，有一个平衡的问题，也就是要确保map函数和reduce函数能得到足够的内存来运行。这就是为什么写map函数和reduce函数时尽量少用内存的原因，它们不应该无限使用内存（例如，应避免在map中堆积数据）。

运行map任务和reduce任务的JVM，其内存大小由mapred.child.java.opts属性设置。任务节点上的内存应该尽可能设置的大些。

在map端，可以通过避免多次溢出写磁盘来获得最佳性能；一次是最佳的情况。如果能估算map输出大小，就可以合理地设置mapreduce.task.io.sort.*属性来尽可能减少溢出写的次数。具体而言，如果可以，就要增加mapreduce.task.io.sort.mb的值。MapReduce计数器（“SPILLED_RECORDS”）计算在作业运行整个阶段中溢出写磁盘的记录数，这对于调优很有帮助。注意，这个计数器包括map和reduce两端的溢出写。

在reduce端，中间数据全部驻留内存时，就能获得最佳性能。在默认情况下，这是不可能发生的，因为所有内存一般都预留给reduce函数。但如果reduce函数的内存需求不大，把mapreduce.reduce.merge.inmem.threshold设置为0，把mapreduce.reduce.input.buffer.percent设置为1.0（或一个更低的值，详见下表）就可以提升性能。

reduce端的调优属性：

属性名称	类型	默认值	说明
mapreduce.reduce.shuffle.parallelcopies	int	5	用于把map输出复制到reducer的线程数
mapreduce.reduce.shuffle.maxfetchfailures	int	10	在声明失败之前，reducer获取一个map输出所花的最大时间
mapreduce.task.io.sort.factor	int	10	排序文件时一次最多合并的流的数量。这个属性也在map端使用
mapreduce.reduce.shuffle.input.buffer.percent	float	0.70	在shuffle的复制阶段，分配给map输出的缓冲区占堆空间的百分比
mapreduce.reduce.shuffle.merge.percent	float	0.66	map输出缓冲区（由mapred.job.shuffle.input.buffer.percent定义）的阈值使用比例，用于启动合并输出和磁盘溢出写的过程
mapreduce.reduce.merge.inmem.threshold	int	100	启动合并输出和磁盘溢出写过程的map输出的阈值数。0或更小的数意味着没有阈值限制，溢出写行为由mapreduce.reduce.shuffle.merge.percent单独控制
mapreduce.reduce.input.buffer.percent	float	0.0	在reduce过程中，在内存中保留map输出的空间占整个堆空间的比例。reduce阶段开始时，内存中的map输出大小不能大于这个值。默认情况下，在reduce任务开始之前，所有map输出都合并到磁盘上，以便为reducer提供尽可能多的内存。然而，如果reducer需要的内存较少，可以增加此值来最小化访问磁盘的次数

2008年4月，Hadoop在通用TB字节排序基准测试中获胜，它使用了一个优化方法，即将中间数据保存在reduce端的内存中。

更常见的情况是，Hadoop使用默认为4KB的缓冲区，这是很低的，因此应该在集群中增加这个值（通过设置io.file.buffer.size）。

完毕。