Hadoop中Map端shuffle过程及源码解析

最新推荐文章于 2022-12-24 00:08:11 发布

lisuo1234

最新推荐文章于 2022-12-24 00:08:11 发布

阅读量760

点赞数

CC 4.0 BY-SA版权

分类专栏： hadoop大数据学习

本文链接：https://blog.youkuaiyun.com/lisuo1234/article/details/54934342

hadoop大数据学习专栏收录该内容

18 篇文章

订阅专栏

本文深入剖析Hadoop Shuffle机制，从MapTask输出到ReduceTask输入的全过程。详细介绍了内存缓冲、溢写、排序、合并等关键步骤，以及如何优化Shuffle过程以减少网络和磁盘I/O开销。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

这张是官方对Shuffle过程的描述。但我可以肯定的是，单从这张图你基本不可能明白Shuffle的过程，因为它与事实相差挺多，细节也是错乱的。后面我会具体描述Shuffle的事实情况，所以这里你只要清楚Shuffle的大致范围就成－怎样把map task的输出结果有效地传送到reduce端。也可以这样理解， Shuffle描述着数据从map task输出到reduce task输入的这段过程。

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

完整地从map task端拉取数据到reduce 端。
在跨节点拉取数据时，尽可能地减少对带宽的不必要消耗。
减少磁盘IO对task执行的影响。

        OK，看到这里时，大家可以先停下来想想，如果是自己来设计这段Shuffle过程，那么你的设计目标是什么。我想能优化的地方主要在于减少拉取数据的量及尽量使用内存而不是磁盘。

        我的分析是基于Hadoop0.21.0的源码，如果与你所认识的Shuffle过程有差别，不吝指出。我会以WordCount为例，并假设它有8个map task和3个reduce task。从上图看出，Shuffle过程横跨map与reduce两端，所以下面我也会分两部分来展开。

        先看看map端的情况，如下图：

        上图可能是某个map task的运行情况。拿它与官方图的左半边比较，会发现很多不一致。官方图没有清楚地说明partition， sort与combiner到底作用在哪个阶段。我画了这张图，希望让大家清晰地了解从map数据输入到map端所有数据准备好的全过程。

        整个流程我分了四步。简单些可以这样说，每个map task都有一个内存缓冲区，存储着map的输出结果，当缓冲区快满的时候需要将缓冲区的数据以一个临时文件的方式存放到磁盘，当整个map task结束后再对磁盘中这个map task产生的所有临时文件做合并，生成最终的正式输出文件，然后等待reduce task来拉数据。

        当然这里的每一步都可能包含着多个步骤与细节，下面我对细节来一一说明：
1.        在map task执行时，它的输入数据来源于HDFS的block，当然在MapReduce概念中，map task只读取split。Split与block的对应关系可能是多对一，默认是一对一。在WordCount例子里，假设map的输入数据都是像“aaa”这样的字符串。

2.        在经过mapper的运行后，我们得知mapper的输出是这样一个key/value对： key是“aaa”， value是数值1。因为当前map端只做加1的操作，在reduce task里才去合并结果集。前面我们知道这个job有3个reduce task，到底当前的“aaa”应该交由哪个reduce去做呢，是需要现在决定的。

        MapReduce提供Partitioner接口，它的作用就是根据key或value及reduce的数量来决定当前的这对输出数据最终应该交由哪个reduce task处理。默认对key hash后再以reduce task数量取模。默认的取模方式只是为了平均reduce的处理能力，如果用户自己对Partitioner有需求，可以订制并设置到job上。

        在我们的例子中，“aaa”经过Partitioner后返回0，也就是这对值应当交由第一个reducer来处理。接下来，需要将数据写入内存缓冲区中，缓冲区的作用是批量收集map结果，减少磁盘IO的影响。我们的key/value对以及Partition的结果都会被写入缓冲区。当然写入之前，key与value值都会被序列化成字节数组。

        整个内存缓冲区就是一个字节数组，它的字节索引及key/value存储结构我没有研究过。如果有朋友对它有研究，那么请大致描述下它的细节吧。

