Hadoop学习笔记[5]-Yarn介绍
分布式计算简单的说就是要将计算任务分发给不同的计算节点,这其中很自然的就会遇到两个问题:
- 资源管理
- 任务调度
资源管理负责监控计算节点的负载情况,任务调度负责派发具体的任务到计算节点,本文说的Yarn主要就是用于资源管理
1、Yarn之前
Hadoop在2.X之后进行了比较大规模的重构,比较大的一块就是集群新增了Yarn这个角色,在Hadoop1.X的时候,负责集群资源管理和任务调度的角色叫JobTracker和TaskTracker,只能支持MR,整个集群的部署图如下:
结合上面的图说一下MR任务的提交计算流程:
- 1)、客户端(MR Cli)会根据计算的数据咨询hdfs的NN(通过Hdfs Cli)获取元数据,计算出split清单,主要切片位置信息【每个切片的偏移量、服务器等】,split计算完成后即可知道map任务的数量
- 2)、客户端会生成未来运行MR程序的相关配置文件【所有的配置信息写入xml文件】
- 3)、客户端将运行的jar包、配置文件、切片清单存储到hdfs,存储到hdfs后其他节点都可以从hdfs下载,不需要逐台机器分发
- 4)、提交计算任务到JobTracker,也就是通知jobTracker可以启动计算任务,并且告知它计算所需文件在hdfs中的位置(也就是步骤3的文件)
- 5)、JobTracker负责集群的资源管理和任务调度,JobTracker先从Hdfs取回该任务的切片清单,并根据自己掌握的资源情况【计算节点的资源情况由TaskTracker定时汇报】最终确定每个split应该由哪个节点计算,也就是map任务在哪些节点启动,TaskTracker在向JobTracker发送心跳信息是会取回自身需要负责计算的split清单(每个split一个map任务)
- 6)、TaskTracker负责计算任务具体的执行,并汇报资源给JobTracker,TaskTracker取回任务后,会从Hdfs下载运行程序jar包、配置文件到本机,最终启动任务计算
这个架构主要存在两个问题:
- 1)、JobTracker压力过大,且存在单点故障问题主
- 2)、只支持MR,其余分布式计算框架不能复用(思考一下,无论是哪一种分布式计算框架,虽然计算层的实现不一样,但是资源管理其实大同小异,都是从集群中选择一些计算节点启动计算任务)
为了解决这个问题,Hadoop2.X设计了Yarn,可以看成是一个阉割版的JobTracker,保留了其资源管理的功能
2、Yarn
Hadoop2.X的Yarn的基本架构(官网有张图片更加形象生动一点)如下:
图中两个cli代表的是两个不同的计算框架,也就是说,yarn不仅支持MR,其余计算框架只要实现了Yarn的接口,都可以使用Yarn进行资源管理,Resourcemanager是主节点,NodeManager是从节点,和TaskTracker类似,NodeManger会向Rm汇报自身的资源情况【内部使用的系统的cgroup技术进行资源的隔离,没深入研究过这个】,和Hdfs不同的是,yarn出现的晚,所以设计之初就考虑了HA,所以不需要像HDFS那样设计单独的单独的ZKFC角色,但是也要借助ZK实现HA
还是以MR为例,说一下有了Yarn之后,MR的程序提交流程:
- 1)、客户端(Cli)做的事情还是和之前一样,计算切片清单和上传文件到hdfs,只是从通知JobTracker变成通知RM启动计算任务
- 2)、RM会从自身掌握的资源情况,从NM中挑选一台启动应用程序主节点 APP Master【APP mstr负责具体的任务调度,类似于没有资源管理功能的JobTracker,不同的是JobTracker负责管理所有的任务,而App Mstr只负责某个具体的计算任务,解决了JobTracker的单点故障问题,并可以做负载均衡(不同计算任务可以由运行在不同节点的APP MStr管理),并且可以失败重试,APP Mstr故障重试后需要恢复作业执行状态,会从hdfs存储的作业日志进行恢复,具体还没研究】
- 3)、APP Mstr从Hdfs取回切片清单,并向RM申请计算资源,RM挑选一批NM分配Contaner实际进行计算,每个Container都是一个JVM进程,这一批Container会反向注册到App Mstr,App Mstr将具体的Map和Reduce任务调度给Container运行【不是发代码到Container,只是发个消息,具体运行的代码Container从hdfs下载】,如果某个Container失败了,App Mstr会向RM申请新的Container运行失败的任务
以上就是关于Yarn的基本介绍,因为平时工作中没涉及资源管理相关的工作,所以未深入研究,只是大概了解,如有不对的地方,欢迎指正