Hadoop的MAPReduce之shuffle

1. shuffle: 洗牌、发牌——（核心机制：数据分区，排序，缓存）；

shuffle具体来说：就是将maptask输出的处理结果数据，分发给reducetask，并在分发的过程中，对数据按key进行排序；

2. shuffle缓存流程：

shuffle是MapReduce处理流程中的一个过程，每一个处理步骤是分散在各个maptask和reducetask节点上完成的，整体来看，分为三个操作：

1）分区partition；

2）根据key进行sort排序；

3）Combiner进行局部value的合并；

（这里再提一下Combiner和reduce的区别：

 

Combiner是在每一个maptask所在的节点运行

Reducer是接收全局所有Mapper的输出结果；

）

3. 详细流程：

1）maptask收集map（）方法输出的keyValue对，放到内存缓冲区(环形缓冲区)中；

2）从内存缓冲区中不断溢出本地磁盘文件，可能会溢出多个文件；

3）多个溢出文件会被合并成大的溢出文件；

4）在溢出的过程以及合并的过程中，都要调用partition进行分组和对key的排序；

5）reducetask根据分区号，去maptask机器上取相对应的结果分区数据；

6）reducetask会取到同一个分区的来自不同maptask的结果文件，reducetask会将这些文件在进行合并；

7）合并成大文件后，shuffle的过程也就结束了，后面进入reducetask的逻辑运算过程，调用reduce方法进行逻辑运算；

8)shuffle中的缓冲区大小会影响到mapreduce程序的执行效率，原则上说，缓冲区越大，磁盘io的次数越少，执行的速度就越快；缓冲区的大小默认是100M，可以通过参数io.sort.mb进行设置；

Shuffle流程详解：

map之后的数据会写入一个内存缓冲区，一条原始记录进过map后转换成<key,value>的形式进入内存缓冲区，但是此时并不知道这个<key,value>对应该发送给哪个reducetask，这个时候partition开始派上用场了，partition根据key的值和reducetask的数量确定这个<key,value>具体应该发送给哪个reducetask。确定的过程是这样的：partition计算key的hash值，将hash对reducetask的数量的数量求模 来确定要发送的reducetask的ID （实际上，由于key值得非均衡分布 这种算法可能会导致发送给某台reducetask的数据过多 而另外的reducetask收到的数据过程，hadoop允许我们自己实现partition接口来实现数据的均衡）。

 

内存缓冲区的大小当然是有限制的，默认是100MB，Map的输出数据一般会比这个大，因此但内存缓冲区快要写满时，hadoop即启动一个线程来讲缓冲区的数据输出到磁盘，这个过程叫做溢写 spill，对应的有一个溢写比例spill.percent，如果将其值设置为0.8，则当内存缓冲区的数据达到80MB大小时，溢写线程启动并锁定这个80MB的内存区域，开始对80MB内部的数据做排序并写出至本地磁盘。这个时候map的输出就只能往剩下的20MB的内存区域中写数据了。这样写一次的话就是一个80MB的文件了。当溢写很多次的话，就会在本地生成很多的小文件。

将这些小文件发送给reducetask并不是一个很好的主意，溢写之后hadoop同时会进行combine操作和merge操作，combine是将具有相同key值得<key,value>组合，merge将小文件合并为大文件等待map过程结束后进行发送。

每个maptask的工作量有大有小，有的很早就完成了任务，有的还在辛勤工作，一部分完成了工作的maptask向ResourceManager发送消息告知分配的任务已经完成。这个时候reducetask也没有闲着，reducetask向ResourceManager发送消息，查询已经完成任务的maptask，并从该maptask的本地文件系统拉取数据，由于有很多的maptask，因此reducetask也会得到很多的小文件，reducetask拉取数据的同时会对这些文件做merge操作，为即将开始的reduce任务做准备。

当Map过程和shuffle过程真正结束的时候，reducetask才开始reduce过程，最后将结果输出至HDFS。