3.        这个内存缓冲区是有大小限制的，默认是100MB。当map task的输出结果很多时，就可能会撑爆内存，所以需要在一定条件下将缓冲区中的数据临时写入磁盘，然后重新利用这块缓冲区。这个从内存往磁盘写数据的过程被称为Spill，中文可译为溢写，字面意思很直观。这个溢写是由单独线程来完成，不影响往缓冲区写map结果的线程。溢写线程启动时不应该阻止map的结果输出，所以整个缓冲区有个溢写的比例spill.percent。这个比例默认是0.8，也就是当缓冲区的数据已经达到阈值（buffer size * spill percent = 100MB * 0.8 = 80MB），溢写线程启动，锁定这80MB的内存，执行溢写过程。Map task的输出结果还可以往剩下的20MB内存中写，互不影响。

        当溢写线程启动后，需要对这80MB空间内的key做排序(Sort)。排序是MapReduce模型默认的行为，这里的排序也是对序列化的字节做的排序。

        在这里我们可以想想，因为map task的输出是需要发送到不同的reduce端去，而内存缓冲区没有对将发送到相同reduce端的数据做合并，那么这种合并应该是体现是磁盘文件中的。从官方图上也可以看到写到磁盘中的溢写文件是对不同的reduce端的数值做过合并。所以溢写过程一个很重要的细节在于，如果有很多个key/value对需要发送到某个reduce端去，那么需要将这些key/value值拼接到一块，减少与partition相关的索引记录。

        在针对每个reduce端而合并数据时，有些数据可能像这样：“aaa”/1， “aaa”/1。对于WordCount例子，就是简单地统计单词出现的次数，如果在同一个map task的结果中有很多个像“aaa”一样出现多次的key，我们就应该把它们的值合并到一块，这个过程叫reduce也叫combine。但MapReduce的术语中，reduce只指reduce端执行从多个map task取数据做计算的过程。除reduce外，非正式地合并数据只能算做combine了。其实大家知道的，MapReduce中将Combiner等同于Reducer。

        如果client设置过Combiner，那么现在就是使用Combiner的时候了。将有相同key的key/value对的value加起来，减少溢写到磁盘的数据量。Combiner会优化MapReduce的中间结果，所以它在整个模型中会多次使用。那哪些场景才能使用Combiner呢？从这里分析，Combiner的输出是Reducer的输入，Combiner绝不能改变最终的计算结果。所以从我的想法来看，Combiner只应该用于那种Reduce的输入key/value与输出key/value类型完全一致，且不影响最终结果的场景。比如累加，最大值等。Combiner的使用一定得慎重，如果用好，它对job执行效率有帮助，反之会影响reduce的最终结果。

4.        每次溢写会在磁盘上生成一个溢写文件，如果map的输出结果真的很大，有多次这样的溢写发生，磁盘上相应的就会有多个溢写文件存在。当map task真正完成时，内存缓冲区中的数据也全部溢写到磁盘中形成一个溢写文件。最终磁盘中会至少有一个这样的溢写文件存在(如果map的输出结果很少，当map执行完成时，只会产生一个溢写文件)，因为最终的文件只有一个，所以需要将这些溢写文件归并到一起，这个过程就叫做Merge。Merge是怎样的？如前面的例子，“aaa”从某个map task读取过来时值是5，从另外一个map 读取时值是8，因为它们有相同的key，所以得merge成group。什么是group。对于“aaa”就是像这样的：{“aaa”, [5, 8, 2, …]}，数组中的值就是从不同溢写文件中读取出来的，然后再把这些值加起来。请注意，因为merge是将多个溢写文件合并到一个文件，所以可能也有相同的key存在，在这个过程中如果client设置过Combiner，也会使用Combiner来合并相同的key。

        至此，map端的所有工作都已结束，最终生成的这个文件也存放在TaskTracker够得着的某个本地目录内。每个reduce task不断地通过RPC从JobTracker那里获取map task是否完成的信息，如果reduce task得到通知，获知某台TaskTracker上的map task执行完成，Shuffle的后半段过程开始启动。

        简单地说，reduce task在执行之前的工作就是不断地拉取当前job里每个map task的最终结果，然后对从不同地方拉取过来的数据不断地做merge，也最终形成一个文件作为reduce task的输入文件。见下图：

        如map 端的细节图，Shuffle在reduce端的过程也能用图上标明的三点来概括。当前reduce copy数据的前提是它要从JobTracker获得有哪些map task已执行结束，这段过程不表，有兴趣的朋友可以关注下。Reducer真正运行之前，所有的时间都是在拉取数据，做merge，且不断重复地在做。如前面的方式一样，下面我也分段地描述reduce 端的Shuffle细节：
