Shuffle和排序
MapReduce确保每个reducer的输入都按键排序。系统执行排序的过程——将map输出作为输入传给reducer——称为shuffle。shuffle属于不断被优化和改进的代码库的一部分，从许多方面来看，shuffle是MapReduce的“心脏”，是奇迹发生的地方。事实上，shuffle这个说法并不准确。因为在某些语境中，它只代表reduce任务获取map输出的这部分过程。在这里，我们将其理解为从map产生输出到reduce的消化输入的整个过程。
map端：
map函数开始产生输出时，并不是简单地将它写到磁盘。这个过程更复杂，它利用缓冲的方式写到内存缓冲区，并出于效率的考虑进行预排序(步骤1)。map的输出结果是由collector处理的，所以map端的shuffle过程包含在collect函数对map输出结果的处理过程中。
每个map任务都有一个环形内存缓冲区，用于存储任务的输出，默认情况下，缓冲区的大小为100MB，此值可以通过改变io.sort.mb属性来调整。一旦缓冲内容达到阀值(io.sort.spill.percent，默认为0.80，或80%)，一个后台线程便开始把内容溢写(spill)到磁盘中。在写磁盘过程中，map输出继续被写到缓冲区，但如果在此期间缓冲区被填满，map会阻塞直到写磁盘过程完成。
final int kvnext = (kvindex + 1) % kvoffsets.length;
do{ //在环形缓冲区中，如果下一个空闲位置同起始位置相等，那么缓冲区已满 kvfull = kvnext ==kvstart; //环形缓冲区的内容是否达到写出的阀值 final Boolean kvsoftlimit = ((kvnext > kvend ) ? kvnext – kvend > softRecordLimit : kvend – kvnext <= kvoffsets.length – softRecordLimit ); //达到阀值，写出缓冲区内容，形成spill文件 if(kvstart == kvend && kvsoftlimit ){ startspill(); } //如果缓冲区满，则map任务等待写出过程结束 if( kvfull ){ while ( kvstart != kvend ){ reporter.progress(); spillDone.await(); } } }
写磁盘将按轮询方式写到mapred.local.dir属性指定的作业特定子目录中的目录中。
在collect函数中将缓冲区中的内容写出前会调用sortAndSpill函数。sortAndSpill函数每被调用一次就会创建一个spill文件（步骤2），然后按照key值对需要写出的数据进行排序（步骤3），如果有多个reduce任务，则每个map任务都会对其输出进行分区(partition)，即为每个reduce任务建立一个分区。每个分区有许多键(及其对应值)，但每个键对应的键/值对记录都在同一分区中。分区由用户定义的分区函数控制，但通常用默认的分区器(partitioner，有时也被叫做分区函数)通过哈希函数来分区，按照划分的顺序将所有需要写出的结果溢写到这个spill中（步骤4或步骤5）。
如果用户作业配置了combiner类，那么在写出过程中会先调用combineAndSpill()再写出，对结果进行进一步的合并(combine)是为了让map的输出数据更加紧凑（步骤4）。
但是并不是所有的项目都可以添加combiner函数。例如，计算气温的最大值，max(0,20,10,25,15) = max(max(0,20,10),max(25,15)) = max(20,25) = 25,这是没有问题的，但是计算气温的平均值就不行了。mean(0,20,10,25,15) = 14,
而combiner不能取代reduce函数：
mean(mean(0,20,10),mean(25,15)) = mean(10,20) = 15
为什么呢？我们仍然需要reduce函数来处理不同map输出中具有相同键的记录。但是combiner能有效减少map和reduce之间的数据传输量，在MapReduce作业中使用combiner是需要慎重考虑的。
sortAndSpill函数的执行过程可以参考下面sortAndSpill函数的代码。
//创建spill文件 Path filename = mapOutputFile.getSpillFileForWrite(getTaskID() , numSpills , size ); out = rfs.create(filename); ……. //按照key值对待写出的数据进行排序 sorter.sort( MapOutputBuffer.this , kvstart , endPosition , reporter ); …….. //按照划分将数据写入文件 for ( int i = 0 ; i < partitions ; ++ i ){ IFile.Writer< K , V > writer = null ; long segmentStart = out.getPos(); writer = new Writer< K , V >(job , out , keyClass , valClass , codec ); //如果没有没有配置combiner类，数据直接写入文件 if( null == combinerClass ){ ……. } else{ …….. //如果配置了combiner类，先调用combineAdnSpill函数后再写入文件 combineAndSpill( kvIter , combineInputCounter ); } }
这里需要注意的是，combine函数要做的一般就是reducer要做的事，先处理部分数据，再在reducer中集中处理所有的数据，这样传输给reducer的数据会减少，reducer要做的工作量也会减少。其实这里面还有一个集聚的过程，这个过程不是combine，是系统默认进行的，它会将map的输出中相同的key的value聚集成value-list（这里的聚集通过实验发现，map输出到内存缓冲区，经过sort，partition过程形成排好序的列表，但是key和value还是一样的，只是顺序改变了而已，即使有了combine，combine也是执行reduce函数的动作（这里要看combine的class设置成什么，如果是job.setCombinerClass(Reduce.class)，combine则执行reduce函数的动作，而数据在输入给combine之前没有进行聚集，所以我认为聚集的过程是在溢写到磁盘文件中进行的，或者在磁盘中的多个splil文件进行merge合并的时候进行的。）。
显然，直接将每个map生成的众多spill文件（因为map过程中，每一次缓冲区写出都会产生一个spill文件）交给reduce处理不现实。所以在每个map任务结束之后在map的TaskTracker上还会执行合并操作(merge)（步骤6），这个操作的主要目的是将map生成的众多spill文件中的数据按照划分重新组织，以便于reduce处理。主要做法是针对指定的分区，从各个spill文件中拿出属于同一个分区的所有数据，然后将它们合并在一起，并写入一个已分区且已排序的map输出文件中。最后每个map只生成一个输出文件。
待唯一的已分区且已排序的map输出文件写入最后一条记录后，map端的shuffle阶段就结束了。下面就进入reduce端的shuffle阶段。
reduce端：
在reduce端，shuffle阶段可以分成三个阶段：复制map输出、排序合并、reduce处理。
map输出文件位于运行map任务的TaskTracker的本地磁盘(注意，尽管map输出经常写到map TaskTracker的本地磁盘，但reduce输出并不这样)，现在，TaskTtracker需要为分区文件运行reduce任务。更进一步，reduce任务需要集群上若干个map任务的map输出作为其特殊的分区文件。每个map任务的完成时间可能不同，因此只要有一个任务完成，reduce任务就开始复制其输出。也就是reduce任务的复制阶段（步骤7）。reduce任务有少量复制线程，因此能够并行取得map输出，默认值是5个线程。
reducer如何知道要从哪个TaskTracker取得map输出呢？map任务成功完成后，它们会通知其父TaskTracker状态已更新，然后TaskTracker进而通知JobTracker。这些通知在心跳通信机制中传输。因此，对于指定作业，JobTracker知道map输出和TaskTracker之间的映射关系。reducer中的一个线程定期询问JobTracker以便获取map输出的位置，直到它获得所有输出位置。
由于reducer可能失败，因此TaskTracker并没有在第一个reducer检索到map输出时就立即从磁盘上删除它们。相反，TaskTracker会等待，直到JobTracker告知它们可以删除map输出，这是作业完成后执行的。
如果map输出相当小，则会被复制到执行reduce任务的TaskTracker节点的内存中，以便进一步的处理，否则输出被复制到磁盘中。
一旦内存缓冲区达到阀值大小或达到map输出阀值，则合并后溢出写到磁盘中。随着磁盘上副本的增多，后台线程会将这些从各个map TaskTracker上复制的map输出文件(无论在内存还是在磁盘上)进行整合，合并为更大的、排好序的文件，并维持数据原来的顺序（步骤8）。这会为后面的合并节省一些时间。注意，为了合并，压缩的map输出(通过map任务)都必须在内存中被解压缩。
reduce端的最后阶段就是对合并的文件进行reduce处理。reduce TaskTracker从合并的文件中按照顺序先拿出一条数据，交给reduce函数处理，然后直接将结果输出到本地的HDFS上(因为在Hadoop集群上，TaskTracker节点一般也是DataNode节点)，接着继续拿出下一条数据，再进行处理。下面是reduce Task上run函数的部分代码，从这个函数可以看出整个reduce端的三个步骤。
//复制阶段，从map TaskTracker出获取map输出 boolean isLocal = “local”.equals(job.get(“mapred.job.tracker”,”local”)); if( !isLocal ){ reduceCopier = new ReduceCopier(umbilical , job ); if ( ! reduceCopier.fetchOutpus() ){ ………. } } //复制阶段结束 copyPhase.complete(); //合并阶段，将得到的map输出合并 setPhase(TaskStatus.Phase.SORT); ………. //合并阶段结束 sortPhase.complete(); //reduce阶段 setPhase(TaskStatus.Phase.REDUCE); … …. Reducer reducer = ReflectionUtils.newInstance(job.getReducerClass() , job); … … //逐个读出每一条记录，然后调用Reducer的reduce函数 while ( values.more() ){ reduceInputKeyCounter.increment(1); reducer.reduce(values,getKey() , values , collector , reporter); values.nextKey(); values.informReduceProgress(); } values.informReduceProgress(); } reducer.close(); out.close(reporter); done(umbilical); }
