大数据系统——Apache Hadoop YARN: Yet Another Resource Negotiator论文分享

1.背景

Apache Hadoop最开始设计是考虑运行大量MapReduce任务来处理网络爬虫数据,但是随着应用日益广泛,Hadoop成为了数据存放和计算的主要地方。日益广泛的使用范围超出了最初设计的考虑,暴露出了两个主要的缺点:(1)对于特定编程语言的紧耦合使得开发者滥用MapReduce编程模型;(2)集中处理作业控制流造成无休止的调度程序扩展问题。
YARN的定位是下一代Hadoop的计算平台。引入的新架构将编程模型与资源管理基础架构分离,并将许多调度功能(例如,task fault tolerance)委托给每个应用程序组件。

2.架构

YARN将一些功能提升到负责资源管理的平台层,将逻辑执行计划的协调留给大量框架实现。具体而言,每个集群的资源管理器(Resource Manager,RM)跟踪资源使用情况和节点活跃度,强制执行分配不变量,并仲裁租户之间的争用。通过在JobTracker的章程中分离这些职责,中央分配器(即RM)可以使用租户要求的抽象描述,但仍然不知道每个分配的语义。该职责被委托给应用程序主机(Application Master,AM),它协调单个job的逻辑计划,通过从RM请求资源,从其接收的资源生成物理计划,以及围绕故障协调该计划的执行。
大数据系统——Apache Hadoop YARN: Yet Another Resource Negotiator论文分享_第1张图片
概览:RM在专用计算机上作为后台程序(daemon)运行,并作为中央权威,在集群中的各种竞争应用程序之间仲裁资源。通过这种中心化的和全局视图,它可以在租户之间实施丰富,熟悉的属性,如公平性,容量和位置。根据应用程序需求,调度优先级和资源可用性,RM动态地将租约(称为容器)分配给应用程序以在特定节点上运行。容器是绑定到特定节点的资源的逻辑捆绑(例如,<2GB RAM,1 CPU>)。为了强制执行和跟踪此类分配,RM与在称为NodeManager(NM)的每个节点上运行的特殊系统守护程序进行交互。RM和NM之间的通信是基于心跳的传递。NM负责监控资源可用性,报告故障和容器生命周期管理(例如,启动,终止)。 RM从NM的状态快照中汇集其全局视图。作业(job)提交给RM,并通过准入控制阶段,在此期间,安全凭证被验证并执行各种操作和管理检查。接受的(accepted)作业将传递给调度程序以运行。一旦调度程序有足够的资源,应用程序就会从接受状态(accepted)转移到运行状态(running)。除内部簿记外,还为AM分配容器并在集群中的节点上生成容器。已接受的应用程序的记录将写入持久存储,并在RM重新启动或失败时恢复。ApplicationMaster是作业(job)的“head”,管理job的生命周期的各个方面,包括动态增加和减少资源消耗,管理执行流程,处理故障和计算偏差,以及执行其他操作来进行本地优化。事实上,AM可以运行任意用户代码,并且可以用任何编程语言编写,因为与RM和NM的所有通信都是使用可扩展通信协议编码的。YARN对AM做了一些假设,尽管在实践中我们期望大多数工作将使用更高级别的编程框架(例如,MapReduce,Dryad,Tez,REEF等)。通过将所有这些功能委托给AM,YARN的架构获得了大量的可扩展性,编程模型灵活性,以及改进的升级/测试(因为同一框架的多个版本可以共存)。
下图为yarn的框架流程:
大数据系统——Apache Hadoop YARN: Yet Another Resource Negotiator论文分享_第2张图片
下图为yarn的job提交流程:
大数据系统——Apache Hadoop YARN: Yet Another Resource Negotiator论文分享_第3张图片
通常,AM需要利用多个节点上可用的资源(cpus,RAM,磁盘等)来完成作业。为了获取容器,AM向RM发出资源请求。这些请求的形式包括局部性偏好的规范和容器的属性。 RM将根据可用性和调度策略尝试满足来自每个应用程序的资源请求。当为AM分配资源时,RM会为资源生成租约,该租约由后续AM心跳传播提取。当AM将容器租约呈现给NM时,基于令牌的安全机制保证其真实性。一旦ApplicationMaster发现容器可供其使用,它就会使用租约对应用程序特定的启动请求进行编码。在MapReduce中,容器中运行的代码是map任务或reduce任务。如果需要,运行容器可以通过应用程序特定协议直接与AM通信,以报告状态和活跃度并接收框架特定命令,YARN既不促进也不强制执行此通信。总的来说,YARN为应用的生命周期管理和容器监控提供了基础但强大的基础架构,而应用程序特定的语义由每个框架管理。

