YARN产生背景
MapReduce1.x存在的问题
在1.x版本中,架构也是master/slave的,对应的角色是分别是JobTracker和TaskTracker,一个作业可以拆分成MapTask和ReduceTask,一个JobTracker跟踪多个TaskTracker。
JobTracker负责资源的管理和状态的管理,TaskTracker定期向JobTracker汇报本节点的健康状态、本节点的资源使用情况,以及本节点task的任务执行情况。TaskTracker接收来自JobTracker的命令,例如启动一个作业,杀死一个作业。
这种架构存在的问题
- JobTracker是单节点的,整个集群只有一个JobTracker,如果这个节点挂掉之后,所有的客户端的作业就无法提交到集群运行。
- JobTracker负责client和TaskTracker之间的通信,所以JobTracker的压力会很大。
- 仅仅只能够支持MapReduce作业,无法执行其他的作业,例如Flink、spark等。
资源利用率&运维成本
所有的计算框架运行在一个集群中,共享一个集群的资源,做到按需分配。
YARN概述
- Yet Another Resource Negotiator
- 通用的资源管理系统
- 为上层应用(MapReduce、spark等计算框架)提供统一的资源管理和调度
YARN将JobTracker分为两个主要的部分,分别是资源管理和作业调度(作业监控),变成两个独立的进程。因此就有了一个ResourceManager(RM)
和每一个应用程序对应有一个ApplicationMaster(AM)
,例如提交了一个MapReduce作业,就会有一个MapReduce的ApplicationMaster(AM)
,如果提交了一个Spark作业,就会有一个Spark的ApplicationMaster(AM)
。一个作业要么是一个单独的作业(例如MapReduce),要么是一个DAG(相互有依赖的作业,A作业运完成后,运行B作业)作业。
ResourceManager
与NodeManager
共同组成了计算框架。ResourceManager
是一个的决定者,负责资源的管理。
YARN架构
- Client:向RM提交任务、杀死任务等
- ResourceManager(RM):集群中同一时刻对外提供服务的只有一个,负责资源相关。处理来自客户端的请求:包括提交、杀死。启动(监控)ApplicationMaster,监控NM
- NodeManager(NM):(可以有多个)。计算节点,向RM发送心跳信息、任务的执行情况、接收来自RM的请求来启动任务。处理来自ApplicationMaster的命令
- ApplicationMaster(AM):每个应用程序对一个AM,AM向RM申请资源,用于在NM上启动对应的Task。可以进行数据切分,为每个task向RM申请资源(Container)。任务的监控。
- master/slave:RM/NM
- container:任务的运行抽象。memory、CPU…。task运行在container里面的,可以运行AM、也可以运行map/reduce task
一个作业task提交给RM,现在NM上申请一个AM,然后AM向RM申请资源,申请到资源后,到对应的NM上自动Container,然后在Container上启动Map Task和Reduce Task。AM监控Container
YARN执行流程
- 第1步:客户端先提交应用程序到Resource Manager
- 第2步:Resource Manager为作业分配第一个NodeManager
- 第3步:Resource Manager要求在NodeManager中启动了一个Container来运行作业的Application Master
- 第4步:Application Master启动之后,首先要注册到Resource Manager上,因为Resource Manager要负责全局的资源管理,而Application Master是对应于每一个应用程序的,所以需要首先注册到Resource Manager,这样就可以直接通过Client查询到作业的执行情况(Application Master注册在Resource Manager,而Client可以跟Resource Manager进行通信)
- 第5步:到具体的NodeManager中启动Container跑Task
Application Master是直到具体的Task的执行情况的。
这个执行流程不仅仅是针对MapReduce,对于Spark也是一样的。Spark仅仅是对于Application Master不同而已