MapReduce的shuffle源码剖析（设置Combiner）

本文为了全面源码级剖析MapReduceshuffle过程，设置了Combiner并进行了剖析，对于没有设置Combiner的shuffle，只需要将Combiner部分忽略即可。

 

0、前言    

    shuffle是MapReduce的重要部分，横跨map与reduce两端，是指从Mapper函数输出到Reducer函数输入的这段过程，属于本地（节点内）聚合操作，实现逻辑与reducer相同。目的是为了将Mapper的输出更快更好地传到Reducer。由于Reduce的数量可能不止一个，因此 Mapper的输出需要均匀分到reducer函数中，所以采用HashCode分区，打乱Key的原始顺序，因此得名为shuffle（洗牌）。

 

    在Hadoop这样的集群环境中，大部分map task与reduce task的执行是在不同的节点上。当然很多情况下Reduce执行时需要跨节点去拉取其它节点上的map task结果。如果集群正在运行的job有很多，那么task的正常执行对集群内部的网络资源消耗会很严重。这种网络消耗是正常的，我们不能限制，能做的就是最大化地减少不必要的消耗。还有在节点内，相比于内存，磁盘IO对job完成时间的影响也是可观的。从最基本的要求来说，我们对Shuffle过程的期望可以有： 

1）完整地从map task端拉取数据到reduce 端。

2）在跨节点拉取数据时，尽可能地减少对带宽的不必要消耗（网络IO）。

3）减少磁盘IO对task执行的影响。

 

    为了更好达到上面的目的，在业务逻辑满足交换律的条件下，可以设置Combiner优化网络IO和磁盘IO的消耗。

    下面通过源码来剖析shuffle的过程，源码版本为Hadoop0.21.0，配图为：

    

 

 

1、Map端shuffle

1）详细Map端的shuffle过程图为

 

2）具体步骤：

（1）mapper的输出会利用缓冲的方式写到内存，进入一个环形缓冲区。在默认情况下，环形缓冲区大小为100M，这个值可以通过mapreduce. task.io.sort.mb属性来调整，一旦缓冲内容达到阈值（mapreduce. map.sort.spill.percent，默认为0.8），一个后台线程锁定这80MB的内存内容，开始把内容溢出（spill）到磁盘。执行溢写过程，Map task的输出结果还可以往剩下的20MB内存中写，互不影响，但是若20MB也被写满，且80MB没有溢写完毕，map就会被阻塞。

 

（2）在溢写到磁盘之前，线程首先根据Reduce数对数据的进行分区，然后对每个分区在内存中会执行快排（QiukSort）。排序之后，Combiner开始登场，源码为MapOutputBuffer.sortAndSpill()：

for (int i = 0; i < partitions; ++i) {

      //...

      if (spstart != spindex) {

            combineCollector.setWriter(writer);

            RawKeyValueIterator kvIter = new MRResultIterator(spstart, spindex);

            combinerRunner.combine(kvIter, combineCollector);//缓冲区之后溢写之前的Combiner

       }

 

（3）每次溢写都执行一次Combiner，最后没有达到溢写条件进行flush也进行一次Combiner，Combiner之后生成一个溢出文件（spill file），Mapper完成之后就会形成若干个溢出文件。

 

（4）对溢出文件进行合并，配置属性mapreduce.task.io.sort.factor控制一次最多能合并多少流。默认为10，最后循环合并成一个已经分好区的map输出文件。在合并过程中，从源码可知若溢出文件大于等于3，会调用Combiner：

private void mergeParts() {

    //...

    if (numSpills == 1){

        //更名，加后缀