YARN——任务提交启动流程
【概述】
学习yarn，就不得不涉及yarn的任务运行流程，虽然网上有很多文章进行相关的总结，但总觉得是别人，因此还是按照自己的理解，进行总结分享，也算是对过程的输出交付。
【名词概念】
首先来说明下yarn中的一些概念，后续流程中都会涉及到。
ResourceManager（RM）
负责整个集群的资源管理和分配，处理客户端和AM的请求，为containr分配资源（将任务调度到不同的NM上运行），同时通过NM的心跳获取所有container的运行状态，并进行必要的失败重试。
NodeManager（NM）
集群资源（CPU和内存，还包括GPU等）的实际拥有者，接收RM和AM的请求，启动具体的container，并通过心跳向RM汇报container的运行情况。
Application
对应1.X版本中的job，它可以是一个MapReduce应用，也可以是一个spark应用，或者flink应用等。
ApplicationMaster（AM）
每个Application都有一个ApplicationMaster，负责管理具体的某个应用，包括向RM申请具体任务所需的资源，向NM请求启动具体的任务，同时监控所有任务的运行状况，并进行必要的容错处理。spark的driver，flink的jobManager都属于AM。
Container
Container是YARN中的一个抽象概念，它是任务运行所需资源，环境变量，启动参数等的一个封装和抽象。
一个Application中可以分为两类Container，一类是前面提到的AM，一类是具体任务的container，常见的任务container有MR中的map任务、reduce任务、spark中的executor、flink的taskManager。
【整体流程】
首先通过一张图来看下客户端提交任务到最终运行的整体流程。
客户端向RM提交应用，本质上是向RM请求启动AM
RM选择合适的NM，并向NM发送请求，要求启动AM
NM收到启动AM的请求后，根据所携带的参数，下载AM所依赖的资源到本地
完成依赖资源的本地化后，NM启动AM进程
AM启动后向RM进行注册，并向RM申请启动任务containr所需的资源
RM根据NM的资源汇报情况，向AM回复资源（container）的分配情况，即给请求的任务container分配具体的NM。
AM根据任务container分配的NM，向对应的NM发送请求，要求启动任务container
NM收到启动任务container的请求后，同样根据请求参数，先完成依赖资源的本地化，然后启动任务container进程。
整体流程中有几点需要注意：
RM中为container分配container，是等待NM进行心跳汇报后，被动触发进行的。
任务container的运行状态，是NM通过心跳向RM汇报，RM再通过AM的心跳响应告知对应的AM。
【RM中的流程】
前面概念中提到了application、container以及AM。在RM中，分别用Application，Container，AppAttempt类来对应这三个概念。整个任务提交运行流程也就围绕这三个类实例的创建，以及各自的状态机变化完成。
当然，还有一块内容未涉及，那就是调度器模块，这里暂不深入，后续再单独整理说明。
来看看任务提交运行在RM中的流程：
客户端向RM申请Application的ID
RM内部生成application的唯一ID
通过rpc响应将applicaiton ID告知客户端
客户端携带ID，以及container上下文，通过RPC向RM提交任务。
RM的rpc服务将请求转发给内部的AppManager模块。
AppManager创建一个App实例对象（RMAppImpl）。
随后向该实例对象发送start事件。
RMAppImpl收到事件后，向状态存储服务请求保存App状态，状态从NEW变为NEW_SAVING。
状态存储服务完成APP信息的存储后，再以事件的形式告知RMAppImpl。
RMAppImpl向调度器发送添加APP的事件，状态从NEW_SAVING变为SUBMITTED。
调度器收到消息后，进行相应的处理动作，然后告知RMAppImpl应用被接受。
RMAppImpl创建Attempt实例对象（RMAppAttemptImpl），
然后，向其发送start事件，随后状态从SUBMITTED变为ACCEPTED。
Attempt创建后，先向ApplicationMasterService进行注册，使其在内存中有对应的记录，方便后面真正的AM进程进行注册。
然后，向调度器发送添加Attempt事件。
调度器同样进行一系列的处理，包括权限判断，队列应用计数等，在内存中记录相关信息，最后通知Attempt成功添加。
Attempt调用调度器的接口，申请启动AM所需的资源，同时状态从NEW变为SUBMITTED。
当有NM节点向RM发送心跳请求时，RM内部最终会以事件的形式通知到调度器，调度器则选择合适的应用为其分配资源。
资源分配过程中，会新建Container对象（RMContainerImpl）。
然后向Container对象发送start事件。
container收到start事件后，告知attempt，资源已经完成分配。自身状态从NEW切换为ALLOCATED。
attempt收到事件后，通过接口向调度器获取已分配的资源，然后状态从SUBMITTED切换为SCHEDULED。
调度器的接口处理过程中会向container发送acquire事件。Container的状态从ALLOCATED切换为ACQUIRED。
随后，attempt向状态存储模块发送请求，要求存储attempt的信息。自身状态从SCHEDULED切换为ALLOCATED_SAVING。
状态存储完成后，以事件的形式告诉attempt。
attmpt向AMLaunch模块发送启动AM的请求。自身状态从ALLOCATED_SAVING切换为ALLOCATED。
AMLaunch通过RPC协议向指定的NM发送startContainer的请求。
AMLaunch告知Attempt，container已启动，Attempt的状态从ALLOCATED切换为LAUNCHED。
NM收到请求后，启动AM进程
AM进程启动后向RM中的ApplicationMasterService进行注册。
ApplicationMasterService收到注册请求后，告知对应的Attempt。Attempt的状态从LAUNCHED切为RUNNING。
Attempt收到AM进程并成功注册的消息后，进而告诉RMAppImpl。App的状态从ACCEPTED转换为RUNNING。
注：NM通过心跳告知RM节点上container的运行状态，RM内部处理该消息最终通知对应container，container状态从ACQUIRED转为RUNNING。
【NM中的流程】
与RM不同，在NM中并不感知container是具体任务还是AM，因此内部只有application和container，任务运行流程也就围绕这两个类实例的创建，状态机的变化及周边配套模块完成。
在NM中，任务运行的流程如下图所示：
NM内部的containerManagerImpl处理启动container的请求，先新建一个AppImpl（App的具体实现，后面简称为App）的实例对象，然后向该APP发送一个初始化事件，然后新建一个ContainerImpl（Container的具体实现，后面简称为Container）对象。
App向日志聚合模块发送请求，告知App启动，要求进行相应的初始化动作，同时状态从NEW变为INITING。
日志聚合模块完成app的初始化动作后，通过事件告知App。
APP收到事件后，接着向资源本地化服务模块发送请求，要求完成App所依赖资源的下载。
资源本地化服务模块完成对应的资源下载后，通过事件告知App。
App收到事件后，向Container发送初始化事件，同时状态从INITING变为RUNNING。
Container同样向资源本地化服务模块发送请求，要求完成Container所依赖资源的下载，此时状态从NEW变为LOCALIZING。
资源本地化服务模块每成功完成一个资源的下载，都会以事件的形式通知Container。
当Container感知所有依赖资源都完成本地化后，通过事件告知资源本地化服务模块进行清理动作（这里的清理动作不是清理资源文件，而是结束相应的资源下载进程）。
Container继续向Container启动服务模块发送请求，要求启动具体的Container进程，随后状态从LOCALIZING变为LOCALIZED。
Container启动服务模块根据Container上下文，设置环境变量、启动参数生成启动脚本，并创建Container的进程，然后通过事件告知Container。
Container收到进程启动的事件后，状态从LOCALIZED变为RUNNING。
当Container的进程运行结束后，其对应的创建线程获取其结束码，并通知Container。（假设这里为运行成功并正常结束）
Container收到事件后，向资源本地化服务模块发送请求，要求清理资源文件，然后状态从RUNNING切换为EXITED_WITH_SUCCESS。
资源本地化服务模块对Container的资源文件进行清理后，告知Container。
Container通知日志聚合模块运行结束，让其准备进行日志聚合。
随后也通知App，Container运行结束，最后状态切换为DONE。
App感知Container运行结束后，只是在内存中进行相关的记录，NM通过心跳向RM上报所有container的运行状况。RM会再通过心跳告知AM，当AM得知所有任务均结束时，向RM进行注销，并自身退出。RM得知AM结束后，进行相应的处理动作，最终告知该应用对应任务containerd的NM，应用结束。NM内部最终告知App。
App收到消息后，通知资源本地化服务模块进行资源的清理。然后自身状态从RUNNING切换为APPLICATION_RESOURCE_CLEANUP。
资源化本地服务模块完成资源清理后事件通知App。
App通知日志聚合模块进行日志聚合，最后状态变为FINISHED。
【总结】
本文简单总结了yarn任务提交运行的流程，可以看到整体流程还是比较长的，涉及的模块也非常多，那么任意一个环节出现异常，都可能导致任务的运行失败。yarn为此也做了很多异常处理，也有部分处理逻辑交给AM来决定，下篇文章我们就来聊聊yarn任务运行过程中的异常处理。
原创不易，点赞、在看、分享是最好的支持～
本文分享自微信公众号 - hncscwc（gh_383bc7486c1a）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。
