Hadoop中MapTask&ReduceTask源码解析（非常详细请耐心看完）、MapReduce内核源码解析、MapTask&ReduceTask工作机制、ReduceTask并行度决定机制

13.MapReduce框架原理

13.5 MapReduce 内核源码解析

13.5.1 MapTask 工作机制

（1）Read阶段：MapTask通过InputFormat获得的RecordReader，从输入InputSplit中解析出一个个key/value。
（2）Map阶段：该节点主要是将解析出的key/value交给用户编写map()函数处理，并产生一系列新的key/value。
（3）Collect收集阶段：在用户编写map()函数中，当数据处理完成后，一般会调用OutputCollector.collect()输出结果。在该函数内部，它会将生成的key/value分区（调用Partitioner），并写入一个环形内存缓冲区中。
（4）Spill阶段：即“溢写”，当环形缓冲区满后，MapReduce会将数据写到本地磁盘上，生成一个临时文件。需要注意的是，将数据写入本地磁盘之前，先要对数据进行一次本地排序，并在必要时对数据进行合并、压缩等操作。
溢写阶段详情：
步骤1：利用快速排序算法对缓存区内的数据进行排序，排序方式是，先按照分区编号Partition进行排序，然后按照key进行排序。这样，经过排序后，数据以分区为单位聚集在一起，且同一分区内所有数据按照key有序。
步骤2：按照分区编号由小到大依次将每个分区中的数据写入任务工作目录下的临时文件output/spillN.out（N表示当前溢写次数）中。如果用户设置了Combiner，则写入文件之前，对每个分区中的数据进行一次聚集操作。
步骤3：将分区数据的元信息写到内存索引数据结构SpillRecord中，其中每个分区的元信息包括在临时文件中的偏移量、压缩前数据大小和压缩后数据大小。如果当前内存索引大小超过1MB，则将内存索引写到文件output/spillN.out.index中。
（5）Merge阶段：当所有数据处理完成后，MapTask对所有临时文件进行一次合并，以确保最终只会生成一个数据文件。
当所有数据处理完后，MapTask会将所有临时文件合并成一个大文件，并保存到文件output/file.out中，同时生成相应的索引文件output/file.out.index。
在进行文件合并过程中，MapTask以分区为单位进行合并。对于某个分区，它将采用多轮递归合并的方式。每轮合并mapreduce.task.io.sort.factor（默认10）个文件，并将产生的文件重新加入待合并列表中，对文件排序后，重复以上过程，直到最终得到一个大文件。
让每个MapTask最终只生成一个数据文件，可避免同时打开大量文件和同时读取大量小文件产生的随机读取带来的开销。

13.5.2 ReduceTask工作机制

（1）Copy阶段：ReduceTask从各个MapTask上远程拷贝一片数据，并针对某一片数据，如果其大小超过一定阈值，则写到磁盘上，否则直接放到内存中。
（2）Sort阶段：在远程拷贝数据的同时，ReduceTask启动了两个后台线程对内存和磁盘上的文件进行合并，以防止内存使用过多或磁盘上文件过多。按照MapReduce语义，用户编写reduce()函数输入数据是按key进行聚集的一组数据。为了将key相同的数据聚在一起，Hadoop采用了基于排序的策略。由于各个MapTask已经实现对自己的处理结果进行了局部排序，因此，ReduceTask只需对所有数据进行一次归并排序即可。
（3）Reduce阶段：reduce()函数将计算结果写到HDFS上。

13.5.3 ReduceTask并行度决定机制

回顾：MapTask并行度由切片个数决定，切片个数由输入文件和切片规则决定。
思考：ReduceTask并行度由谁决定？

13.5.3.1 设置ReduceTask并行度（个数）

ReduceTask的并行度同样影响整个Job的执行并发度和执行效率，但与MapTask的并发数由切片数决定不同，ReduceTask数量的决定是可以直接手动设置：
// 默认值是1，手动设置为4
job.setNumReduceTasks(4);

13.5.3.2 实验：测试ReduceTask多少合适