3.yarn的主要组件

  1. Resource Manager(RM):ResourceManager有两个公共接口,分别面向:1)客户端提交应用程序,2)ApplicationMaster动态协商对资源的访问,以及一个面向NodeManagers的内部接口,用于集群监视和资源访问管理。RM将集群状态的全局模型与运行的应用程序报告的资源需求摘要进行匹配。这使得可以紧密地实施全局调度属性(YARN中的不同调度程序关注于不同的全局属性,例如容量或公平性)。通信消息和调度程序状态必须紧凑且高效,以便RM根据应用程序需求和集群大小进行扩展。捕获资源请求的方式在捕获资源需求的准确性和紧凑性之间取得平衡。幸运的是,调度程序仅处理每个应用程序的整体资源配置,忽略了本地优化和内部应用程序流。YARN完全脱离了静态分区;它将集群资源视为(离散化的)连续体,这为集群利用率带来了显着的改进。
    ApplicationMasters根据一个或多个ResourceRequests编码他们对资源的需求,每个ResourceRequests跟踪:
    a.容器数量,如200个容器;
    b.每个容器的资源,如<2GB RAM,1 CPU>
    c.局部性信息
    d.应用请求的优先级
  2. Application Master(AM):一个应用程序可以是静态的进程集,工作的逻辑描述,甚至是长期运行的服务。ApplicationMaster是协调应用程序在集群中执行的进程,但它本身就像任何其他集群中运行容器。 RM的一个组件协商容器以生成此引导过程。 AM定期向RM发送心跳以确认其活动并更新其需求记录。在构建其需求模型后,AM在心跳消息中将其偏好和约束编码到RM。为响应后续心跳,AM将在绑定到集群中特定节点的资源束上接收容器租约。基于它从RM接收的容器,AM可以更新其执行计划。与某些资源模型相比,对应用程序的分配是后期绑定:生成的进程不是绑定到请求,而是绑定到租约,导致AM发出请求的条件在收到其资源时可能不会保持为真,但容器的语义是可替代的和框架特定的。AM还将更新其资源要求发送到RM,因为它收到的容器会影响其当前和未来的要求。
    由于RM不解释容器状态,因此AM确定NM通过RM报告的容器退出状态成功或失败的语义。由于AM本身就是一个在不可靠硬件集群中运行的容器,因此它应该设计为能够抵御故障。YARN为恢复提供了一些支持,但由于容错和应用程序语义紧密交织在一起,因此大部分负担都落在了AM上
  3. Node Manager(NM):NodeManager是YARN中的“worker”后台程序。它进行容器租约身份验证,管理容器的依赖关系,监视其执行情况,并为容器提供一组服务。NM报告此节点上可用的内存,CPU和其他资源,并为YARN分配。在向RM注册后,NM心跳其状态并接收指令。YARN中的所有容器(包括AM)都由容器启动上下文(container launch context,CLC)描述。此记录包括环境变量的映射,存储在远程可访问存储中的依赖关系,安全性令牌,NM服务的有效负载以及创建该过程所需的命令。在验证了租约的真实性之后,NM确定了容器的环境,包括使用租约中指定的资源约束初始化其监控子系统。为了启动容器,NM将所有必要的依赖项:数据文件,可执行文件,tarball等复制到本地存储。如果需要,CLC还包括用于验证下载的凭据。依赖关系可以在应用程序中的容器之间,由同一租户启动的容器之间,甚至在租户之间共享,通过CLC进行。NM最终垃圾收集运行容器未使用的依赖项。 NM还将按照RM或AM的指示杀死容器。当RM报告其拥有的应用程序已完成,当调度程序决定将其发送给另一个租户时,或者当NM检测到容器超过其租约的限制时,容器可能会被杀死。当不再需要相应的工作时,AM可以请求杀死容器。每当容器退出时,NM将清理其在本地存储中的工作目录。应用程序完成后,其容器拥有的所有资源将在所有节点上丢弃,包括仍在群集中运行的任何进程。NM还定期监视物理节点的运行状况。它监视本地磁盘的任何问题,并经常运行管理配置脚本,反过来可以指向任何硬件/软件问题。当发现这样的问题时,NM将其状态改变为不健康状态并报告给RM相同的情况,然后使调度程序特定决定杀死容器和/或停止此节点上的未来分配,直到解决健康问题。除上述内容外,NM还为在该节点上运行的容器提供本地服务。例如,日志聚合服务,该服务将在应用程序完成后将应用程序写入的数据上载到HDFS的stdout和stderr。
  4. 框架/应用writers:
    a.ApplicationMaster通过CLC提交任务给RM
    b.RM开启AM,AM向RM进行注册,并通过心跳协议周期性向RM汇报生命周期和需求
    c.一旦RM分配出容器,AM构建出一个CLC,来启动响应NM上的容器,同时检测容器的状态信息。
    d.一旦AM结束它的工作,应该从RM注册信息中剔除相关注册信息,然后退出
    e.可选的,框架作者可以添加控制信息,来汇报Job状态信息。
    即使是简单的AM也可能相当复杂;具有少量功能的分布式shell示例需要超过450行的Java代码。YARN附带的客户端库:YarnClient,NMClient,AMRMClient作为更高级别的API以避免对低级协议进行编码。
    下一篇:Hive- A Warehousing Solution Over a Map-Reduce Framework

你可能感兴趣的:(大数据)