Hadoop系列（三）——MapReudce总结

三、MapReduce

1、简介

MapReduce是一个基于集群的高性能并行计算平台（Cluster Infrastructure）
MapReduce是一个并行计算与运行软件框架（Software Framework）
MapReduce是一个并行程序设计模型与方法（Programming Model & Methodology）

MapReduce有两个含义：

1. 一般来说，在说到计算框架时，我们指的是开源社区的MapReduce计算框架，但随着新一代计算框架如Spark、Flink的崛起，开源社区的MapReduce计算框架在生产环境中使用得越来越少，主见退出舞台。
2. 第二个含义是一种**编程模型**，这种编程模型来源于古老的函数式编程思想，在 Lisp 等比较老的语言中也有相应的实现，并随着计算机 CPU 单核性能以及核心数量的飞速提升在分布式计算中焕发出新的生机。

MapReduce 模型将数据处理方式抽象为map和reduce，其中map也叫映射，顾名思义，它表现的是数据的一对一映射，通常完成数据转换的工作。reduce被称为归约，它表示另外一种映射方式，通常完成聚合的工作，如下图所示：

• MapReduce是一个软件框架和编程模型，用于处理大量数据。MapReduce程序分两个阶段工作，即Map和Reduce。Map任务处理数据的拆分和映射，而 Reduce 任务则随机排列和减少数据。

• Hadoop能够运行用各种语言编写的MapReduce程序：Java，Ruby，Python和C++。Map Reduce在云计算中的程序本质上是并行的，因此对于在集群中使用多台机器进行大规模数据分析非常有用。

• MapReduce核心功能是将用户编写的业务逻辑代码和自带默认组件整合成一个完整的分布式运算程序，并发运行在一个Hadoop集群上。

MapReduce主要思想

MapReduce擅长处理大数据，思想就是分而治之。概念"Map（映射）“和"Reduce（归约）”，是它们的主要思想，都是从函数式编程语言里借来的，还有从矢量编程语言里借来的特性。它极大地方便了编程人员在不会分布式并行编程的情况下，将自己的程序运行在分布式系统上。

• Mapper负责“分”，即把复杂的任务分解为若干个简单的任务来处理，缩小原任务的数据计算规模。

  就近计算原则，任务会分配到存放着所需数据的节点上进行计算。

  这些小任务可以并行计算，彼此间几乎没有依赖关系

• **Reducer负责“合”，**对map阶段的结果进行汇总，Reducer个数，通过mapred-site.xml配置文件里设置参数mapred.reduce.tasks的值，默认值为1。

总结：

1. MapReduce运算程序一般需要分成2个阶段：Map阶段和Reduce阶段
2. Map阶段的并发MapTask，完全并行运行，互不相干
3. Reduce阶段的并发ReduceTask，完全互不相干，但是他们的数据依赖与上一阶段所有MapTask并行实例的输出
4. MapReduce编程模型只能包含一个Map阶段和一个Reduce阶段，如果用户的业务逻辑非常复杂，那就只能多个MapReduce程序，串行运行。

2、MapReduce优缺点

优点：

1. MapReduce易于编程

   它简单的实现一些接口，就可以完成一个分布式程序，这个分布式程序可以分布到大量廉价的PC机器上运行。也就是说你写一个分布式程序，跟写一个简单的串行程序是一模一样的。就是因为这个特点使得MapReduce编程变得非常流行。

2. 良好的扩展性

   当你的计算资源不能得到满足的时候，你可以通过简单的增加机器来扩展它的计算能力。

3. 高容错性

   MapReduce设计的初衷就是使程序能够部署在廉价的PC机器上，这就要求它具有很高的容错性。比如其中一台机器挂了，它可以把上面的计算任务转移到另外一个节点上运行，不至于这个任务运行失败，而且这个过程不需要人工参与，而完全是由Hadoop内部完成的。

4. 适合PB级以上海量数据的离线处理

   可以实现上千台服务器集群并发工作，提供数据处理能力。

缺点

1. 不擅长实时计算

   MapReduce无法像MySQL一样，在毫秒或者秒级内返回结果。