1.        Copy过程，简单地拉取数据。Reduce进程启动一些数据copy线程(Fetcher)，通过HTTP方式请求map task所在的TaskTracker获取map task的输出文件。因为map task早已结束，这些文件就归TaskTracker管理在本地磁盘中。

2.        Merge阶段。这里的merge如map端的merge动作，只是数组中存放的是不同map端copy来的数值。Copy过来的数据会先放入内存缓冲区中，这里的缓冲区大小要比map端的更为灵活，它基于JVM的heap size设置，因为Shuffle阶段Reducer不运行，所以应该把绝大部分的内存都给Shuffle用。这里需要强调的是，merge有三种形式：1)内存到内存 2)内存到磁盘 3)磁盘到磁盘。默认情况下第一种形式不启用，让人比较困惑，是吧。当内存中的数据量到达一定阈值，就启动内存到磁盘的merge。与map 端类似，这也是溢写的过程，这个过程中如果你设置有Combiner，也是会启用的，然后在磁盘中生成了众多的溢写文件。第二种merge方式一直在运行，直到没有map端的数据时才结束，然后启动第三种磁盘到磁盘的merge方式生成最终的那个文件。

3. Reducer的输入文件。不断地merge后，最后会生成一个“最终文件”。为什么加引号？因为这个文件可能存在于磁盘上，也可能存在于内存中。对我们来说，当然希望它存放于内存中，直接作为Reducer的输入，但默认情况下，这个文件是存放于磁盘中的。至于怎样才能让这个文件出现在内存中，之后的性能优化篇我再说。当Reducer的输入文件已定，整个Shuffle才最终结束。然后就是Reducer执行，把结果放到HDFS上。

Map端shuffle的过程:
在执行每个map task时，无论map方法中执行什么逻辑，最终都是要把输出写到磁盘上。如果没有reduce阶段，则直接输出到hdfs上，如果有有reduce作业，则每个map方法的输出在写磁盘前线在内存中缓存。每个map task都有一个环状的内存缓冲区，存储着map的输出结果，在每次当缓冲区快满的时候由一个独立的线程将缓冲区的数据以一个溢出文件的方式存放到磁盘，当整个map task结束后再对磁盘中这个map task产生的所有溢出文件做合并，被合并成已分区且已排序的输出文件。然后等待reduce task来拉数据。
二、流程描述

1、在child进程调用到runNewMapper时，会设置output为NewOutputCollector，来负责map的输出。
2、在map方法的最后，不管经过什么逻辑的map处理，最终一般都要调用到TaskInputOutputContext的write方法，进而调用到设置的output即NewOutputCollector的write方法。
3、NewOutputCollector其实只是对MapOutputBuffer的一个封装，其write方法调用的是MapOutputBuffer的collect方法。
4、MapOutputBuffer的collect方法中把key和value序列化后存储在一个环形缓存中，如果缓存满了则会调用startspill方法设置信号量，使得一个独立的线程SpillThread可以对缓存中的数据进行处理。
5、SpillThread线程的run方法中调用sortAndSpill方法对缓存中的数据进行排序后写溢出文件。
6、当map输出完成后，会调用output的close方法。
7、在close方法中调用flush方法，对剩余的缓存进行处理，最后调用mergeParts方法，将前面过程的多个溢出文件合并为一个。
这里写图片描述

对上面流程进行解释：
1、对第一步介绍：
MapTask中的run方法会根据新旧api选择执行的Mapper函数。


    if (useNewApi) {
      runNewMapper(job, splitMetaInfo, umbilical, reporter);
    } else {
      runOldMapper(job, splitMetaInfo, umbilical, reporter);
    }
 1
2
3
4
5
6
 1
2
3
4
5
6