（1）实验环境：1个Master节点，16个Slave节点：CPU:8GHZ，内存: 2G
（2）实验结论：

13.5.3.3 注意事项

（1）ReduceTask=0，表示没有Reduce阶段，输出文件个数和Map个数一致。
（2）ReduceTask默认值就是1，所以输出文件个数为一个。
（3）如果数据分布不均匀，就有可能在Reduce阶段产生数据倾斜
（4）ReduceTask数量并不是任意设置，还要考虑业务逻辑需求，有些情况下，需要计算全局汇总结果，就只能有1个ReduceTask。
（5）具体多少个ReduceTask，需要根据集群性能而定。
（6）如果分区数不是1，但是ReduceTask为1，是否执行分区过程。答案是：不执行分区过程。因为在MapTask的源码中，执行分区的前提是先判断ReduceNum个数是否大于1。不大于1肯定不执行。

13.5.4 MapTask & ReduceTask 源码解析

13.5.4.1 MapTask 源码解析流程

运行前在这里context.write(outK, outV);打上断点。

这里强行进入会进入环形缓冲区，我们来看看是不是，点击强行进入这里是write方法，继续强行进入

这里是write方法，继续强行进入

这个是collect收集器，第一次强行进入则会进到我们自己编写的partitioner分区
这个是自己写的partitioner分区，然后快速通过

再次强行进入

collect这里就是环形缓冲区

这些都是初始化过程，一直点下一步就行，点到下图的位置

这里是存储元数据的（可以说是索引吧，不太确定）

this.keySerializer.serialize(key);为什么要序列化，如果MapTask在Hadoop102，ReduceTask在Hadoop103，则key需要跨节点的通讯，则必须支持序列化

这部分一直下一步，看keystart=kvbidx，valstart=kvbend值的变化情况，直到下图停止下一步

这里是存储meta的值

这里的kvindex的值可以通过公式计算
debug到这里，就要写出去一条了，context是一条一条的写

往下走，点击下一步

往下走，点击下一步

往下走，点击下一步

写完一行后要写下一行，往下走，点击下一步

又回到map里面了，在这里强行进入

到这里出去

在这里强行进入

到这里在出去

到这里在点下一步，而不是强行进入

又回到了这里context.write(outK, outV);要一行一行读入，因为我的输入文件特别小，所以达不到环形缓冲区的最大溢写条件，则会将输入文件里的数据全读完再溢写

1	13736230513	192.196.100.1	www.baidu.com	2481	24681	200
2	13846544121	192.196.100.2			264	0	200
3 	13956435636	192.196.100.3			132	1512	200
4 	13966251146	192.168.100.1			240	0	404
5 	18271575951	192.168.100.2	www.baidu.com	1527	2106	200
6 	84188413	192.168.100.3	www.baidu.com	4116	1432	200
7 	13590439668	192.168.100.4			1116	954	200
8 	15910133277	192.168.100.5	www.hao123.com	3156	2936	200
9 	13729199489	192.168.100.6			240	0	200
10 	13630577991	192.168.100.7	www.shouhu.com	6960	690	200
11 	15043685818	192.168.100.8	www.baidu.com	3659	3538	200
12 	15959002129	192.168.100.9	www.baidu.com	1938	180	500
13 	13560439638	192.168.100.10			918	4938	200
14 	13470253144	192.168.100.11			180	180	200
15 	13682846555	192.168.100.12	www.qq.com	1938	2910	200
16 	13992314666	192.168.100.13	www.gaga.com	3008	3720	200
17 	13509468723	192.168.100.14	www.qinghua.com	7335	110349	404
18 	18390173782	192.168.100.15	www.sogou.com	9531	2412	200
19 	13975057813	192.168.100.16	www.baidu.com	11058	48243	200
20 	13768778790	192.168.100.17			120	120	200
21 	13568436656	192.168.100.18	www.alibaba.com	2481	24681	200
22 	13568436656	192.168.100.19			1116	954	200

这个是我的数据

全速运行，让这里的outK出现最后一个数据13568436656，因为有两个，所以要看清

最后一条数据，outK的颜色会变灰，大家可以根据这个判断一下