2. 不擅长流式计算

   流式计算的输入数据是动态的，而MapReduce的输入数据集是静态的，不能动态变化。这是因为MapReduce自身的设计特点决定了数据源必须是静态的。

3. 不擅长DAG（有向无环图）计算

   多个应用程序存在依赖关系，后一个应用程序的输入为前一个的输出。在这种情况下，MapReduce并不是不能做，而是使用后，每个MapReduce作业的输出结果都会写入到磁盘，会造成大量的磁盘IO，导致性能非常的低下。

3、MapReduce作业任务涉及的组件

Mapreduce是hadoop中一个批量计算的框架，在整个Mapreduce作业的过程中，包括从数据的输入，数据的处理，数据的输出这些部分，而其中数据的处理部分就要map，reduce，combiner等操作组成。在一个mapreduce的作业中必定会涉及到如下一些组件：

• client客户端，提交mapreduce作业
• yarn资源管理器(RM,ResourceManager)，负责集群上计算资源的协调
• yarn节点管理器(NM,NodeManager)，负责启动和监控集群中机器上的计算容器（container）
• mapreduce的application master，负责协调运行mapreduce的作业
• hdfs，分布式文件系统，负责与其他实体共享作业文件

4、MapReduce的工作流程（举例理解）

让我们用一个例子（统计单词数量）来理解MapReduce的工作方式。考虑你的MapReduce程序有以下输入数据（示例数据来自这里）：

Welcome to Hadoop Class
Hadoop is good
Hadoop is bad

以上输入数据需要经过MapReduce以下几个步骤的处理：

MapReduce任务的最终输出是：

单词	数量
bad	1
Class	1
good	1
Hadoop	3
is	2
to	1
Welcome	1

数据经历了以下几个阶段：

整体四个阶段：

分片------Map------Shuffle------Reduce

1. Input Splits————分片，格式化数据源

   输入 Map 阶段的数据源，必须经过分片和格式化操作。

   • 分片操作：

     指的是将源文件划分为大小相等的小数据块( Hadoop 2.x 中默认 128MB )，也就是分片( split )。Hadoop 会为每一个分片构建一个 Map 任务，并由该任务运行自定义的 map() 函数，从而处理分片里的每一条记录;

   • 格式化操作：

     将划分好的分片( split )格式化为键值对<key,value>形式的数据，其中， key 代表偏移量， value 代表每一行内容。

2. Mapping————执行MapTask

   这是执行map-reduce程序的第一个阶段。 在这个阶段中，每个分片中的数据被传递给一个mapping 函数以产生输出值。

   在我们的例子中，映射阶段的工作是计算来自输入分割的每个词的出现次数，并且提供<word, frequency>形式的列表。

   • 内存缓冲区 缓存中间结果
     • 每个 Map 任务都有一个内存缓冲区(缓冲区大小 100MB )，输入的分片( split )数据经过 Map 任务处理后的中间结果会写入内存缓冲区中。
     • 如果写人的数据达到内存缓冲的阈值( 80MB )，会启动一个线程将内存中的溢出数据写入磁盘，同时不影响 Map 中间结果继续写入缓冲区。
     • 在溢写过程中， MapReduce 框架会对 key 进行排序，如果中间结果比较大，会形成多个溢写文件，最后的缓冲区数据也会全部溢写入磁盘形成一个溢写文件，如果是多个溢写文件，则最后合并所有的溢写文件为一个文件。

3. Shuffling————执行Shuffling合并任务

   MapReduce 工作过程中， Map 阶段处理的数据如何传递给 Reduce 阶段，这是 MapReduce 框架中关键的一个过程，这个过程叫作 Shuffle 。

   此阶段消费Mapping阶段的输出。 其任务是整合Mapping阶段输出的相关记录。 在我们的例子中，同样的词汇与各自的频率一起组合在一起。

   此阶段除了进行Shuffling操作还可以进行sorting操作，Shuffle 会将 MapTask 输出的处理结果数据分发给 ReduceTask ，并在分发的过程中，对数据按 key 进行分区和排序。

4. Reducing————执行ReduceTask

   在这个阶段，会汇总来自Shuffling阶段的输出值。 该阶段结合Shuffling阶段的值并返回单个输出值。 总之，这个阶段得出了完整的数据集。

   输入 ReduceTask 的数据流是<key, {value list}>形式，用户可以自定义 reduce()方法进行逻辑处理，最终以<key, value>的形式输出。

