一.Map端:

Map节点运行map task任务生成map的输出结果
1.Shuffer的工作内容

• 从运算效率的出发点,map的输出结果有限存储在map节点的内存中.每个map task都有一个内存缓冲区,存储着map的输出结果,当缓冲快满时,需要将缓冲区的数据以一个临时文件的形式存储到磁盘中,当整个map task结束后,在对磁盘中的这个临时文件做合并,生成最终的输出文件, 最后等待reduce task来拉取数据.当然当map task的结果不大,能够完全存储在内存缓冲区,且未达到内存缓冲区的阀值,那么就不会有写临时文件到磁盘的操作,也不会有后面的合并
  详细过程如下:
• map task 执行任务,输入数据的来源: HDFS的block 在mapreduce的概念中,map task读取的是split分片, split与block的关系: 一对一(默认)
  说明一下block和split
   * Block(物理划分)
  文件上传到HDFS.就要划分成数据块,这里的划分属于物理划分,块的大小可配置(默认:第一代为64MB’,第二代为128MB)可以通过dfs.block.size配置, 为保证数据的安全，block采用冗余 机制：默认为3份，可通过dfs.replication配置。注意：当更改块大小的配置后，新上传的文件的块大小为新配置的值，以前上传的文件的块大小为以前的配置值。
   * Split(逻辑划分)
   Hadoop中的split划分属于逻辑上的划分,目的是为了让map task更好的获取数据,split是通过Hadoop中的InputFormat接口中的getSplit()方法得到的.

2. map执行后，得到key/value键值对。接下来的问题就是，这些键值对应该交给哪个reduce做？注意：reduce的个数是允许用户在提交job时，通过设置方法设置的！
   　　MapReduce提供partitioner接口解决上述问题。默认操作是：对key hash后再以reduce task数量取模，返回值决定着该键值对应该由哪个reduce处理。
   这种默认的取模方式只是为了平均reduce的处理能力，防止数据倾斜，保证负载均衡。
   如果用户自己对Partition有需求，可以自行定制并设置到job上。
   接下来，需要将key/value以及Partition结果都写入到缓冲区，缓冲区的作用：批量收集map结果，减少磁盘IO的影响。
   当然，写入之前，这些数据都会被序列化成字节数组。而整个内存缓冲区就是一个字节数组。
   这个内存缓冲区是有大小限制的，默认100MB。当map task的输出结果很多时，就可能撑爆内存。需将缓冲区的数据临时写入磁盘，然后重新利用这块缓冲区。
   从内存往磁盘写数据被称为Spill(溢写)，由单独线程完成，不影响往缓冲区写map结果的线程。溢写比例：spill.percent(默认0.8)。
   当缓冲区的数据达到阀值，溢写线程启动，锁定这80MB的内存，执行溢写过程。剩下的20MB继续写入map task的输出结果。互不干涉！
   当溢写线程启动后，需要对这80MB空间内的key做排序(Sort)。排序是mapreduce模型的默认行为，也是对序列化的字节做的排序。排序规则：字典排序！
   map task的输出结果写入内存后，当溢写线程未启动时，对输出结果并没有做任何的合并。从官方图可以看出，合并是体现在溢写的临时磁盘文件上的，且这种合并是对不同的
   reduce端的数值做的合并。所以溢写过程一个很重要的细节在于，如果有很多个key/value对需要发送到某个reduce端，那么需要将这些键值对拼接到一块，减少与partition相
   关的索引记录。如果client设置过Combiner，其会将有相同key的key/value对的value加起来，减少溢写到磁盘的数据量。注意：这里的合并并不能保证map结果中所有的相同
   的key值的键值对的value都合并了，它合并的范围只是这80MB，它能保证的是在每个单独的溢写文件中所有键值对的key值均不相同！
   溢写生成的临时文件的个数随着map输出结果的数据量变大而增多，当整个map task完成，内存中的数据也全部溢写到磁盘的一个溢写文件。
   也就是说，不论任何情况下，溢写过程生成的溢写文件至少有一个！但是最终的文件只能有一个，需要将这些溢写文件归并到一起，称为merge。
   merge是将所有的溢写文件归并到一个文件，结合上面所描述的combiner的作用范围，归并得到的文件内键值对有可能拥有相同的key，这个过程如果client设置过
   Combiner，也会合并相同的key值的键值对，如果没有，merge得到的就是键值集合，如{“aaa”, [5, 8, 2, …]}
   注意：combiner的合理设置可以提高效率，但是如果使用不当会影响效率！

二.Reduce端:

当mapreduce任务提交后，reduce task就不断通过RPC从JobTracker那里获取map task是否完成的信息，如果获知某台TaskTracker上的map task执行完成，Shuffle的后半段过程就开始启动。其实呢，reduce task在执行之前的工作就是：不断地拉取当前job里每个map task的最终结果，并对不同地方拉取过来的数据不断地做merge，也最终形成一个文件作为reduce task的输入文件。
1.Copy过程，简单地拉取数据。Reduce进程启动一些数据copy线程（Fether），通过HTTP方式请求map task所在的TaskTracker获取map task的输出文件。因为map task早已结束，这些文件就归TaskTracker管理在本地磁盘。
2.Merge过程。这里的merge如map端的merge动作，只是数组中存放的是不同map端copy过来的数值。Copy过来的数据会先放入内存缓冲区中，这里缓冲区的大小要比map端的更为灵活，它是基于JVM的heap size设置，因为shuffler阶段reducer不运行，所以应该把绝大部分的内存都给shuffle用。
3.merge的三种形式：
内存到内存、内存到磁盘、磁盘到磁盘
　　默认情况下，第一种形式不启用。当内存中的数据量达到一定的阀值，就启动内存到磁盘的merge。与map端类似，这也是溢写过程，当然如果这里设置了Combiner，也是会启动的，然后在磁盘中生成了众多的溢写文件。第二种merge方式一直在运行，直到没有map端的数据时才结束，然后启动第三种磁盘到磁盘的merge方式生成最终的那个文件。
4.reducer的输入文件。不断地merge后，最后会生成一个“最终文件”。这个最终文件可能在磁盘中也可能在内存中。当然我们希望它在内存中，直接作为reducer的输入，但默认情况下，这个文件是存放于磁盘中的。当reducer的输入文件已定，整个shuffle才最终结束。然后就是reducer执行，把结果存放到HDFS上。

参考博客链接:https://www.cnblogs.com/felixzh/p/4680808.html