YARN学习总结

1、Yarn产生背景和基本架构

   Yarn产生背景：

Yarn之前MapReduce是Master/Slave结构，通过Master上的JobTracker（一个集群一个）管理MapReduce的作业，并向TaskTracker发布任务；TaskTracker（一个节点一个）运行在Slave节点，运行监控Map/Reduce任务。Hadoop1.0运行任务时，首先把job提交到jobTracker，由jobTracker把Map和Reduce任务分发向TaskTracker。Hadoop1.0的MapReduce任务比较简单，只能是MapReduce任务，整个集群只有一个JobTracker，存在单点故障，并且每个slave机器运行的Map和Reduce任务个数为固定值（以slot划分Map和Reduce）；需要运行其他任务时还需要额外部署，难以对集群资源进行共享。

   Yarn的基本概念：

• ResourecManager：一个集群只有一个，负责全局的资源管理和启动客户端提交的Application，监控NodeManager，汇总上报的资源和进行资源的分配
• NodeManager：每个节点一个NodeManager，管理自身节点的资源并监控资源使用情况上报给ResourceManager
• ApplicationMaster：每个应用程序特有的ApplicationMaster，协调来自ResourceManager的资源，并通过NodeManager监视容易的执行和资源使用情况

   Yarn的基本思想：

• Hadoop1.0中：jobTracker = 资源管理 + 任务调度
• Yarn切分：

        资源管理：ResourceManager负责

        任务调度：让ApplicationMaster负责，包括每个作业的启动、根据作业切分为任务、向ResourecManager申请资源与NodeManager进行协作，将申请的资源分配给任务，并监控任务，重启失败的任务。

   Yarn的资源抽象（container）：

• 描述：可使用的CPU资源和内存资源、任务执行命令、任务的环境变量、外部资源
• 获取：通过ApplicationMaster向ResourceManager申请，ApplicationMaster本身也有一个Container，由ResourceManager向自身申请启动
• 启动：由Container所属的NodeManager发起运行
• cpu资源：cpu被划分为虚拟cpu，这里的虚拟cpu是yarn自己引入的概念，初衷是考虑到不同节点cpu性能可能不同，每个cpu具有计算能力也是不一样的。比如，某个物理cpu计算能力可能是另外一个物理cpu的2倍，这时候，你可以通过为第一个物理cpu多配置几个虚拟cpu弥补这种差异。用户提交作业时，可以指定每个任务需要的虚拟cpu个数cpu不够会导致任务运行缓慢，并不会失败。

• cpu相关配置参数如下：

  yarn.nodemanager.resource.cpu-vcores

  表示该节点上yarn可使用的虚拟cpu个数，默认是8个，注意，目前推荐将该值为与物理cpu核数相同。如果你的节点cpu合数不够8个，则需要调减小这个值，而yarn不会智能的探测节点物理cpu总数。

  yarn.scheduler.minimum-allocation-vcores

  单个任务可申请最小cpu个数，默认1，如果一个任务申请的cpu个数少于该数，则该对应值被修改为这个数

  yarn.scheduler.maximum-allocation-vcores

  单个任务可以申请最多虚拟cpu个数，默认是32.

• 内存资源：内存资源不够会导致任务失败

  配置参数如下：

  yarn.nodemanager.resource.memory-mb

  表示该节点上yarn可以使用的物理内存总量，默认是8192m，注意，如果你的节点内存资源不够8g，则需要调减这个值，yarn不会智能的探测节点物理内存总量。

  yarn.nodemanager.vmem-pmem-ratio

  任务使用1m物理内存最多可以使用虚拟内存量，默认是2.1

  yarn.nodemanager.pmem-check-enabled

  是否启用一个线程检查每个任务证使用的物理内存量，如果任务超出了分配值，则直接将其kill，默认是true。

  yarn.nodemanager.vmem-check-enabled

  是否启用一个线程检查每个任务证使用的虚拟内存量，如果任务超出了分配值，则直接将其kill，默认是true。

  yarn.scheduler.minimum-allocation-mb

  单个任务可以使用最小物理内存量，默认1024m，如果一个任务申请物理内存量少于该值，则该对应值改为这个数。

  yarn.scheduler.maximum-allocation-mb

  单个任务可以申请的最多的内存量，默认8192m

思考：通常NodeManager会和DataNode混合部署？

答：1、DataNode存储真实数据使用的为磁盘空间对CPU和内存占用率非常低，NodeManager需要占用大量的CPU和内存，混合

        2、考虑到数据的本地性

2、Yarn的资源调度过程

1. 客户端提交程序到ResourceManager，ResourceManager寻找空闲的NodeManager
2. NodeManager本地启动Container，开启ApplicationMaster（一个作业一个）
3. ApplicationMaster向ResourceManager发起ResourceRequest请求申请资源，ResourceManager整理好资源后分配给ApplicationMaster（分配过程中存在等待过程）
4. ApplicationMaster向NodeManager申请资源，NodeManager（多个任务多次发起）启动一个Container，运行任务
5. NodeManager向ApplicationMaster汇报任务状态，失败后重新执行
6. NodeManager向ApplicationMaster、ResourceManager汇报Container的状态，ResourceManager进行资源的回收处理，ApplicationMaster负责任务失败的重试

   各个组件之间的心跳：

    ApplicationMaster和ResourceManager：

          AM向RM申请Container所需要的资源和Container的优先级，并汇报已使用完毕的Container列表（Container是否处理完毕数据）

          RM向AM发送Container的资源和已完成的Container状态（是否删除）

    ApplicationMaster和NodeManager：

          AM向NM发起Container请求（NodeManager根据AM向RM请求的资源开启Container）

          NM向AM汇报Container的状态（是否处理完毕、是否处理失败）

    ResourceManager和NodeManager：

          NM向RM汇报Container状态（处理完毕的Container可以RM清理）

          RM向NM发送已删除和等待清理的Container列表（清理完毕的在NM端将Cintainer移除）

3、Yarn的资源隔离策略

   内存资源隔离

• 基于线程监控方案：当高于机器本身内存时，不会直接kill调Container，当高于时间达到一定阀值的时候才会进行kill操作
• 基于cgroups：linux系统自带

   cpu资源隔离

• 默认不对cpu进行隔离
• 基于cgroups（CHD可配）

4、Yarn的容错能力

• 作业失败：作业异常会汇报给ApplicationMaster，通过心跳检查挂住任务，一个任务失败超过配置，会认为改任务失败
• ApplicationMaster失败：ResourceManager接收不到心跳信号时，会重启ApplicationMaster
• NodeManager失败：ResourceManager接收不到心跳信息会将其移除，ResourceManager会通知ApplicationMaster，让其决定任务如何处理，若失败次数过多则不在其上运行任务
• ResourceManager失败：通过checkpoint机制定期将其状态保存到磁盘，失败时重新运行，或通过zookeeper实现ResourecManager的高可用

5、Yarn的资源调度算法

   解决问题：

     多租户：多个用户同时提交应用程序，资源调度器如何合理分配资源

     可扩展：增加集群的机器数量可以提高整个集群的性能

   资源共享问题：使用层级队列，任务只允许提交到子队列上，不可以直接提交到root目录

   资源调度器：FIFO（先来先服）、Capacity Scheduler （容量调度器）、 Fair Scheduler（公平调度器）