5. 写入文件
   MapReduce 框架会自动把 ReduceTask 生成的<key, value>传入 OutputFormat 的 write 方法，实现文件的写入操作。

5、Shuffle详解

1. Map是映射，负责数据的过滤分法，将原始数据转化为键值对；

   <key1, value1>,<key1, value2>,<key2, value1>,<key2, value2>…

2. Reduce是合并，将具有相同key值的value进行处理后再输出新的键值对作为最终结果。

   <key1, values>,<key2, values>

3. 为了让Reduce可以并行处理Map的结果，必须对Map的输出进行一定的排序与分割，然后再交给对应的Reduce，而这个将Map输出进行进一步整理并交给Reduce的过程就是Shuffle。

   <key1, (value1,value2…)>,<key2, (value1,value2…)>

shuffle概念

shuffle的本意是洗牌、混洗的意思，把一组有规则的数据尽量打乱成无规则的数据。而在MapReduce中，shuffle更像是洗牌的逆过程，指的是将map端的无规则输出按指定的规则“打乱”成具有一定规则的数据，以便reduce端接收处理。其在MapReduce中所处的工作阶段是map输出后 到 reduce接收前，具体可以分为map端和reduce端前后两个部分。在shuffle之前，也就是在map阶段，MapReduce会对要处理的数据进行分片（split）操作，为每一个分片分配一个MapTask任务。接下来map()函数会对每一个分片中的每一行数据进行处理得到键值对（key,value），其中key为偏移量，value为一行的内容。此时得到的键值对又叫做“中间结果”。此后便进入shuffle阶段，由此可以看出shuffle阶段的作用是处理“中间结果”。

block块（物理划分）

block是HDFS中的基本存储单位，hadoop1.x默认大小为64M而hadoop2.x默认块大小为128M。文件上传到HDFS，就要划分数据成块，这里的划分属于物理的划分（实现机制也就是设置一个read方法，每次限制最多读128M的数据后调用write进行写入到hdfs），块的大小可通过 dfs.block.size配置。block采用冗余机制保证数据的安全：默认为3份，可通过dfs.replication配置。

注意：当更改块大小的配置后，新上传的文件的块大小为新配置的值，以前上传的文件的块大小为以前的配置值。

split分片（逻辑划分）

一个MapReducejob的map阶段并行度由客户端在提交job时决定，即客户端提交job之前会对待处理数据进行逻辑切片split。

Hadoop中split划分属于逻辑上的划分，决定了maptask的并行度，有几个split分片就会启动几个maptask。

Split输入分片的概念:

所谓输入分片，并不是真的把原来的一个大文件，比如说10MB的文件，切分成10个1MB的小文件，这里的分片不是物理分片，而是逻辑分片。所谓逻辑分片就是根据文件的字节索引进行分割，比如0~1MB位置定义为第一个分片，1MB~2MB定义为为第二个分片，依次类推……而原来的大文件还是原来的大文件，不会受到影响，因此，输入分片（input split）存储的并非数据本身，而是一个分片长度和一个记录数据的位置的数组。

shuffle流程概括：

因为频繁的磁盘I/O操作会严重的降低效率，因此“中间结果”不会立马写入磁盘，而是优先存储到map节点的“环形内存缓冲区”.

• 在写入的过程中进行分区（partition），也就是对于每个键值对来说，都增加了一个partition属性值，然后连同键值对一起序列化成字节数组写入到缓冲区（缓冲区采用的就是字节数组，默认大小为100M）。

• 当写入的数据量达到预先设置的阙值后（mapreduce.map.io.sort.spill.percent,默认0.80，或者80%）便会启动溢写出线程将缓冲区中的那部分数据溢出写（spill）到磁盘的临时文件中，并在写入前根据key进行排序（sort）和合并（combine，可选操作），溢出写过程按轮询方式将缓冲区中的内容写到mapreduce.cluster.local.dir属性指定的目录中。