在runNewMapper方法的执行过程如下：

 void runNewMapper( job, splitIndex,umbilical,TaskReporter reporter){
 // 生成一个Mapper
        mapper =  ReflectionUtils.newInstance(taskContext.getMapperClass(), job);
        // 根据splitIndex构建一个split
        split = getSplitDetails(new Path(splitIndex.getSplitLocation()),splitIndex.getStartOffset());
        //生成RecordReader类型的input
input = new NewTrackingRecordReader(split, inputFormat, reporter, taskContext);
        // 根据Reducer数目对输出output赋值
        if (job.getNumReduceTasks() == 0) {
            output = new NewDirectOutputCollector(taskContext, job, umbilical,
                    reporter);
        } else {
            output = new NewOutputCollector(taskContext, job, umbilical,
                    reporter);
        }
        //对mapContent进行赋值
    mapContext = new MapContextImpl(job, getTaskID(), input, output, committer, reporter, split);
     //mapContent进行包装
     mapperContext = new WrappedMapper<INKEY, INVALUE, OUTKEY, OUTVALUE>()
                .getMapContext(mapContext);

        try {
            //根据分片内容，对mapperContext进行初始化
            input.initialize(split, mapperContext);
            //运行mapper的run方法
            mapper.run(mapperContext);
            input.close();
            //关闭output
            output.close(mapperContext);
        } finally {
            closeQuietly(input);
            closeQuietly(output, mapperContext);
        }
}
 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

2、对第二步进行介绍：
Mapper类中的map方法中的Content继承了MapContext，MapContext继承了TaskInputOutputContext。
而在runNewMapper方法中的mapperContext变量，实现了对out的封装。而out是NewOutputCollector类型变量。不管经过什么逻辑的map处理，最终一般都要调用到TaskInputOutputContext的write方法，进而调用到设置的output即NewOutputCollector的write方法
3、对第三步进行介绍：
NewOutputCollector实现了对MapOutputCollector的封装

private class NewOutputCollector<K, V> extendsRecordWriter<K, V> {
        private final MapOutputCollector<K, V> collector;
        NewOutputCollector(JobContext jobContext,
                JobConf job, TaskUmbilicalProtocol umbilical,
                TaskReporter reporter)  {
            collector = createSortingCollector(job, reporter);//对collector进行赋值，变成MapOutputBuffer类型
        }
       //写操作
        @Override
        public void write(K key, V value)  {
            collector.collect(key, value,
                    partitioner.getPartition(key, value, partitions));
        }
      //关闭操作
        @Override
        public void close(TaskAttemptContext context) throws IOException,
                InterruptedException {
            try {
                collector.flush();
            } catch (ClassNotFoundException cnf) {
                throw new IOException("can't find class ", cnf);
            }
            collector.close();
        }
    }
 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

其中MapOutputBuffer实现了MapOutputCollector接口。所以NewOutputCollector中的write方法调用的是MapOutputBuffer的collect方法。

什么是MapOutputBuffer
MapOutputBuffer是一个用来暂时存储map输出的缓冲区，它的缓冲区大小是有限的，当写入的数据超过缓冲区的设定的阀值时，需要将缓冲区的数据溢出写入到磁盘，这个过程称之为spill，spill的动作会通过Condition通知给SpillThread，由SpillThread完成具体的处理过程。MR采用了循环缓冲区，做到数据在spill的同时，仍然可以向剩余空间继续写入数据。
这里写图片描述

缓冲区之间的关系，从上图即可一目了然。 kvoffsets作为一级索引，是用来表示每个k,v在kvindices中的位置。当对kvbuffer中的某一个分区的KeyValue序列进行排序时，排序结果只需要将kvoffsets中对应的索引项进行交换即可，保证kvoffsets中索引的顺序其实就想记录的KeyValue的真实顺序。换句话说，我们要对一堆对象进行排序，实际上只要记录他们索引的顺序即可，原始记录保持不动，而kvoffsets就是一堆整数的序列，交换起来快得多。 kvindices中的内容为：分区号、Key和Value在kvbuffer中的位置。通过解析这个数组，就可以得到某个分区的所有KV的位置。之所以需要按照分区号提取，是因为Map的输出结果需要分为多份，分别送到不同的Reduce任务，否则还需要对key进行计算才得到分区号。 kvbuffer存储了实际的k,v。k,v的大小不向索引区一样明确的是一对占一个int，可能会出现尾部的一个key被拆分两部分，一步存在尾部，一部分存在头部，但是key为保证有序会交给RawComparator进行比较，而comparator对传入的key是需要有连续的，那么由此可以引出key在尾部剩余空间存不下时，如何处理。处理方法是，当尾部存不下，先存尾部，剩余的存头部，同时在copy key存到接下来的位置，但是当头部开始，存不下一个完整的key，会付出溢出flush到磁盘。当碰到整个buffer都存储不下key，那么会抛出异常
MapBufferTooSmallException表示buffer太小容纳不小.

