MapReduce

源码讲解

shuffle过程

1.圆环代表buffer环，不断的有k，v往里存储，超过一定的量就会发生溢写

2.溢写需要把这个数据拉取出来，但是不知道每个数据的位置，那么就需要在圆环数据记录的起始位置往另外一边，记录四个量，大概占用16B

3.默认溢写，是大于数组大小的80%就会触发

4.溢写的区域就会被锁定，会被拉取并清除，剩下的区域会开辟一个赤道，也就是剩余区域的中心位置，kv值和位置信息分别从两边读取，若触发下一次溢写，仍然按照上述算法执行

map初始化阶段主要做了什么事情

map任务启动，一个切片对应一个文件，对这个文件发起一个io，对这个文件执行一个seek方法，参数是切片的偏移量，就从开始的阶段开始读

在读取数据的过程中如果不是这个文件的第一行，在初始化的过程中，会抛弃读取的第一行数据，原因是那一行数据有可能被block给截断，所以要让上一个切片多读一行保证数据的完整

nextKeyValue详解

nextKeyValue的代码key其实就是偏移量pos，value就是文本内容，pos会根据读取数据将偏移量往上加，内容也会跟着变化。所以，nextKeyValue在执行过程中，key和value是不停跟着在变的

整个map写入的过程

这个时候进入map的写入的过程，将数据根据kv生成一个p，序列化添加进buffer缓冲区中，若缓冲区达到设置的上线就会发生溢写，将数据根据记录进行拉取，并且排序，合并生成一个小文件，等待着reducetask进行处理

reduce过程

在reduce中有两组迭代，一组时迭代key，还有一组是迭代相同key的分组数据，又一次用到了reduce的原语：相同的key为一组，调用一次reduce的方法，在reduce方法中迭代这一组数据进行计算

基本理解

map

映射为K，V模型

并行分布式

计算向数据移动

reduce

对数据进行全量/分量加工

相同的key汇聚到reduce task中

一个reduce task可以包含多个key，由分区器控制

rduce原语（很重要，要记住）

相同的key为一组，调用一次reduce方法，在reduce方法中迭代这一组数据进行计算

架构

Hadoop1.0架构

角色

· JobTracker

• 核心，主，单点

• 调度所有的作业

• 监控整个集群的资源负载

· TaskTracker

• 从，自身节点资源管理

• 和JobTracker心跳，汇报资源，获取Task

· Client

• 作业为单位

• 规划作业计算分布

• 提交作业资源到HDFS

• 最终提交作业到JobTracker

问题

· JobTracker：负载过重，单点故障

· 资源与计算强耦合，其他计算框架需要重复实现资源管理，例如如果用spark也要进行调用，不知道哪个是被MapReduce调用的

· 不同框架对资源不能全局管理

运行过程

· 1.Client如果有一个map的请求，然后去NN中寻找相关文件的位置

· 2.Client再把请求发送到JT中，TT和JT是通过心跳机制进行通信，TT和JT进行心跳过后，发现有map请求，那么就在数据所在的那个节点，或者空闲临近的节点开始进行map处理

· 3.map完成之后，TT和JT进行心跳通信，发送map完成，需要reduce，那么就JT就选择若干个节点进行reduce

· 4.reduce根据分区拉取对应map节点的数据，最后进行合并

Hadoop2.0架构

角色

· YARN：解耦资源与计算

• ResourceManager

• 主，核心

• 集群节点资源管理

• NodeManager

• 与RM汇报资源

• 管理Container生命周期

• 计算框架中的角色都以Container表示

• Container：【节点NM，CPU,MEM,I/O大小，启动命令】

• 默认NodeManager启动线程监控Container大小，超出申请资源额度，kill

• 支持Linux内核的Cgroup

· MR

• ApplicationMaster-Container

• 作业为单位，避免单点故障，负载到不同的节点

• 创建Task需要和RM申请资源（Container）

• Task-Container

• 执行任务的单元

· Client

• RM-Client：请求资源创建AM

• AM-Client：与AM交互

运行过程

· 1.用户向YARN中提交应用程序，其中包括ApplicationMaster程序、启动ApplicationMaster的命令、用户程序等。

· 2.ResourceManager为该应用程序分配第一个Container，并与对应的Node-Manager通信，要求它在这个Container中启动应用程序的ApplicationMaster

· 3.ApplicationMaster首先向ResourceManager注册，这样用户可以直接通过ResourceManager查看应用程序的运行状态，然后它将为各个任务申请资源，并监控它的运行状态，直到运行结束，即重复步骤4~7

· 4.ApplicationMaster采用轮询的方式通过RPC协议向ResourceManager申请和领取资源

· 5.一旦ApplicationMaster申请到资源后，便与对应的NodeManager（在对应数据所在的节点）通信，要求它启动任务，首先执行map task

· 7.各个任务通过某个RPC协议向ApplicationMaster汇报自己的状态和进度，以让ApplicationMaster随时掌握各个任务的运行状态，从而可以在任务失败时重新启动任务

· 8.应用程序运行完成后，ApplicationMaster向ResourceManager注销并关闭自己

在资源管理中，一切皆container

· 6.当map task执行完后，ApplicationMaster会向RM申请资源，申请到后NodeManger，会创建环境，将数据拉去到对应节点，并执行reduce task