分布式资源调度YARN

YARN产生背景

• Hadoop1.x中的MapReduce构成图如下：
  

在Hadoop1.x中MapReduce是Master/Slave结构，在集群中的表现形式为： 1个JobTracker带多个TaskTracker；
JobTracker：负责资源管理和作业调度；

                    只存在一个JT--------宕掉后，整个架构无法完成作业运行，即 单点故障

                     JT要接受来自每个TT的RPC请求和客户端的作业提交/查询请求，集群规模越来越大时 ，JT节点存在压力过大的瓶颈仅支持MapReduce作业，不支持其他计算框架
TaskTracker：定期向JobTracker汇报本节点的健康状况、资源使用情况以及任务的执行情况；

                       接收来自JobTracker的命令（启动/杀死任务等）并执行接收到的命令;

1、MapReduce1.0存在的问题：

　　1） 单点故障：JobTracker只有一个，JobTracker挂了整个集群就没办法使用了；
　　2）JobTracker负责接收来自各个JobTracker节点的RPC请求，压力会很大 ，限制了集群的扩展；随着节点规模增大之后，JobTracker就成为一个瓶颈；
　　3） 仅支持MapReduce计算框架；
　　　　MapReduce计算框架是一个基于Map和Reduce两阶段、适合批处理的、基于磁盘的计算框架；
　　　　MapReduce计算框架优点：容错性好；
　　　　MapReduce计算框架缺点：性能差；

2、资源利用率　　

　　在没有YARN之前，是一个集群一个计算框架。比如：Hadoop一个集群、Spark一个集群、HBase一个集群...... 造成各个集群管理复杂，资源的利用率很低；比如：在某个时间段内Hadoop集群忙而Spark集群闲着，反之亦然，各个集群之间不能共享资源造成集群间资源并不能充分利用；
　　解决思路：
　　将所有的计算框架运行在一个集群中， 共享一个集群的资源，按需分配；Hadoop需要资源就将资源分配给Hadoop，Spark需要资源就将资源分配给Spark，进而整个集群中的资源利用率就高于多个小集群的资源利用率；

3、运维成本

　　采用“一个框架一个集群”的模式，则需要多个管理员管理这些集群，进而增加运维成本；
　　而共享集群模式通常需要少数管理员即可完成多个框架的统一管理;

4、数据共享

　　随着数据量的暴增，跨集群间的数据移动不仅需要花费更长的时间，且硬件成本也会大大增加；
　　而共享集群模式可让多种框架共享数据和硬件资源,将大大减少数据移动带来的成本;

总结：

1) 源于MRv1的缺陷： 扩展性受限、单点故障、难以支持MR之外的计算框架；
2) 多计算框架各自为战，数据共享困难，资源利用率低；

             MR: 离线计算框架
　      　Storm：实时计算框架
　      　Spark：内存计算框架

催生了YARN的产生。

YARN：不同计算框架可以共享同一个HDFS集群上的数据，享受整体的资源调度
XXX on YARN的好处：（ XXX: Spark/MapReduce/Storm/Flink）
与其他计算框架共享集群资源，按资源需要分配，进而提高集群资源的利用率。

YARN基本构成

YARN架构：
1.ResourceManager： 整个集群只有一个，负责集群资源的统一管理和调度
1）处理来自客户端的请求（启动/杀死应用程序）；
　　2）启动/监控ApplicationMaster；一旦某个AM挂了之后，RM将会在另外一个节点上启动该AM；
　 3）监控NodeManager，接收NodeManager的心跳汇报信息并分配任务到NodeManager去执行；一旦某个NM挂了， 标志下该NM上的任务，来告诉对应的AM如何处理；
　　4）负责整个集群的资源分配和调度；
2. NodeManager: 整个集群中有多个，负责单节点资源管理和使用
1）周期性向ResourceManager汇报本节点上的资源使用情况和各个Container的运行状态；
　　2）接收并处理来自ResourceManager的Container启动/停止的各种命令；
　　3）处理来自ApplicationMaster的命令；
　　4）负责单个节点上的资源管理和任务调度；
3. ApplicationMaster: 每个应用一个，负责应用程序的管理
       1）数据切分；
　　2）为应用程序/作业向ResourceManager申请资源(Container)，并分配给内部任务；
　　3）与NodeManager通信以启动/停止任务；
　　4）任务监控和容错（在任务执行失败时重新为该任务申请资源以重启任务）；
　　5）处理ResourceManager发过来的命令：杀死Container、让NodeManager重启等；
4.Container： 对任务运行环境的抽象
      1）封装了任务运行资源（节点、内存、CPU）的一个容器；