MapOutputBuffer初始化分析

    // k/v serialization
      comparator = job.getOutputKeyComparator();
      keyClass = (Class<K>)job.getMapOutputKeyClass();
      valClass = (Class<V>)job.getMapOutputValueClass();
      serializationFactory = new SerializationFactory(job);
      keySerializer = serializationFactory.getSerializer(keyClass);
      keySerializer.open(bb);
      valSerializer = serializationFactory.getSerializer(valClass);
      valSerializer.open(bb);
 1
2
3
4
5
6
7
8
9
 1
2
3
4
5
6
7
8
9

comparator是key之间用于比较的类，在没有设置的情况下，默认是key所属类里面的一个子类，这个子类继承自WritableComparator。以Text作为key为例，就是class Comparator extends WritableComparator。Map处理的输入并不排序，会对处理完毕后的结果进行排序，此时就会用到该比较器。
serializationFactory，序列化工厂类，其功能是从配置文件中读取序列化类的集合。Map处理的输出是Key,Value集合，需要进行序列化才能写到缓存以及文件中。
keySerializer和valSerializer这两个序列化对象，通过序列化工厂类中获取到的。序列化和反序列化的操作基本类似，都是打开一个流，将输出写入流中或者从流中读取数据。
keySerializer.open(bb)和valSerializer.open(bb)打开的是流，但不是文件流，而是BlockingBuffer，也就是说后续调用serialize输出key/value的时候，都是先写入到Buffer中。这里又涉及一个变量bb。
其定义是：BlockingBuffer bb = new BlockingBuffer()。使用BlockingBuffer的意义在于将序列化后的Key或Value送入BlockingBuffer。BlockingBuffer内部又引入一个类：Buffer。Buffer实际上最终也封装了一个字节缓冲区byte[] kvbuffer，Map之后的结果暂时都会存入kvbuffer这个缓存区，等到要慢的时候再刷写到磁盘，Buffer这个类的作用就是对kvbuffer进行封装，比如在其write方法中存在以下代码：

 public synchronized void write(byte b[], int off, int len)
  {
          spillLock.lock();
          try {
           do {
 .......
               } while (buffull && !wrap);
           } finally {
           spillLock.unlock();
          }
        if (buffull) {
           final int gaplen = bufvoid - bufindex;
           System.arraycopy(b, off, kvbuffer, bufindex, gaplen);
           len -= gaplen;
           off += gaplen;
          bufindex = 0;
         }
        System.arraycopy(b, off, kvbuffer, bufindex, len);
         bufindex += len;
       }
 }
 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

上面的 System.arraycopy 就是将要写入的b（序列化后的数据）写入到 kvbuffer中。因此，Buffer相当于封装了kvbuffer，实现环形缓冲区等功能，BlockingBuffer则继续对此进行封装，使其支持内部Key的比较功能。
那么，上面write这个方法又是什么时候调用的呢？实际上就是MapOutputBuffer的collect方法中，会对KeyValue进行序列化，在序列化方法中，会进行写入：

 public void serialize(Writable w) throws IOException {
       w.write(dataOut);
     }
 1
2
3
 1
2
3

此处的dataout就是前面 keySerializer.open(bb)这一方法中传进来的，也就是BlockingBuffer（又封装了Buffer）：

 public void open(OutputStream out) {
       if (out instanceof DataOutputStream) {
         dataOut = (DataOutputStream) out;
       } else {
         dataOut = new DataOutputStream(out);
       }
     }
 1
2
3
4
5
6
7
 1
2
3
4
5
6
7

因此，当执行序列化方法serialize的时候，会调用Buffer的write方法，最终将数据写入byte[] kvbuffer。

collect分析
这里分析的collect是MapOutputBuffer中的collect方法，在用户层的map方法内调用collector.collect最终会一层层调用到MapOutputBuffer.collect。
collect的代码我们分为两部分来看，一部分是根据索引区来检查是否需要触发spill，另外一部分是操作buffer并更新索引区的记录。
第一部分代码如下

