MapReduce源码阅读

本文主要是介绍MapReduce源码阅读，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

 MapReduce运行流程图：

个人感悟：

1. maptask中的InputFileReader组件读取的是hdfs中默认的一个block大小的文件，即128M,在mr中一个数据块即为一个split；
2. 环形缓冲区其实为一个连续内存的字节数组，大小默认为100M，达到80%进行磁盘溢写；
3. 从环形缓冲区中溢写出的文件spill都为有序的文件，多个spill合并成一个Merge文件和一个索引文件,标记从哪到哪属于哪个reduce的分区，提高后期reduce拉取map端输出数据的效率；
4. reducer端从map输出端拉取使用协议为http，不停的拉取数据后将数据放在缓冲中进行在内存中进行合并；
   
5. reducer端中的reduce函数使用的输入数据来源有2个：
   1. 　数据量较小时，直接使用内存中的数据作为数据输入源；
   2.    数据量大时，则使用多次从reducer端内存溢写合并的文件作为数据的输入源头；
6. Reducer端中输入的File有序的必要性：
   
   1. 　如果无序则相同key进行汇总数据时候需要遍历很多次；
   2. 　如果有序则reduce方法汇总数据的时候只需要遍历一次；
7. Mapper端在环形缓冲区对数据进行排序的必要性：      环形缓冲区存在必要性：实现数据在mapper端的排序自由；
   1. 　对环形缓冲区中的数据进行排序后，reducer端拉取数据后在内存中即可以使用更高效的归并排序对拉取后所有的数据进行排序来提高排序的高效性；　
   2.    Reducer端拉取数据来源为磁盘，如果想要实现对拉取数据高效性，可以使用数据提前在mapper端进行排序好；
8. mapper端环形缓冲区溢写的多个有些spill磁盘文件后，spill合并成merge时候会再次启用一次归并排序；
9. 常用的分区方式：hashPartitioner、rangePartitioner、Robin、自定义等，mapper端合并溢写的数据后数据并不一定是按照分区编号均匀的分布，所有可能导致reducer端拉取数据后产生数据倾斜；
10. Reducer端拉取数据到内存中后也会按照拉取不同mapper端的有序文件数据再进行一次归并排序；
11.  每个mapper端只输出一个mapper文件，不设计成一个分区一个文件的设计方式：　  mapper端spill文件merge并不是等所有的spill都溢写完成才开始进行合并，默认溢写3个文件就开始进行文件合并；
    • 如果reducer的设置数据量太多，则可能会产生太多的小文件。
12.  Reducer中缓存的大小也是为100M；

笔记：

mapper阶段溢出的磁盘文件的组织形式：
1,a,1
1,a,2
1,a,1
1,b,1
1,b,2
...
1,z,22
2,c,1
2,f,1
2,f,22

reducer的输入大文件的格式：
a,1
a,2
a,1
a,2
a,1
a,2
a,1
a,1
.....
b,1
b,1
b,2

FileInputSplit核心类：

Mapper核心类：

 Reducer核心类：

 ========================================================== =========================================================== =========================================================== ===================================

Mapreduce执行过程：

1、程序的入口

 2、程序进行提交

 3、

4、

 5、 任务真正提交

 6、提交任务

这篇关于MapReduce源码阅读的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！