• 当整个map任务完成溢出写后，会对磁盘中这个map任务产生的**所有临时文件（spill文件）进行归并（merge）**操作生成最终的正式输出文件，此时的归并是将所有spill文件中的相同partition合并到一起，并对各个partition中的数据再进行一次排序（sort），生成<key，value-list>。

• 文件归并时，如果溢写文件数量超过参数min.num.spills.for.combine的值（默认为3）时，可以再次进行合并。至此，map端shuffle过程结束，接下来等待reduce task来拉取数据。

---

对于reduce端的shuffle过程来说，reduce task在执行之前的工作就是不断地拉取当前job里每个map task的最终结果，然后对从不同地方拉取过来的数据不断地做merge最后合并成一个分区相同的大文件，然后对这个文件中的键值对按照key进行sort排序，排好序之后紧接着进行分组，分组完成后才将整个文件交给reduce task处理。

下图是shuffle的官方流程图：

结合下面三张图可以清楚地理解shuffle过程：

Shuffle详细流程

Map和Reduce操作需要我们自己定义相应Map类和Reduce类，以完成我们所需要的化简、合并操作，而shuffle则是系统自动帮我们实现的，了解shuffle的具体流程能帮助我们编写出更加高效的Mapreduce程序。

Shuffle过程包含在Map和Reduce两端，即Map shuffle和Reduce shuffle

（1）Map端Shuffle

1. 分区partition ： 分区决定map输出的数据将会被哪个reduce任务进行处理
2. 写入环形内存缓冲区 ： 在内存缓存中间结果
3. 排序sort—>合并combiner ： 会对我们分区中的数据进行排序
4. 生成溢出spill写文件 ： 将内存的数据写入磁盘上的文件
5. 归并merge ： 把溢出写的多个文件合并

在Map端的shuffle过程是对Map的结果进行分区、排序、分割，然后将属于同一划分（分区）的输出合并在一起并写在磁盘上，最终得到一个分区有序的文件。分区有序的含义是map输出的键值对按分区进行排列，具有相同partition值的键值对存储在一起，每个分区里面的键值对又按key值进行升序排列（默认），其流程大致如下：

1）Partition

• 在将map()函数处理后得到的（key,value）对写入到缓冲区之前，需要先进行分区操作，这样就能把map任务处理的结果发送给指定的reducer去执行，从而达到负载均衡，避免数据倾斜。

• 对于map输出的每一个键值对，系统都会给定一个partition，partition值默认是通过计算key的hash值后对Reduce task的数量取模获得。如果一个键值对的partition值为1，意味着这个键值对会交给第一个Reducer处理。

我们知道每一个Reduce的输出都是有序的，但是将所有Reduce的输出合并到一起却并非是全局有序的，如果要做到全局有序，我们该怎么做呢？最简单的方式，只设置一个Reduce task，但是这样完全发挥不出集群的优势，而且能应对的数据量也很受限。最佳的方式是自己定义一个Partitioner，用输入数据的最大值除以系统Reduce task数量的商作为分割边界，也就是说分割数据的边界为此商的1倍、2倍至numPartitions-1倍，这样就能保证执行partition后的数据是整体有序的。

另一种需要我们自己定义一个Partitioner的情况是各个Reduce task处理的键值对数量极不平衡。对于某些数据集，由于很多不同的key的hash值都一样，导致这些键值对都被分给同一个Reducer处理，而其他的Reducer处理的键值对很少，从而拖延整个任务的进度。当然，编写自己的Partitioner必须要保证具有相同key值的键值对分发到同一个Reducer。

2）Collector缓存到内存

• 因为频繁的磁盘I/O操作会严重的降低效率，因此“中间结果”不会立马写入磁盘，而是优先存储到map节点的“环形内存缓冲区”，
• Map的输出结果是由collector处理的，每个Map任务不断地将键值对输出到在内存中构造的一个环形数据结构中。使用环形数据结构是为了更有效地使用内存空间，在内存中放置尽可能多的数据。

这个数据结构其实就是个字节数组，叫Kvbuffer，名如其义，但是这里面不光放置了数据，还放置了一些索引数据，给放置索引数据的区域起了一个Kvmeta的别名，在Kvbuffer的一块区域上穿了一个IntBuffer（字节序采用的是平台自身的字节序）的马甲。数据区域和索引数据区域在Kvbuffer中是相邻不重叠的两个区域，用一个分界点来划分两者，分界点不是亘古不变的，而是每次Spill之后都会更新一次。初始的分界点是0，数据的存储方向是向上增长，索引数据的存储方向是向下增长，如图所示：