if (bufferRemaining <= 0) {
        //  开始spill，如果溢写线程没有在运行并且内存已满
        spillLock.lock();
        try {
          do {
            if (!spillInProgress) {
              final int kvbidx = 4 * kvindex;
              final int kvbend = 4 * kvend;
              final int bUsed = distanceTo(kvbidx, bufindex);
              final boolean bufsoftlimit = bUsed >= softLimit;
              if ((kvbend + METASIZE) % kvbuffer.length !=
                  equator - (equator % METASIZE)) {
                //  溢写完成，修改空间参数
                resetSpill();
                bufferRemaining = Math.min(
                    distanceTo(bufindex, kvbidx) - 2 * METASIZE,
                    softLimit - bUsed) - METASIZE;
                continue;
              } else if (bufsoftlimit && kvindex != kvend) {//开始溢出
                startSpill();
                final int avgRec = (int)
                  (mapOutputByteCounter.getCounter() /
                  mapOutputRecordCounter.getCounter());
                final int distkvi = distanceTo(bufindex, kvbidx);
                final int newPos = (bufindex +
                  Math.max(2 * METASIZE - 1,
                          Math.min(distkvi / 2,
                                   distkvi / (METASIZE + avgRec) * METASIZE)))
                  % kvbuffer.length;
                setEquator(newPos);
                bufmark = bufindex = newPos;
                final int serBound = 4 * kvend;
                bufferRemaining = Math.min(
                    distanceTo(bufend, newPos),
                    Math.min(
                      distanceTo(newPos, serBound),
                      softLimit)) - 2 * METASIZE;
              }
            }
          } while (false);
        } finally {
          spillLock.unlock();
        }
      }
 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

其中的resetSpill()是处理有key存在尾部存了一部分，头部存了一部分的情况。由于key的比较函数需要的是一个连续的key，因此需要对key进行特殊处理。
startSpill() 是为了激活spill

    private void startSpill() {
      assert !spillInProgress;
      kvend = (kvindex + NMETA) % kvmeta.capacity();
      bufend = bufmark;
      spillInProgress = true;
      spillReady.signal();//激活spill
    }
 1
2
3
4
5
6
7
 1
2
3
4
5
6
7

第二部分代码。

 try {
        // 步骤1：序列化K
        int keystart = bufindex;
        keySerializer.serialize(key);
        if (bufindex < keystart) {
          // 对k进行转换调整，使其连续
          bb.shiftBufferedKey();
          keystart = 0;
        }
        // 步骤2：序列化value，并标记一个完整k，v的结束位置
        final int valstart = bufindex;
        valSerializer.serialize(value);
        bb.write(b0, 0, 0);
        //record必须被标记在前面的写之后，因为这条record的元数据（二级索引）记录还没有被写。
        int valend = bb.markRecord();

        mapOutputRecordCounter.increment(1);
        mapOutputByteCounter.increment(
            distanceTo(keystart, valend, bufvoid));

        // 步骤三：更新索引信息
        kvmeta.put(kvindex + PARTITION, partition);
        kvmeta.put(kvindex + KEYSTART, keystart);
        kvmeta.put(kvindex + VALSTART, valstart);
        kvmeta.put(kvindex + VALLEN, distanceTo(valstart, valend));
        // advance kvindex
        kvindex = (kvindex - NMETA + kvmeta.capacity()) % kvmeta.capacity();
      } catch (MapBufferTooSmallException e) {//MapBufferTooSmall异常
        LOG.info("Record too large for in-memory buffer: " + e.getMessage());
        spillSingleRecord(key, value, partition);
        mapOutputRecordCounter.increment(1);
        return;
}}
 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

SpillThread的run方法。

   public void run() {
       //临界区
        spillLock.lock();
        spillThreadRunning = true;
        try {
          while (true) {
            spillDone.signal();
            //表示没有要spill的记录
            while (!spillInProgress) {
              spillReady.await();
            }
            try {
              spillLock.unlock();
              //执行操作
              sortAndSpill();
            } catch (Throwable t) {
              sortSpillException = t;
            } finally {
              spillLock.lock();
              if (bufend < bufstart) {
                bufvoid = kvbuffer.length;
              }
              kvstart = kvend;
              bufstart = bufend;
              spillInProgress = false;
            }
          }
        } catch (InterruptedException e) {
          Thread.currentThread().interrupt();
        } finally {
          spillLock.unlock();
          spillThreadRunning = false;
        }
      }
    }
 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

SpillThread线程的run方法中调用sortAndSpill把缓存中的输出写到格式为+ ‘/spill’ + spillNumber + ‘.out’的spill文件中。索引（kvindices）保持在spill{spill号}.out.index中，数据保存在spill{spill号}.out中创建SpillRecord记录，输出文件和IndexRecord记录，然后，需要在kvoffsets上做排序，排完序后顺序访问kvoffsets，也就是按partition顺序访问记录。按partition循环处理排完序的数组，如果没有combiner，则直接输出记录，否则，调用combineAndSpill，先做combin然后输出。循环的最后记录IndexRecord到SpillRecord。

