189 8069 5689

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。

【整体流程】


首先通过一张图来看下客户端提交任务到最终运行的整体流程。

YARN任务提交启动的流程是什么

  1. 客户端向RM提交应用,本质上是向RM请求启动AM

  2. RM选择合适的NM,并向NM发送请求,要求启动AM

  3. NM收到启动AM的请求后,根据所携带的参数,下载AM所依赖的资源到本地

  4. 完成依赖资源的本地化后,NM启动AM进程

  5. AM启动后向RM进行注册,并向RM申请启动任务containr所需的资源

  6. RM根据NM的资源汇报情况,向AM回复资源(container)的分配情况,即给请求的任务container分配具体的NM。

  7. AM根据任务container分配的NM,向对应的NM发送请求,要求启动任务container

  8. NM收到启动任务container的请求后,同样根据请求参数,先完成依赖资源的本地化,然后启动任务container进程。

整体流程中有几点需要注意:

  • RM中为container分配container,是等待NM进行心跳汇报后,被动触发进行的。

  • 任务container的运行状态,是NM通过心跳向RM汇报,RM再通过AM的心跳响应告知对应的AM。

【RM中的流程】


前面概念中提到了application、container以及AM。在RM中,分别用Application,Container,AppAttempt类来对应这三个概念。整个任务提交运行流程也就围绕这三个类实例的创建,以及各自的状态机变化完成。

当然,还有一块内容未涉及,那就是调度器模块,这里暂不深入,后续再单独整理说明。

来看看任务提交运行在RM中的流程:

YARN任务提交启动的流程是什么

  1. 客户端向RM申请Application的ID

  2. RM内部生成application的唯一ID

  3. 通过rpc响应将applicaiton ID告知客户端

  4. 客户端携带ID,以及container上下文,通过RPC向RM提交任务。

  5. RM的rpc服务将请求转发给内部的AppManager模块。

  6. AppManager创建一个App实例对象(RMAppImpl)。

  7. 随后向该实例对象发送start事件。

  8. RMAppImpl收到事件后,向状态存储服务请求保存App状态,状态从NEW变为NEW_SAVING。

  9. 状态存储服务完成APP信息的存储后,再以事件的形式告知RMAppImpl。

  10. RMAppImpl向调度器发送添加APP的事件,状态从NEW_SAVING变为SUBMITTED。

  11. 调度器收到消息后,进行相应的处理动作,然后告知RMAppImpl应用被接受。

  12. RMAppImpl创建Attempt实例对象(RMAppAttemptImpl),

  13. 然后,向其发送start事件,随后状态从SUBMITTED变为ACCEPTED。

  14. Attempt创建后,先向ApplicationMasterService进行注册,使其在内存中有对应的记录,方便后面真正的AM进程进行注册。

  15. 然后,向调度器发送添加Attempt事件。

  16. 调度器同样进行一系列的处理,包括权限判断,队列应用计数等,在内存中记录相关信息,最后通知Attempt成功添加。

  17. Attempt调用调度器的接口,申请启动AM所需的资源,同时状态从NEW变为SUBMITTED。

  18. 当有NM节点向RM发送心跳请求时,RM内部最终会以事件的形式通知到调度器,调度器则选择合适的应用为其分配资源。

  19. 资源分配过程中,会新建Container对象(RMContainerImpl)。

  20. 然后向Container对象发送start事件。

  21. container收到start事件后,告知attempt,资源已经完成分配。自身状态从NEW切换为ALLOCATED。

  22. attempt收到事件后,通过接口向调度器获取已分配的资源,然后状态从SUBMITTED切换为SCHEDULED。

  23. 调度器的接口处理过程中会向container发送acquire事件。Container的状态从ALLOCATED切换为ACQUIRED。

  24. 随后,attempt向状态存储模块发送请求,要求存储attempt的信息。自身状态从SCHEDULED切换为ALLOCATED_SAVING。

  25. 状态存储完成后,以事件的形式告诉attempt。

  26. attmpt向AMLaunch模块发送启动AM的请求。自身状态从ALLOCATED_SAVING切换为ALLOCATED。

  27. AMLaunch通过RPC协议向指定的NM发送startContainer的请求。

  28. AMLaunch告知Attempt,container已启动,Attempt的状态从ALLOCATED切换为LAUNCHED。

  29. NM收到请求后,启动AM进程

  30. AM进程启动后向RM中的ApplicationMasterService进行注册。

  31. ApplicationMasterService收到注册请求后,告知对应的Attempt。Attempt的状态从LAUNCHED切为RUNNING。

  32. Attempt收到AM进程并成功注册的消息后,进而告诉RMAppImpl。App的状态从ACCEPTED转换为RUNNING。