• Kvbuffer（数据：字节数组）的存放指针bufindex是一直闷着头地向上增长，比如bufindex初始值为0，一个Int型（4字节）的key写完之后，bufindex增长为4，一个Int型的value写完之后，bufindex增长为8。
• 索引是对在kvbuffer中的键值对的索引，是个四元组，包括：value的起始位置、key的起始位置、partition值、value的长度，占用四个Int长度，Kvmeta的存放指针Kvindex每次都是向下跳四个“格子”，然后再向上一个格子一个格子地填充四元组的数据。比如Kvindex初始位置是-4，当第一个键值对写完之后，(Kvindex+0)的位置存放value的起始位置、(Kvindex+1)的位置存放key的起始位置、(Kvindex+2)的位置存放partition的值、(Kvindex+3)的位置存放value的长度，然后Kvindex跳到-8位置，等第二个键值对和索引写完之后，Kvindex跳到-12位置。

Kvbuffer的大小可以通过io.sort.mb设置，默认大小为100M。但不管怎么设置，Kvbuffer的容量都是有限的，键值对和索引不断地增加，加着加着，Kvbuffer总有不够用的那天，那怎么办？把数据从内存刷到磁盘上再接着往内存写数据，把Kvbuffer中的数据刷到磁盘上的过程就叫Spill，多么明了的叫法，内存中的数据满了就自动地spill到具有更大空间的磁盘。

关于Spill触发的条件，也就是Kvbuffer用到什么程度开始Spill，还是要讲究一下的。如果把Kvbuffer用得死死得，一点缝都不剩的时候再开始Spill，那Map任务就需要等Spill完成腾出空间之后才能继续写数据；如果Kvbuffer只是满到一定程度**（设置一个阈值）**，比如80%的时候就开始Spill，那在Spill的同时，Map任务还能继续写数据，如果Spill够快，Map可能都不需要为空闲空间而发愁。两利相衡取其大，一般选择后者。Spill的门限可以通过io.sort.spill.percent，默认是0.8。

Spill这个重要的过程是由Spill线程承担，Spill线程从Map任务接到“命令”之后就开始正式干活，干的活叫SortAndSpill，原来不仅仅是Spill，在Spill之前还有个颇具争议性的Sort。

3）Sort

当Spill触发后，SortAndSpill先把Kvbuffer中的数据按照partition值和key两个关键字升序排序，移动的只是索引数据，排序结果是Kvmeta中数据按照partition为单位聚集在一起，同一partition内的按照key有序。-------快速排序

4）Spill

• Spill线程为这次Spill过程创建一个磁盘文件：从所有的本地目录中轮训查找能存储这么大空间的目录，找到之后在其中创建一个类似于“spill12.out”的文件。Spill线程根据排过序的Kvmeta挨个partition的把数据吐到这个文件中，一个partition对应的数据吐完之后顺序地吐下个partition，直到把所有的partition遍历完。一个partition在文件中对应的数据也叫段(segment)。

• 【可选步骤】在这个过程中如果用户配置了combiner类，那么在写之前会先调用combineAndSpill()，对结果进行进一步合并后再写出。Combiner会优化MapReduce的中间结果，所以它在整个模型中会多次使用。那哪些场景才能使用Combiner呢？Combiner的输出是Reducer的输入，Combiner绝不能改变最终的计算结果。所以从我的想法来看，Combiner只应该用于那种Reduce的输入key/value与输出key/value类型完全一致，且不影响最终结果的场景。比如累加，最大值等。Combiner的使用一定得慎重，如果用好，它对job执行效率有帮助，反之会影响reduce的最终结果。

所有的partition对应的数据都放在这个文件里，虽然是顺序存放的，但是怎么直接知道某个partition在这个文件中存放的起始位置呢？强大的索引又出场了。有一个三元组记录某个partition对应的数据在这个文件中的索引：起始位置、原始数据长度、压缩之后的数据长度，一个partition对应一个三元组。