在这里强行进入

在这里强行进入

在这里强行进入

在这里强行进入

然后出来

在这里强行进入

又进来这个环形缓冲区了，这是最后一遍了，和上面的过程一样，就直接跳过了

一直下一步，他不会进入map方法，而是到cleanup里面了

然后下一步，多次下一步，到达下图位置

在这里打上断点
强行进入该方法，查看在close前都做了些什么

在这两处打上断点，this.collector.flush();这个是将数据刷到磁盘上，我们进去看看他是如何刷到磁盘上的，点击强行进入

进来之后，他是要进行快排的，我们往下找看看有没有快排，一直点下一步，直到下图位置

在这里打上断点

这里是快排和溢写

强行进入

this.sorter.sort(this, mstart, mend, this.reporter);在这里打上断点，这里是快排的逻辑，一直下一步，到下图位置

到这一步强行进入

第一次强行进入会进入到getMaxDepth(r - p)这里面

然后退出来

再次强行进入

下面这些就是快排的逻辑

简单看一下里面的逻辑，然后退出来

然后再继续往下走

到这里相当于排完序了，然后继续下一步，该溢写了，溢写的话我这个有5个分区，只会溢写出一个文件，他是有索引来标记是哪个分区的，然后我们看一个文件D:\tmp\hadoop-73631\mapred\local\localRunner\73631\jobcache\job_local837257542_0001\attempt_local837257542_0001_m_000000_0\output，这个你看你自己的就行在下图的位置从此处打开有一个文件

打开里面是一个空的文件，然后继续下一步

从这里可以看出他是根据索引快排，没有动原始的数据，然后一直下一步，直到下图的位置

到达这个位置，0号分区已经写完了，再点击下一步则开始写1号分区

到这里，我们去看看那个文件里面有没有内容

里面已经有内容了

在这里打上断点，开始全速运行，执行到4就停止执行，看下图

一直进行下一步到下图的位置

这里将他解锁

提前在这里打断点

溢写完数据了，这里要进行归并排序，强行进入看看，然后下一步到如下位置

这里开始遍历溢写文件

由于我的数据少，他生成了一个文件，他也会象征性的去循环一下，继续下一步到如下位置

如果只有一个溢写文件，则就是最后的输出文件，然后一直下一步，到如下位置

则排序结束

则这里会多出一个文件，这个index文件则是告诉reducemask数据存放在file.out的位置，然后继续下一步，到如下的位置
到这里MapTask阶段就结束了，到这里先别动，看下面如何打断点，在继续下一步

=================== MapTask ===================
context.write(k, NullWritable.get()); //自定义的map方法的写出，进入
output.write(key, value);
//MapTask727行，收集方法，进入两次
collector.collect(key, value,partitioner.getPartition(key, value, partitions));
HashPartitioner(); //默认分区器
collect() //MapTask1082行 map端所有的kv全部写出后会走下面的close方法
close() //MapTask732行
collector.flush() // 溢出刷写方法，MapTask735行，提前打个断点，进入
sortAndSpill() //溢写排序，MapTask1505行，进入
sorter.sort() QuickSort //溢写排序方法，MapTask1625行，进入
mergeParts(); //合并文件，MapTask1527行，进入

collector.close(); //MapTask739行,收集器关闭,即将进入ReduceTask

13.5.4.2ReduceTask源码解析流程

搜索这个，然后选择第一个

然后ctrl+f搜索isMapOrReduce这个，然后再这行打上断点，然后再继续下一步，一直到如下位置

这里一定要提前打上断点，否则抓不到这个位置

这里上来就是3个阶段，copy，sort，reduce，会走5遍，因为有5个分区，然后进行下一步操作，一直到如下位置

在此处打上断点，首先强行进入会进入到this.getJobID()里面，然后退出来，再次强行进入，到如下图

在这里打上断点，害怕跑偏，然后下一步，直到下图位置

这里是新旧API的兼容问题，使用新的API继续下一步，到如下位置

运行到Path outputPath = FileOutputFormat.getOutputPath(this.conf);这个位置，鼠标放到outputFormat这个上面，默认情况下，可以看到使用的是TextOutputFormat

