Yarn提交mr的流程和三种调用方案的理解

Yarn提交mr的流程

 

第一步 : 客户端提交运行一个 MR 的程序给 Yarn 集群 , Yarn 主节点首先会先检查提交任务请求是否 OK

第二步 : 如果 OK, RM 会随机选择一台 NodeManager, 启动这个任务对应的一个管理者 : AppMaster( 一个任务一个

AppMaster)

第三步 : AppMaster 进行启动 , 启动后会和 RM 进行汇报 , 已经启动成功了 , 同时也会和主节点简历心跳包

第四步 : AppMaster 开始进行资源的申请 , 根据任务的对应资源要求 , 向 RM 申请资源 , 通过心跳包的形式 , 将需要申请资

源信息发送给 RM

第五步 : RM 接收到资源申请的信息后 , 将这个资源申请交给其底层的资源调度器 (FIFO 容量 公平 ), 来负责完整资源的分

配工作 , 如果当前没有资源 , 那么就需要等待即可 , 如果有资源 , 就会立即分配好 , 等待 AppMaster 来拉取

第六步 : AppMaster 会不断的询问 RM( 心跳 ), 是否已经准备好资源 , 如果发现已经准备好资源 , 那么就会立即拉取过来

第七步 : AppMaster 会根据资源信息 ( 资源信息会采用 container 容器的方式返回 ), 连接对应的 nodeManager, 开始进

行任务的分配

第八步 : 将任务分配给对应的 nodemanager 进行执行操作 , nodemanager 收到任务后 , 占用相关的资源 , 启动运行 , 同

时一旦占用资源后 , 后续 nodemanager 汇报的时候 , 就会告知 RM 资源已经被占用了

第九步 : AppMaster 不断的监听各个 NN 是否已经执行完成 , 如果 MapTask 全部都执行完成后 , 就会通知 ReduceTask 可以

拉取数据 , 完成 reduceTask 的运行操作

第十步 : 当所有的 Task 全部都执行完成后 , AppMaster 就会通知给 RM 任务以及执行完成 , RM 回收资源 , 通知

AppMaster 可以关闭了

Yarn的三种调度方案

1- FIFO Scheduler( 先金先出调度器 ) :

         只有一个队列 , 将所有的提交任务全部放置在一个队列中 , 根据提交的顺序 , 依次的分配资源进行运行操作

        好处 : 配置简单

        弊端 : 不合适共享集群 , 因为大的应用会直接将所有的资源全部都拿到了 , 导致后续的其他的任务无法运行

2- Capacity Scheduler( 容量调度器 ) :

         可以对资源进行划分 , 形成多个队列 , 不同队列管理不同范围资源 , 比如说 , 分配队列, 分别管理 30% 50% 20% 资源 , 这样可以让不同任务 , 放置到不同队列中 , 既可以保证大任务运行 , 也可以让小任务有资源可用

        好处 : 多队列 , 可以多任务的运行 , 可以进行资源的划分

        弊端 : 如果是一个庞大的任务 , 是无法拿到全部的资源 , 虽然支持资源抢占 , 但是存在一定抢占比例

        注意 : 此调度器是 Apache 版本的 Hadoop 默认使用的

3- Fair Scheduler( 公平调度器 ) :

        使用公平调度器, 不需要预留一定的资源 , 因为调度器会在所有运行的作业中进行 动态平衡, 当第一个大的任务运行的时候 , 公平调度器可以将全部的资源分配给第一个任务 , 当第二个大的任务过来后 , 会要求第一个任务释放出50% 的资源 , 交给第二个任务来进行运行 , 当第二个任务运行完成后 , 会将资源在归还给第一个任务

        好处 : 可以让大的任务使用全部的资源 , 同时也可以满足其他的任务也可以有资源运行

        弊端 : 如果任务比较多 , 会导致大任务迟迟无法结束 , 因为资源一直被其他的任务在使用中

         注意 : 此调度器是CDH 版本的 Hadoop 默认使用的