　　2）任务启动命令；
　　3）任务运行环境；
　　任务是运行在Container中，一个Container中既可以运行ApplicationMaster也可以运行具体的Map/Reduce/MPI/Spark Task；
5. Client
提交作业
查询作业的运行进度
杀死作业
流程：Task submit -----> 先到ResourceManage -----> 从RM在到任意一个NodeManage上去启动ApplicationMaster-------> AM再到RM申请资源------->RM通知对应的NM，启动Container运行Task

YARN工作原理

1）用户向YARN中提交应用程序/作业，其中包括ApplicaitonMaster程序、启动ApplicationMaster的命令、用户程序等；

2）ResourceManager为作业分配第一个Container，并与对应的NodeManager通信，要求它在这个Containter中启动该作业的ApplicationMaster；

3）ApplicationMaster首先向ResourceManager注册，这样用户可以直接通过ResourceManager查询作业的运行状态；然后它将为各个任务申请资源并监控任务的运行状态，直到运行结束。即重复步骤4-7；

4）ApplicationMaster采用轮询的方式通过RPC请求向ResourceManager申请和领取资源；

5）一旦ApplicationMaster申请到资源后，便与对应的NodeManager通信，要求它启动任务；

6）NodeManager启动任务；

7）各个任务通过RPC协议向ApplicationMaster汇报自己的状态和进度，以让ApplicaitonMaster随时掌握各个任务的运行状态，从而可以在任务失败时重新启动任务；
在作业运行过程中，用户可随时通过RPC向ApplicationMaster查询作业当前运行状态；

8）作业完成后，ApplicationMaster向ResourceManager注销并关闭自己；

流程：

①Client submit task -----> RM
②，③RM 与 NM 通信，在这个NM上启动一个Container（用来启动应用程序ApplicationMaster）
④AM到RM上注册，注册完成后Client即可查询Task运行情况，AM向RM上申请Core，Memory
⑤，⑥AM在对应的NM上启动Task（在Container中启动）

YARN容错性

1、ResourceMananger
　　基于ZooKeeper实现HA避免单点故障；
2、NodeManager
　　执行失败后，ResourceManager将失败任务告诉对应的ApplicationMaster；
　　由ApplicationMaster决定如何处理失败的任务；
3、ApplicationMaster
　　执行失败后，由ResourceManager负责重启；
　　ApplicationMaster需处理内部任务的容错问题；
　　RMAppMaster会保存已经运行完成的Task，重启后无需重新运行。

YARN调度框架

1、双层调度框架
　　1）ResourceManager将资源分配给ApplicationMaster；
　　2）ApplicationMaster将资源进一步分配给各个TASK；

2、 基于资源预留的调度策略
　　1）资源不够时，会为Task预留，直到资源充足；
　　描述：当一个Task需要10G资源时，各个节点都不足10G，那么就选择一个节点，但是某个NodeManager上只有2G，那么就在这个NodeManager上预留，当这个NodeManager上释放其他资源后，会将资源预留给10G的作业，直到攒够10G时，启动Task；
　 　缺点：资源利用率不高，要先攒着，等到10G才利用，造成集群的资源利用率低；
　　2）与“all or nothing”策略不同（Apache Mesos）
　　描述：当一个作业需要10G资源时，节点都不足10G， 那就慢慢等 ，等到某个节点上有10G空闲资源时再运行， 很可能会导致该Task饿死。

YARN设计目标

通用的统一的资源管理系统：
1）同时运行 长应用程序 （永不停止的程序：Service、HTTP Server）；
2） 短应用程序 （秒、分、小时级内运行结束的程序：MR job、Spark job等）；

MapReduce2.0与YARN

1、一个MapReduce应用程序需要如下模块：

　　1）任务管理和资源调度；

　　2）任务驱动模块（MapTask、ReduceTask）；

　　3）用户代码（Mapper、Reducer）；

2、MapReduce2.0的组成：

　　1）YARN（整个集群只有一个）；

　　2）MRAppMasster（一个应用程序一个）；

　　3）用户代码（Mapper、Reducer）；

3、MapReducer1.0和MapReduce2.0的区别：

　　1）MapReduce1.0是一个独立的系统，直接运行在Linux上；

　　2）MapReduce2.0则是运行在YARN上的框架，且可与多种框架一起运行在YARN之上；

4、MapReduce2.0和YARN的区别：

　　1）YARN是一个资源管理系统，负责资源管理和调度；

　　2）MapReduce只是运行在YARN上的一个应用程序；如果把YARN看成是android，那么MapReduce就是运行在android上个一个app；