大数据学习(05)——MapReduce/Yarn架构
Hadoop1.x中的MapReduce
MapReduce作为Hadoop最核心的两个组件之一,在1.0版本中就已经存在了。它包含这么几个角色:
- Client
- 多数情况下Client的作用就是向服务端发送请求并返回结果。但是在MapReduce里,Client的作用可不小。
- Client根据传入的数据参数,向HDFS的NameNode获取元数据信息,计算出Map任务的split切片信息。split跟Block有映射关系,Client可以计算出split在文件中的偏移量,再根据计算向数据移动的原则,建议JobTracker将计算程序移动到哪些主机节点。
- Client生成计算程序的配置文件。
- Client将程序jar包、split清单、xml配置文件上传到HDFS的目录中(10副本,避免多个Map任务读取程序文件造成瓶颈)。
- Client调用JobTracker启动计算程序,告知计算需要的文件放在哪里。
- JobTracker
- 主从架构中的主节点,像HDFS中的NameNode。它有两个作用:资源管理和任务调度。
- 从HDFS获取split清单。
- JobTracker收到TaskTracker心跳时,记录下TaskTracker当前的资源情况,为任务调度做准备。
- 按照计算向数据移动的原则,根据资源使用情况为任务分配离数据最近的TaskTracker。
- TaskTracker
- 主从架构中的从节点,像HDFS中的DataNode,相同的架构会出现在大数据技术的多个地方。
- 为尽量实现本地计算而不需要网络传输,通常TaskTracker和HDFS的DataNode在相同主机上。
- 与JobTracker的每次心跳时,汇报自身的资源状况。
- 心跳时从JobTracker获取MapReduce任务。
- 从HDFS下载计算程序相关的文件,启动MapTask/ReduceTask。
在上面的架构中,JobTracker要为所有的计算任务做调度,而且全局只有一个进程不利于水平扩展。这个架构最大的缺点是单点故障风险,另外资源和调度耦合太高,资源管理难以扩展到其他计算框架。为了解决上述问题,在Hadoop2.x中,MapReduce的资源管理被切割出来,成为一个独立的资源管理模块Yarn。
MapReduce on Yarn
为了解决MapReduce1.x中存在的问题,Hadoop2.x中增加了Yarn模块,专门用来做资源管理。
Yarn包含角色:
- Resource Manager
- 负责整体资源的管理
- 在客户端发起计算任务时,选择空闲资源多的节点,通知Node Manager启动Container
- Node Manager
- 与Resource Manager心跳时,报告自身主机节点的资源情况
- 接收Resource Manager的指令,启动Container
- ApplicationMaster
- 相当于JobTracker不带资源管理功能,只负责任务调度
- Container
- 可用资源的集合,执行具体的计算任务
- 反射生成计算任务的实例
MapReduce包含角色:
- MRClient
- 将split切片清单、xml配置、程序jar上传到HDFS
- 向Resource Manager发请求,申请创建AppMaster
- MRAppMaster
- 在Container中反射生成MRAppMaster
- 从HDFS下载split切片清单
- 向Resource Manager申请执行计算任务的资源
- 向Name Manager分配的Container中调度计算任务并监控其运行状态
- Task
- Container反射生成计算任务的实例,执行Map/Reduce计算任务
新架构解决了MapReduce1.x中的痛点。它的任务调度进程MRAppMaster是每个客户端作业对应一个,单点故障不再是全局性的,并且MRAppMaster和Container都有失败重试的功能,分别由ResourceManager和MRAppMaster来完成重试的动作。任务调度压力也分散到不同的进程里。不同的计算框架可以共用Yarn的资源管理功能。
Yarn本身也是高可用架构,通过Zookeeper选主,架构如下图
这个架构图是不是跟HDFS里的NameNode高可用非常像?可以看到主备高可用的方案都是相似的,可以说是形成了一种设计模式。
这个图比NameNode少了ZKFS这个角色,不是说它不需要了,而是它更方便地集成到ResourceManager中去了。