YARN(Yet Another Resource Negotiator)是Hadoop的集群资源管理系统。
YARN提供请求和使用集群资源的API,但这些API很少直接用于用户代码。
相反,用户代码中用的是分布式计算框架提供的更高层API,这些API建立在YARN之上且向用户隐藏了资源管理细节。
一、YARN应用运行机制 1、运行机制
YARN通过两类长期运行的守护进程提供自己的核心服务:管理集群上资源使用的资源管理器(resource manager)、运行在集群中所有节点上且能够启动和监控容器(container)的节点管理器(node manager)。
容器用于执行特定应用程序的进程,每个容器都有资源限制(内存、CPU等)。
一个容器可以是一个Unix进程,也可以是一个Linux cgroup,取决于YARN的配置。
YARN应用运行机制示意图如下:
首先,客户端联系资源管理器,要求它运行一个application master进程(1)。
然后,资源管理器找到一个能够在容器中启动application master的节点管理器(2a & 2b)。
application master运行起来后做什么依赖于应用本身。
可能是在所处的容器中简单地运行一个计算,并将结果返回给客户端;或是向资源管理器请求更多的容器(3),以用于运行一个分布式计算(4a & 4b)。
YARN本身不会为应用的各部分(客户端、master和进程)彼此间通信提供任何手段。
大多数重要的YARN应用使用某种形式的远程通信机制来向客户端传递状态更新和返回结果,但是这些通信机制都是专属于各应用的。
YARN有一个灵活的资源请求模型。
当请求多个容器时,可以指定每个容器需要的计算机资源数量(内存和CPU),还可以指定对容器的本地限制要求。
YARN允许一个应用为所申请的容器指定本地限制。
本地限制可用于申请位于指定节点或机架,或集群中任何位置的容器。
有时本地限制无法被满足,这种情况下要么不分配资源,或者可选择放松限制。
例如,一个节点由于已运行了别的容器而无法再启动新的容器,这时如果有应用请求该节点,则YARN将尝试在同一机架中的其他节点上启动一个容器,如果还不行,则会尝试集群中的任意一个节点。
YARN应用可以在运行中的任意时刻提出资源申请。
例如,可以在最开始提出所有的请求,或者为了满足不断变化的应用需要,采取更为动态的方式在需要更多资源时提出请求。
Spark采用第一种方式,在集群上启动固定数量的执行器;MapReduce则分两步走,在最开始的时候申请map任务容器,reduce人去容器的启用则放在后期。
YARN应用生命周期差异性很大,所以按照应用到用户运行的作业之间的映射关系对应用分类更有意义。
① 一个用户作业对应一个应用(MapReduce);
② 作业的每个工作流或每个用户对话对应一个应用(Spark);
③ 多个用户共享一个长期运行的应用,作为一种协调者的角色运行(Apache Slider、Impala)。
二、YARN与MapReduce 1相比 1、组成
MapReduce 1中,有两类守护进程控制着作业执行过程:一个jobtracker及一个或多个tasktracker。
jobtracker通过调度tasktracker上运行的任务来协调所有运行在系统上的作业。
tasktracker在运行任务的同时将运行进度报告发送给jobtracker,jobtracker由此记录每项作业任务的整体进度情况。
如果其中一个任务失败,jobtracker可以在任何一个tasktracker节点上重新调度该任务。
MapReduce 1和YARN组成比较如下:
MapReduce 1
YARN
Jobtracker
资源管理器、application master、时间轴服务器
TaskTracker
节点管理器
Slot
容器
YARN可以在更大规模的集群上运行。
由于jobtracker必须同时管理作业任务和任务,当节点数达到4000、任务数达到40000时,MapReduce 1会遇到可扩展性瓶颈。
YARN利用资源管理器和application master分离的架构优点克服了这个局限性,可以扩展到面向将近10000个节点和100000个任务。
MapReduce 1中,每个tasktracker都配置有若干固定长度的slot,这些slot时静态分配的,在配置的时候就被划分为map slot和reduce slot。
一个map slot仅能用于运行一个map任务,同样,一个reduce slot仅能用于运行一个reduce任务。
YARN上,一个节点管理器管理一个资源池,而不是指定的固定数目的slot。
YARN上运行的MapReduce不会出现由于集群中仅有map slot可用导致reduce任务必须等待的情况。
YARN中的资源时精细化管理的,这样一个应用能够按需请求资源,而不是请求一个不可分割的、对于特定的任务而言可能会太大或太小的slot。
YARN向MapReduce以外的其他类型的分布式应用开放了Hadoop。
用户甚至可以在同一个YARN集群上运行不同版本的MapReduce。
三、YARN中的调度 1、调度选项
YARN调度器的工作是根据既定策略为应用分配资源。
YARN中有三种调度器可用:FIFO调度器、容量调度器、公平调度器。
FIFO调度器将应用放置在一个队列中,然后按照提交的顺序运行应用,优点是简单易懂不需要任何配置,但是不适合共享集群。
使用容量调度器时,一个独立的专门队列保证小作业一提交就可以启动,由于队列容量是为那个队列中的作业所保留的,因此这种策略是以整个集群的利用率为代价的。
使用公平调度器时,不需要预留一定量的资源,因为调度器会在所有运行的作业之间动态平衡资源,既得到了较高的集群利用率,又能保证小作业能及时完成。
在一个繁忙的集群上,如果一个应用请求某个节点,那么极有可能此时有其他容器正在该节点上运行。
此时如果等待一小段时间,能够增加在所请求的节点上分配到一个容器的机会,从而可以提高集群的效率。
这个特性称为延迟调度。
容量调度器和公平调度器都支持延迟调度。
当使用延迟调度时,调度器不会简单的使用它收到的第一个调度机会,而是等待、设定的最大数目的调度机会发生,然后才放松本地性限制并接收下一个调度机会。
YARN中调度器解决公平性的思路是,观察每个用户的主导资源,并将其作为对集群资源使用的一个度量(称为主导资源公平性 DRF),默认情况下不用DRF。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)