sortAndSpill 函数

private void sortAndSpill() throws IOException, ClassNotFoundException,InterruptedException {
               ........
            try {
                sorter.sort(MapOutputBuffer.this, mstart, mend, reporter);
                .......
                for (int i = 0; i < partitions; ++i) {
                    IFile.Writer<K, V> writer = null;
                    try {
                        //判断有没有combiner函数
                        if (combinerRunner == null) {
                            .......
                                writer.append(key, value);//键值写到溢出文件
                            .......
                            }
                        } else {
                            .......
                                combinerRunner.combine(kvIter, combineCollector);
                            .......

                        }

                        // 给SpillRecord赋值
                        rec.startOffset = segmentStart;// 起始位置
                        rec.rawLength = writer.getRawLength()
                                + CryptoUtils.cryptoPadding(job);// 原始长度
                        rec.partLength = writer.getCompressedLength()
                                + CryptoUtils.cryptoPadding(job);// 压缩后长度
                        spillRec.putIndex(rec, i);

                    } finally {
                        if (null != writer)
                            writer.close();
                    }
                }
                //当indexCacheList的累积到一定的长度时，才溢写到文件中
                if (totalIndexCacheMemory >= indexCacheMemoryLimit) {
                    // create spill index file
                    Path indexFilename = mapOutputFile
                            .getSpillIndexFileForWrite(numSpills, partitions
                                    * MAP_OUTPUT_INDEX_RECORD_LENGTH);
                    spillRec.writeToFile(indexFilename, job);
                } else {
                    indexCacheList.add(spillRec);
                    totalIndexCacheMemory += spillRec.size()
                            * MAP_OUTPUT_INDEX_RECORD_LENGTH;
                }
            } finally {
                if (out != null)
                    out.close();
            }
        }
 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51

MapOutputBuffer的compare方法和swap方法

MapOutputBuffer实现了IndexedSortable接口，从接口命名上就可以猜想到，这个排序不是移动数据，而是移动数据的索引。在这里要排序的其实是kvindices对象，通过移动其记录在kvoffets上的索引来实现。如图，表示了写磁盘前Sort的效果。kvindices保持了记录所属的（Reduce）分区，key在缓冲区开始的位置和value在缓冲区开始的位置，通过kvindices，我们可以在缓冲区中找到对应的记录。kvoffets用于在缓冲区满的时候对kvindices的partition进行排序，排完序的结果将输出到输出到本地磁盘上，其中索引（kvindices）保持在spill{spill号}.out.index中，数据保存在spill{spill号}.out中。通过观察MapOutputBuffer的compare知道，先是在partition上排序，然后是在key上排序。
这里写图片描述

 public int compare(final int mi, final int mj) {
      final int kvi = offsetFor(mi % maxRec);
      final int kvj = offsetFor(mj % maxRec);
      final int kvip = kvmeta.get(kvi + PARTITION);
      final int kvjp = kvmeta.get(kvj + PARTITION);
      // 按照分区排序
      if (kvip != kvjp) {
        return kvip - kvjp;
      }
      // 按照key排序
      return comparator.compare(kvbuffer,
          kvmeta.get(kvi + KEYSTART),
          kvmeta.get(kvi + VALSTART) - kvmeta.get(kvi + KEYSTART),
          kvbuffer,
          kvmeta.get(kvj + KEYSTART),
          kvmeta.get(kvj + VALSTART) - kvmeta.get(kvj + KEYSTART));
    }

 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

flush分析

我们看看flush是在哪个时间段调用的，在文章开始处说到runOldMapper处理的时候，有提到，代码如下：

runner.run(in, new OldOutputCollector(collector, conf), reporter);
collector.flush()
 1
2
 1
2

Mapper的结果都已经被collect了，需要对缓冲区做一些最后的清理，调用flush方法，合并spill{n}文件产生最后的输出。先等待可能的spill过程完成，然后判断缓冲区是否为空，如果不是，则调用sortAndSpill，做最后的spill，然后结束spill线程.

