shuffle之个人理解

按照我的理解，整个MR任务可以拆解为Map、Shuffle、Reduce三步来执行，当然，Shuffle贯穿于Map与Reduce之间，包括map阶段的shuffle(spill,sort,merge)和reduce阶段的shuffle(copy,sort,merge) 注：现理解为shuffle过程就是map的中间结果如何传递给reduce的过程，一般指reduce阶段的为copy->sort->reduce,不包括map阶段的处理...

首先，map task接受hdfs中的inputsplit，根据mapred.max.split.size和mapred.min.split.size以及dfs.block.size来确定map端输入的split数量（即mapTask数),

经过mapper处理后得到的中间结果集，如果reduceTask数不为1，下面要做的就是判断哪个中间结果发送到哪个reduce task处理，具体算法是key.hashCode()%reduceTasks 将key平均分配到每个reduce task 中去，对中间结果进行partition后会将key,value,partiton的结果序列化成字节数组，并写入内存缓冲区，每个map对应一个内存缓冲区，内存缓冲区的大小有限制，默认一般为100M（通过io.sort.mb设置），当写入到缓冲区的数据大于一定阈值时（通过io.sort.spill.percent设置），默认设置为0.8（80%），就会单独启动一个线程进行spill操作（溢写），将缓冲区的数据写入到本地磁盘上而不影响map结果继续写入到buffer中去，因为还有20%空间可用，在溢写前会对这80%的数据进行sort（如果有partition先按partition信息进行排序，然后按key进行排序）以优化map性能，当全部map task完成后，会存在1个或多个spill文件，在map退出前会进行merge，将多个spill文件合并为1个，这是一个典型的归并排序，因为每个spill文件都是按分区、key进行排序过的，所以merge是一个个分区的key进行归并排序的。

如图：

map阶段结束后，这个中间文件会存放在taskTracker知晓的地方，reduce task会向JobTracker通过RPC请求map task任务是否完成，如果确定job中的第一个map task任务已完成，所有reduce task就会开始尝试从完成的map task中copy 该reduce对应的partition的部分数据（因为一般map阶段会有多个node），对于一个reduce task来说，可以并行从不同已完成的map task中下载数据（通过mapred.reduce.parallel.copies（default5）设置),从map taskcopy的数据同样会先写入内存缓冲区中，这个缓冲区大小跟map阶段的设置不同（mapred.job.shuffle.input.buffer.percent（default0.7）），假设mapred.job.shuffle.input.buffer.percent为0.7，reduce task的maxheapsize为1G，那么用来做下载数据缓存的内存就为大概700MB左右，这700M的内存，跟map端一样，也不是要等到全部写满才会往磁盘刷的，而是当这700M中被使用到了一定的限度（通常是一个百分比），就会开始往磁盘刷。这个限度阈值也是可以通过job参数来设定的，设定参数为：mapred.job.shuffle.merge.percent（default0.66）。如果下载速度很快，很容易就把内存缓存撑大，那么调整一下这个参数有可能会对reduce的性能有所帮助，当该reduce task所需的数据全部copy完毕后，会对写入磁盘的数据进行merge，最后形成一个最终文件，此时就可以开始reduce计算了。

如图:

ReduceTask运行内部原理