注:NM通过心跳告知RM节点上container的运行状态,RM内部处理该消息最终通知对应container,container状态从ACQUIRED转为RUNNING。

【NM中的流程】


与RM不同,在NM中并不感知container是具体任务还是AM,因此内部只有application和container,任务运行流程也就围绕这两个类实例的创建,状态机的变化及周边配套模块完成。

在NM中,任务运行的流程如下图所示:

YARN任务提交启动的流程是什么

  1. NM内部的containerManagerImpl处理启动container的请求,先新建一个AppImpl(App的具体实现,后面简称为App)的实例对象,然后向该APP发送一个初始化事件,然后新建一个ContainerImpl(Container的具体实现,后面简称为Container)对象。

  2. App向日志聚合模块发送请求,告知App启动,要求进行相应的初始化动作,同时状态从NEW变为INITING。

  3. 日志聚合模块完成app的初始化动作后,通过事件告知App。

  4. APP收到事件后,接着向资源本地化服务模块发送请求,要求完成App所依赖资源的下载。

  5. 资源本地化服务模块完成对应的资源下载后,通过事件告知App。

  6. App收到事件后,向Container发送初始化事件,同时状态从INITING变为RUNNING。

  7. Container同样向资源本地化服务模块发送请求,要求完成Container所依赖资源的下载,此时状态从NEW变为LOCALIZING

  8. 资源本地化服务模块每成功完成一个资源的下载,都会以事件的形式通知Container。

  9. 当Container感知所有依赖资源都完成本地化后,通过事件告知资源本地化服务模块进行清理动作(这里的清理动作不是清理资源文件,而是结束相应的资源下载进程)。

  10. Container继续向Container启动服务模块发送请求,要求启动具体的Container进程,随后状态从LOCALIZING变为LOCALIZED。

  11. Container启动服务模块根据Container上下文,设置环境变量、启动参数生成启动脚本,并创建Container的进程,然后通过事件告知Container。

    Container收到进程启动的事件后,状态从LOCALIZED变为RUNNING。

  12. 当Container的进程运行结束后,其对应的创建线程获取其结束码,并通知Container。(假设这里为运行成功并正常结束)

  13. Container收到事件后,向资源本地化服务模块发送请求,要求清理资源文件,然后状态从RUNNING切换为EXITED_WITH_SUCCESS。

  14. 资源本地化服务模块对Container的资源文件进行清理后,告知Container。

  15. Container通知日志聚合模块运行结束,让其准备进行日志聚合。

  16. 随后也通知App,Container运行结束,最后状态切换为DONE。

  17. App感知Container运行结束后,只是在内存中进行相关的记录,NM通过心跳向RM上报所有container的运行状况。RM会再通过心跳告知AM,当AM得知所有任务均结束时,向RM进行注销,并自身退出。RM得知AM结束后,进行相应的处理动作,最终告知该应用对应任务containerd的NM,应用结束。NM内部最终告知App。

  18. App收到消息后,通知资源本地化服务模块进行资源的清理。然后自身状态从RUNNING切换为APPLICATION_RESOURCE_CLEANUP。

  19. 资源化本地服务模块完成资源清理后事件通知App。

  20. App通知日志聚合模块进行日志聚合,最后状态变为FINISHED。

“YARN任务提交启动的流程是什么”的内容就介绍到这里了,感谢大家的阅读。如果想了解更多行业相关的知识可以关注创新互联网站,小编将为大家输出更多高质量的实用文章!


网页名称:YARN任务提交启动的流程是什么
网页地址:http://cdxtjz.com/article/gshdes.html

其他资讯