Hadoop YARN 架构详解

3,465

通过对Hadoop1.0和2.0的架构对比,引出了YARN作为资源调度和管理器的作用。

1、YARN产生的背景

YARN是MRv1基础上演化而来的,克服了MRv1中的各种局限性。在正式的介绍YARN之前,我们先要了解MRv1的一些局限性,这可概括为以下几个方面:

  • 扩展性差:在MRv1中,JobTracker同时兼备了资源管理和作业控制两个功能,这个成为系统的一个最大瓶颈,严重制约了Hadoop集群的扩展性。
  • 可靠性差:MRv1采用的master/slaver结构,其中master节点存在单点故障问题,一旦它出现故障将导致整个集群不可用。
  • 资源利用率低:MRv1采用了基于槽位的资源分配模型,槽位是一种粗粒度的资源划分单位,通常一个任务不会用完槽位对应的资源,且其他任务也无法使用这些空闲资源。此外,Hadoop将槽位分为Map Slot和Reduce Slot两种,且不允许它们之间共享,常常会导致一种槽位资源紧张而另一种闲置(比如一个作业刚刚提交时,只会运行Map Task,此时Reduce Slot闲置)。
  • 无法支持多种计算框架。

2、什么是YARN?

YARN实际上是一个弹性计算平台,它的目标已经不再局限于支持MapReduce一种计算框架了,而是朝着对多种框架进行统一管理的方向发展。YARN的基本思想是将资源管理和作业调度/监视的功能拆分为单独的守护程序。 拥有一个全局的ResourceManager(RM)和每个应用程序的ApplicationMaster(AM)。 应用程序可以是单个作业,也可以是作业的DAG。

image-20191117175429041

image-20191117175447804

3、YARN的作用是什么?

3.1、Hadoop v1.0的方式

在Hadoop v1.0的框架中,对数据的处理、资源调度主要依赖MapReduce完成,具体过程如下所示:

image-20191117175531487

从以上图中,我们可以了解到Hadoop v1.0的数据处理方式。在小规模的数据处理过程中,这套方法没有太大问题。但是,在真实的场景中往往需要处理大量数据,这套方法便会遇到以下问题:

  • 由于大量的数据处理Job提交给Job Tracker,且Job Tracker需要协调的Data Node可能有数千台,Job Tracker极易成为整个系统的性能、可用的瓶颈。
  • 无法有效地调配资源,导致资源分配不均。如以下例子,假设有3台Data Node(DN),每个DN的内存为4GB。用户提交了6个Job,每个Job需要1GB内存进行处理,且数据均在DN2上。由于DN2只有4GB内存,所以Job1-4在DN2上运行,Job5和6则在排队等待。但是,此时DN1和3均在闲置的状态下,而未能有效的被利用。

image-20191117175553600

3.2、YARN的方式

基于上述问题,Hadoop在2.0版本上推出了YARN (Yet Another Resource Negotiator)。YARN的核心思想是将资源管理和Job的调度/监控进行分离。YARN的架构如下图所示。

image-20191117175612400

image-20191117175634723

YARN的核心组件可以分为两大部分:

全局组件

  • Resource Manager(RM): 作为全局统一的资源管理、调度、分配。Resource Manager由Scheduler(调度器:本质上是一种策略)和Applicatio Manager(应用程序管理器,ASM:负责管理Client用户提交的应用)组成。Scheduler根据节点的容量、队列情况,为Application分配资源;Application Manager接受用户提交的请求,在节点中启动Application Master,并监控Application Master的状态、进行必要的重启。
  • Node Manager(NM): 在每一个节点上都有一个Node Manager作为代理监控节点的资源使用情况(cpu, memory, disk, network)并向Resource Manager上报节点状态。

Per-applicaiton组件

  • Application Master(AM): 负责数据处理job的执行调度。Application Master与Resource Manager进行沟通,获取资源进行计算。得到资源后,与节点上的Node Manager进行沟通,在分配的Container汇总执行任务,并监控任务执行的情况。(每当 Client 提交一个 Application 时候,就会新建一个 ApplicationMaster 。由这个 ApplicationMaster 去与 ResourceManager 申请容器资源,获得资源后会将要运行的程序发送到容器上启动,然后进行分布式计算。)
  • Container: 资源的一种抽象方式,它封装了某个节点上的多维度资源,如内存、CPU、磁盘、网络等,当Application Master向Resource Manager申请资源时,Resource Manager为Application Master返回的资源便是Container。

当YARN接受用户提交的Job时,其工作过程为:

image-20191117175658829

YARN通过以下方式,解决了上述问题。

  • 通过Application Master来解决Job Tracker的瓶颈问题。每当新的job提交进来后,Resource Manager会在恰当的节点启动一个新的Application Master,从而避免在Hadoop v1.0中Job Tracker成为性能瓶颈的尴尬。
  • 更有效的进行资源的调度。Resource Manager可以为Application Master分配空余的资源,帮忙Application Master完成任务。
  • 支持MapReduce以外的数据处理方式,例如:Spark等。

4、YARN和其他的资源管理器的对比

即便Hadoop v2.0应用来YARN的设计思路,也仍有一个难题:当大量的job提交、用尽所有计算资源后,新的job要等待很久才能被处理,即便新的job是非常重要的任务,也只能等待。在YARN中,通过scheduler plugin(例如:FIFO SchedulerFair SchedulerCapacity Scheduler)的方式,配置不同的资源调度规则,来尽量缓解该问题,让重要的job可以优先获得资源调配。

5、参考资料

www.jianshu.com/p/952d59b7c…

hadoop.apache.org/docs/curren…