然后退出来

然后一直下一步，到如下位置

在 shuffleConsumerPlugin.init(shuffleContext);和this.sortPhase.complete();这两个地方打上断点

然后强行进入这个方法，看他初始化了那些内容

进来后在此处打上断点，当他是new对象的时候要进入里面在里面打上断点，如下图

这样就是最靠谱的

然后退出来

一直下一步到红框处

点击下一步

进入到这里

这里是获取有多少个MapTask，以此ReduceTask来拉取的时候知道需要拉几个

然后退出来
这里也需要打上断点
然后走到这个位置，强行进入

在进入这个里面打断点

在这里打上断点，然后点上方返回

然后点下一步

前面是各种初始化，因为马上要拉取数据了，而数据要放在内存上，内存不够了放磁盘上，一直点下一步，到如下图位置

先准备好内存和磁盘，初始化工作做好，在进行拉取数据，然后一直点下一步就行

在这里rIter = shuffleConsumerPlugin.run();打上断点，然后强行进入

在这三处打上断点，然后一直下一步，到如下图位置

从名字上可以看出来，这步是ReduceTask从MapTask上抓取数据，然后继续下一步，到如下图位置

到这里就抓取数据完毕了，然后继续往下走，到如下图位置

copy结束，当前阶段切换成SORT阶段，然后继续往下走，到如下图位置

先在下面红框打上断点，sort结束了，当前阶段切换成REDUCE阶段，然后继续往下走，到如下图位置

到这个地方，强行进入

然后继续往下走，到如下图位置

提前在此处打上断点，强行进入

进入到这里了，这里是初始化，关闭，正常的reducer的聚合

这里要提前打断点，然后继续往下走，到如下图位置

到这里是将相同的key往外写，（这里我的例子是相同的手机号往外写总的流量），然后强行进入

强行进入

强行进入

在这里打上断点，下一步

到这里，先写的key，看他是如何写的，强行进入

给他打上断点，然后继续往下走，到如下图位置

看他是如何写的，强行进入

进来后给这行代码打上断点，然后继续往下走，到如下图位置

到这里强行进入

下一步

强行进入

下一步

强行进入

强行进入

强行进入

然后继续往下走，到如下图位置

以上key已经写完了，开始写value了，强行进入，然后继续往下走，到如下图位置

强行进入

就到了自己定义的flowBean，根据自己定义的格式往外写，然后一个key就写完了，但是MapTask里面有多个key，然后继续往下走，到如下图位置

key变成了13736230513，直到这个分区全部写出去

全速运行

就到这个地方了，开启下一个ReduceTask，结束了上一个ReduceTask。

后面就和之前步骤一样了，就不展示了

=================== ReduceTask ===================
if (isMapOrReduce())  //reduceTask324行，提前打断点
initialize()   // reduceTask333行,进入
init(shuffleContext);  // reduceTask375行,走到这需要先给下面的打断点
        totalMaps = job.getNumMapTasks(); // ShuffleSchedulerImpl第120行，提前打断点
         merger = createMergeManager(context); //合并方法，Shuffle第80行
			// MergeManagerImpl第232 235行，提前打断点
			this.inMemoryMerger = createInMemoryMerger(); //内存合并
			this.onDiskMerger = new OnDiskMerger(this); //磁盘合并
rIter = shuffleConsumerPlugin.run();
		eventFetcher.start();  //开始抓取数据，Shuffle第107行，提前打断点
		eventFetcher.shutDown();  //抓取结束，Shuffle第141行，提前打断点
		copyPhase.complete();   //copy阶段完成，Shuffle第151行
		taskStatus.setPhase(TaskStatus.Phase.SORT);  //开始排序阶段，Shuffle第152行
	sortPhase.complete();   //排序阶段完成，即将进入reduce阶段 reduceTask382行
reduce();  //reduce阶段调用的就是我们自定义的reduce方法，会被调用多次
	cleanup(context); //reduce完成之前，会最后调用一次Reducer里面的cleanup方法