然后把这些索引信息存放在内存中，如果内存中放不下了，后续的索引信息就需要写到磁盘文件中了：从所有的本地目录中轮训查找能存储这么大空间的目录，找到之后在其中创建一个类似于“spill12.out.index”的文件，文件中不光存储了索引数据，还存储了crc32的校验数据。spill12.out.index不一定在磁盘上创建，如果内存（默认1M空间）中能放得下就放在内存中，即使在磁盘上创建了，和spill12.out文件也不一定在同一个目录下。每一次Spill过程就会最少生成一个out文件，有时还会生成index文件，Spill的次数也烙印在文件名中。索引文件和数据文件的对应关系如下图所示：

在Spill线程如火如荼的进行SortAndSpill工作的同时，Map任务不会因此而停歇，而是一无既往地进行着数据输出。Map还是把数据写到kvbuffer中，那问题就来了：只顾着闷头按照bufindex指针向上增长，kvmeta只顾着按照Kvindex向下增长，是保持指针起始位置不变继续跑呢，还是另谋它路？如果保持指针起始位置不变，很快bufindex和Kvindex就碰头了，碰头之后再重新开始或者移动内存都比较麻烦，不可取。Map取kvbuffer中剩余空间的中间位置，用这个位置设置为新的分界点，bufindex指针移动到这个分界点，Kvindex移动到这个分界点的-16位置，然后两者就可以和谐地按照自己既定的轨迹放置数据了，当Spill完成，空间腾出之后，不需要做任何改动继续前进。分界点的转换如下图所示：

Map任务总要把输出的数据写到磁盘上，即使输出数据量很小在内存中全部能装得下，在最后也会把数据刷到磁盘上。

5）Merge

• Map任务如果输出数据量很大，可能会进行好几次Spill，out文件和Index文件会产生很多，分布在不同的磁盘上。最后把这些文件进行合并的merge过程闪亮登场。

Merge过程怎么知道产生的Spill文件都在哪了呢？从所有的本地目录上扫描得到产生的Spill文件，然后把路径存储在一个数组里。

Merge过程又怎么知道Spill的索引信息呢？没错，也是从所有的本地目录上扫描得到Index文件，然后把索引信息存储在一个列表里。

到这里，又遇到了一个值得纳闷的地方。在之前Spill过程中的时候为什么不直接把这些信息存储在内存中呢，何必又多了这步扫描的操作？特别是Spill的索引数据，之前当内存超限之后就把数据写到磁盘，现在又要从磁盘把这些数据读出来，还是需要装到更多的内存中。之所以多此一举，是因为这时kvbuffer这个内存大户已经不再使用可以回收，有内存空间来装这些数据了。（对于内存空间较大的土豪来说，用内存来省却这两个io步骤还是值得考虑的。）

然后为merge过程创建一个叫file.out的文件和一个叫file.out.Index的文件用来存储最终的输出和索引，一个partition一个partition的进行合并输出。对于某个partition来说，从索引列表中查询这个partition对应的所有索引信息，每个对应一个段插入到段列表中。也就是这个partition对应一个段列表，记录所有的Spill文件中对应的这个partition那段数据的文件名、起始位置、长度等等。

然后对这个partition对应的所有的segment进行合并，目标是合并成一个segment。当这个partition对应很多个segment时，会分批地进行合并：先从segment列表中把第一批取出来，以key为关键字放置成最小堆，然后从最小堆中每次取出最小的输出到一个临时文件中，这样就把这一批段合并成一个临时的段，把它加回到segment列表中；再从segment列表中把第二批取出来合并输出到一个临时segment，把其加入到列表中；这样往复执行，直到剩下的段是一批，输出到最终的文件中。最终的索引数据仍然输出到Index文件中。

（2）Reduce端Shuffle

1. 复制copy
2. 排序归并merge

在Reduce端，shuffle主要分为复制Map输出、排序合并两个阶段。

1）Copy

