学习Hadoop(五)源码阅读，部分底层原理

1、Job，创建进程、完成作业细则、提交作业。向上追踪源码到MRJobConfig类，发现这里定义了大量的默认配置。

例：maptasjk执行时可申请的最大内存，默认为1G。

2、此为提交作业。既作业提交给集群，集群验证分析后执行。那么，提交后，map阶段之前处于进行分片阶段，之所以默认分片后片的大小默认为块的大小因为如此。minSize默认为1B maxSize默认为long的最大值。blockSize为块的大小。

通过这两部分代码来看：分片后，每个片都会包含block的位置信息（包括副本的）等信息。

以上即为作业提交后，map处理前的注意部分。

2、map部分。

client将配置好的job发送给yarn yarn会找资源合适的服务器开启container,container中会有shell脚本启动yarnchild类，这个类开启applicationmanager线程，此线程根据resourcemanager指定与确认会在响应节点上在创建mappertask、reducetask.这两个task就是两个类用于激活mapper和reducer(通过反射创建对象，然后启动run方法进而执行各自的重写的map/reduce方法).

这里保证了除了第一个切片，其他切片忽略本切片第一行，且到下一片多读一行。这种机制保证了block或片合并后，切割处的数据还原。

map方法执行后数据写入缓冲区（MapOutputBuffer）。

数据通过map映射为key-value格式 同时每个kv还有分区信息（分区数量根据reduce来决定）。当不设置reduce 默认为1.

spillper(溢写器)。缓冲区大小默认为100M，溢写器默认值为0.8既map写入缓冲区，缓冲区达到80%则开始写入磁盘生成一些小文件（同时读写，防止阻塞）。（这里的溢写的比例需要调整以符合业务需求。），同时这些分区排序，分区内部也排序。这里注意在排序的同时可以进行combiner(压缩，可以理解为微型reduce的工作，注意别乱用，分情况使用)，最后小文件要合并（如果之前使用了combiner，这里还可能再combiner一次。比如小文件数量很少就没有必要了，默认为三个以上combiner），然后发送给reduce。注意溢写时是由spillThread溢写线程进行排序和溢写的。还有最后数据部分进入缓冲区是可能达不到80%这时需要flush一下，清空缓冲区数据。

缓冲区中k-v模式的数据存入时会建立一个索引（16B，4个int）,第一个将存放key的起始位置，第二个是value的位置，第三个放value结束位置，第四个是分区信息。提升了检索效率，但是在达到溢写条件同时读写数据时为避免数据冲撞，缓冲区设计为环形缓冲区。

3、reduce部分；简单来说reduce对相同key的value值做一个归并。

第一阶段，shuffle。通过http协议将众多map产生的文件拉取过来。过程中将众多文件归并成为几个文件。

第二阶段，sort,主要是部分业务场景中，map实现的排序规则可能不符合reduce的需求，这是需要重新写个组排序器。

第三阶段，reduce,归并计算。每一组调用一次reduce。

注意，这里的可不是内容的重新排序。reduce不对内容重新排序。只是再不改变内容顺序下，重新界定key是否相等。

ps:map源码看懂了七七八八，reduce源码还是有些欠缺。抽空多看下