public void flush() throws IOException, ClassNotFoundException,
           InterruptedException {
      spillLock.lock();
      try {
        while (spillInProgress) {
          reporter.progress();
          spillDone.await();//写进程等待
        }
        checkSpillException();

        final int kvbend = 4 * kvend;
        if ((kvbend + METASIZE) % kvbuffer.length !=
            equator - (equator % METASIZE)) {
          // 溢写完成
          resetSpill();
        }
        if (kvindex != kvend) {//缓冲区还有数据没有刷出去，则触发spill
          kvend = (kvindex + NMETA) % kvmeta.capacity();
          bufend = bufmark;
          sortAndSpill();
        }
      } catch (InterruptedException e) {
        throw new IOException("Interrupted while waiting for the writer", e);
      } finally {
        spillLock.unlock();
      }
      assert !spillLock.isHeldByCurrentThread();
      // 停止spill线程
      try {
        spillThread.interrupt();
        spillThread.join();
      } catch (InterruptedException e) {
        throw new IOException("Spill failed", e);
      }
      // release sort buffer before the merge
      kvbuffer = null;
      //合并之前输出的spill.1.out...spill.n.out为file.out
      mergeParts();
      Path outputPath = mapOutputFile.getOutputFile();
      fileOutputByteCounter.increment(rfs.getFileStatus(outputPath).getLen());
    }
 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

MapTask.MapOutputBuffer的mergeParts()方法.

从不同溢写文件中读取出来的，然后再把这些值加起来。因为merge是将多个溢写文件合并到一个文件，所以可能也有相同的key存在，在这个过程中如果配置设置过Combiner，也会使用Combiner来合并相同的key。?mapreduce让每个map只输出一个文件，并且为这个文件提供一个索引文件，以记录每个reduce对应数据的偏移量。

private void mergeParts() throws IOException, InterruptedException,
                ClassNotFoundException {
        ..........
            {
                IndexRecord rec = new IndexRecord();
                final SpillRecord spillRec = new SpillRecord(partitions);
                for (int parts = 0; parts < partitions; parts++) {//循环分区
                    //  创建需要merge的分片
                    List<Segment<K, V>> segmentList = new ArrayList<Segment<K, V>>(
                            numSpills);
                    for (int i = 0; i < numSpills; i++) {//循环共多少个split
                        IndexRecord indexRecord = indexCacheList.get(i)
                                .getIndex(parts);

                        Segment<K, V> s = new Segment<K, V>(job, rfs,
                                filename[i], indexRecord.startOffset,
                                indexRecord.partLength, codec, true);
                        segmentList.add(i, s);
                        }
                    }

                 ........
                    // 合并操作
                    @SuppressWarnings("unchecked")
                    RawKeyValueIterator kvIter = Merger.merge(job, rfs,
                            keyClass, valClass, codec, segmentList,
                            mergeFactor, new Path(mapId.toString()),
                            job.getOutputKeyComparator(), reporter,
                            sortSegments, null, spilledRecordsCounter,
                            sortPhase.phase(), TaskType.MAP);

                    //  将merge后的文件写入到磁盘中 ，如果有combiner，要进行后写入
                    long segmentStart = finalOut.getPos();
                    FSDataOutputStream finalPartitionOut = CryptoUtils
                            .wrapIfNecessary(job, finalOut);
                    Writer<K, V> writer = new Writer<K, V>(job,
                            finalPartitionOut, keyClass, valClass, codec,
                            spilledRecordsCounter);
                    if (combinerRunner == null
                            || numSpills < minSpillsForCombine) {
                        Merger.writeFile(kvIter, writer, reporter, job);
                    } else {
                        combineCollector.setWriter(writer);
                        combinerRunner.combine(kvIter, combineCollector);
                    }

                    // SpillRecord赋值
                    rec.startOffset = segmentStart;
                    rec.rawLength = writer.getRawLength()
                            + CryptoUtils.cryptoPadding(job);
                    rec.partLength = writer.getCompressedLength()
                            + CryptoUtils.cryptoPadding(job);
                    spillRec.putIndex(rec, parts);
                }
                spillRec.writeToFile(finalIndexFile, job);
                finalOut.close();
                for (int i = 0; i < numSpills; i++) {
                    rfs.delete(filename[i], true);
                }
            }
        }

 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62

合并前后index文件和spill文件的结构图

merge最终生成一个spill.out和spill.out.index文件
从前面的分析指导，多个partition的都在一个输出文件中，但是按照partition排序的。即把maper输出按照partition分段了。一个partition对应一个reducer，因此一个reducer只要获取一段即可。