Reduce任务通过HTTP向各个Map任务拖取它所需要的数据。Map任务成功完成后，会通知父TaskTracker状态已经更新，TaskTracker进而通知JobTracker（这些通知在心跳机制中进行）。所以，对于指定作业来说，JobTracker能记录Map输出和TaskTracker的映射关系。Reduce会定期向JobTracker获取Map的输出位置，一旦拿到输出位置，Reduce任务就会从此输出对应的TaskTracker上复制输出到本地，而不会等到所有的Map任务结束。

【Reducer如何知道自己应该拷贝处理哪些数据呢？】
因为Map端进行partition的时候，实际上就相当于指定了每个Reducer要处理的数据(partition就对应了Reducer)，所以Reducer在拷贝数据的时候只需拷贝与自己对应的partition中的数据即可。每个Reducer会处理一个或者多个partition。

【reducer如何知道要从哪台机器上去的map输出呢？】
map任务完成后，它们会使用心跳机制通知它们的application master、因此对于指定作业，application master知道map输出和主机位置之间的映射关系。reducer中的一个线程定期询问master以便获取map输出主机的位置。知道获得所有输出位置。

2）Merge Sort

Copy过来的数据会先放入内存缓冲区中，如果内存缓冲区中能放得下这次数据的话就直接把数据写到内存中，即**内存到内存merge**。

Reduce要向每个Map去拖取数据，在内存中每个Map对应一块数据，当内存缓存区中存储的Map数据占用空间达到一定程度的时候，开始启动内存中merge，把内存中的数据merge输出到磁盘上一个文件中，即**内存到磁盘merge**。

在将buffer中多个map输出合并写入磁盘之前，如果设置了Combiner，则会化简压缩合并的map输出。Reduce的内存缓冲区可通过mapred.job.shuffle.input.buffer.percent配置，默认是JVM的heap size的70%。内存到磁盘merge的启动门限可以通过mapred.job.shuffle.merge.percent配置，默认是66%。

当属于该reducer的map输出全部拷贝完成，则会在reducer上生成多个文件（如果拖取的所有map数据总量都没有内存缓冲区，则数据就只存在于内存中），这时开始执行合并操作，即磁盘到磁盘merge，Map的输出数据已经是有序的，Merge进行一次合并排序，所谓Reduce端的sort过程就是这个合并的过程。一般Reduce是一边copy一边sort，即copy和sort两个阶段是重叠而不是完全分开的。最终Reduce shuffle过程会输出一个**整体有序**的数据块。

shuffle过程中的三次排序：

在MapReduce的shuffle过程中通常会执行三次排序，分别是：

1. Map的溢写阶段：根据分区以及key进行快速排序—内存中
2. Map的合并溢写文件：将同一个分区的多个溢写文件进行归并排序，合成大的溢写文件。-----文件
3. Reduce输入阶段：将同一分区，来自不同Map task的数据文件进行归并排序------文件

此外，在MapReduce整个过程中，默认是会对输出的KV对按照key进行排序的，而且是使用快速排序。

1）快速排序：通过一趟排序将要排序的数据分割成独立的两部分，其中一部分的所有数据比另外一部分的所有数据都小，然后再按此方法对这两部分数据分别进行快速排序，整个排序过程可以递归进行，以此使整个数据成为有序序列。

2）归并排序：归并排序在分布式计算里面用的非常多，归并排序本身就是一个采用分治法的典型应用。归并排序是将两个（或两个以上）有序表合并成一个新的有序表，即把待排序序列分为若干个有序的子序列，再把有序的子序列合并为整体有序序列。

Hadoop(hdfs, yarn, mapreduce)理论详解_大宁哥的博客-优快云博客

HDFS读写流程（史上最精炼详细）_bw_233的博客-优快云博客_hdfs 读取

HDFS读写数据流程 - CoderZZZ - 博客园 (cnblogs.com)

深入浅出 Hadoop YARN - 知乎 (zhihu.com)

hadoop之mapreduce详解（基础篇） - 一寸HUI - 博客园 (cnblogs.com)

Hadoop生态之Mapreduce_小滴杂货铺的博客-优快云博客

Hadoop中的MapReduce是什么？体系结构|例 (guru99.com)

MapReduce shuffle过程详解！_<一蓑烟雨任平生>的博客-优快云博客_mapreduce shuffle过程详解

MapReduce shuffle过程详解_xidianycy的博客-优快云博客_mapreduce shuffle