大家都用哪个网站做读书笔记,南京做网站品牌,产品运营推广方案,网站域名注册证明引入
我们前面篇章有提到#xff0c;和MapReduce的论文不太一样。在Hadoop1.0实现里#xff0c;每一个MapReduce的任务并没有一个独立的master进程#xff0c;而是直接让调度系统承担了所有的worker 的master 的角色#xff0c;这就是Hadoop1.0里的 JobTracker。在Hadoop1…引入
我们前面篇章有提到和MapReduce的论文不太一样。在Hadoop1.0实现里每一个MapReduce的任务并没有一个独立的master进程而是直接让调度系统承担了所有的worker 的master 的角色这就是Hadoop1.0里的 JobTracker。在Hadoop1.0里MapReduce论文里面的worker就是TaskTracker用来执行map 和 reduce的任务。而分配任务以及和TaskTracker沟通任务的执行情况都由单一的JobTracker 来负责。
这样实现的好处是比较简单相对的导致了JobTracker的负载过重成为了整个Hadoop 系统“瓶颈”。在Hadoop 2.0Hadoop社区把JobTracker的角色拆分成了进行任务调度的Resource Mananger以及监控单个MapReduce任务执行的Application Master回到了和MapReduce论文相同的架构。
Hadoop 能有今天这个地位Yarn可以说是功不可没。因为有了 Yarn 更多计算框架可以接入到 HDFS 中而不单单是 MapReduceMapReduce 早已经被 Spark 等计算框架赶超而 HDFS 却依然屹立不倒。究其原因正式因为 Yarn 的包容使得其他计算框架能专注于计算性能的提升。HDFS 可能不是最优秀的大数据存储系统但却是应用最广泛的大数据存储系统Yarn 功不可没。
今天我们来看看关于Yarn的涉及与实现。
Yarn
Yarn是“Yet Another Resource Negotiator”的缩写字面意思就是“另一种资源调度器”。
事实上在Hadoop社区决定将资源管理从Hadoop 1中分离出来独立开发Yarn的时候业界已经有一些大数据资源管理产品了比如Mesos等所以Yarn的开发者索性管自己的产品叫“另一种资源调度器”。这种命名方法并不鲜见曾经名噪一时的Java项目编译工具Ant就是“Another Neat Tool”的缩写意思是“另一种整理工具”。
YARN的基本设计思想是将JobTracker拆分成两个独立的服务一个全局的资源管理器ResourceManager和每个应用程序特有的ApplicationMaster。其中ResourceManager负责整个系统的资源管理和分配而ApplicationMaster则负责单个应用程序的管理。
架构设计
YARN总体上仍然是master/slave结构。在整个资源管理框架中ResourceManager为masterNodeManager为slaveResourceManager负责对各个NodeManager上的资源进行统一管理和调度。
当用户提交一个应用程序时需要提供一个用于跟踪和管理这个程序的ApplicationMaster。它负责向ResourceManager申请资源并要求NodeManager启动可以占用一定资源的任务。由于不同的ApplicationMaster分布在不同的节点上因此它们之间不会相互影响。
核心组件
ResourceManager
整个系统有且只有一个 ResourceManager 它是基于应用程序对集群资源的需求进行调度的 Yarn 集群主控节点负责协调和管理整个集群的资源处理客户端请求、启动/监控ApplicationMaster、监控NodeManager、资源分配与调度。
它包含了两个主要的组件调用器(Scheduler)以及应用管理器(ApplicationsManagerASM)。
调度器(Scheduler)
调度器根据容量、队列等限制条件如每个队列分配一定的资源最多执行一定数量的作业等将系统中的资源分配给各个正在运行的应用程序。
从本质上来说定时调度器就是一个资源分配算法或者说是一种策略。当 Client 提交一个任务的时候它会根据所需要的资源以及当前集群的资源状况进行分配。 注意 它只负责向应用程序分配资源并不负责监控或者跟踪应用的执行状态等也不负责重新启动因应用执行失败或者硬件故障而产生的失败任务。 调度器被设计成一个可插拔的组件用户可根据自己的需要设计新的调度器YARN提供了多种直接可用的调度器比如Fair Scheduler和Capacity Scheduler等。 应用管理器(ApplicationsManager)
应用程序管理器负责管理整个系统中所有应用程序包括应用程序提交、与调度器协商资源以启动ApplicationMaster、监控ApplicationMaster运行状态并在失败时重新启动它等。
具体职责包括 应用程序提交 接收客户端提交的应用程序请求。 验证应用程序的配置和资源请求。 资源分配 根据集群的资源情况和调度策略分配资源给各个应用程序。 启动应用程序的第一个容器即 ApplicationMaster 容器。 监控应用程序 监控应用程序的运行状态。 处理应用程序的完成、失败和重试等情况。 维护应用程序队列管理应用程序队列确保资源分配的公平性和高效性。
ApplicationMasterAM
AM是每个应用程序的专属组件负责管理该应用程序的具体执行。用户提交的每个应用程序在启动时都会有一个独立的 AM。
它实际上是一个简化版的JobTracker主要功能包括 与RM调度器协商以获取资源。 与NM通信以启动/停止任务。 监控所有任务的运行状态并在任务运行失败时重新为任务申请资源以重启任务。
ApplicationMaster负责数据切分、为应用程序申请资源并分配给内部任务、任务监控与容错 每当 Client 提交一个 Application 时候就会新建一个 ApplicationMaster 。由这个ApplicationMaster 去与 ResourceManager 申请容器资源获得资源后会将要运行的程序发送到容器上启动然后进行分布式计算。也就是所谓的移动计算
具体职责包括 资源请求 向 ResourceManager 请求资源以运行应用程序的任务。 根据应用程序的需求动态调整资源请求。 任务调度和监控 将获得的资源分配给具体的任务Task。 启动和监控任务的执行处理任务的失败和重试。 任务协调 协调应用程序的所有任务确保任务按计划执行。 收集任务的执行结果并进行必要的合并和处理。 状态报告 向 ResourceManager 报告应用程序的运行状态和进度。 在应用程序完成时通知 ResourceManager 释放资源。 ASM和AM的区别 ApplicationsManagerResourceManager 的一部分管理整个集群中的应用程序生命周期负责资源分配、应用程序提交和监控 启动 ApplicationMaster 容器。 ApplicationMaster 每个应用程序的专属组件管理该应用程序的具体执行负责资源请求、任务调度和监控、任务协调和状态报告 动态调整资源请求确保应用程序的高效执行。 总结ApplicationsManager 负责全局资源管理和调度而 ApplicationMaster 负责具体应用程序的执行和协调。 NodeManager
NM是每个节点上的资源和任务管理器。 它会定时地向RM汇报本节点上的资源使用情况和各个Container的运行状态 它接收并处理来自AM的任务启动/停止等各种请求。
NodeManager 是 YARN 集群当中真正资源的提供者是真正执行应用程序的容器的提供者 监控应用程序的资源使用情况并通过心跳向集群资源调度器 ResourceManager 进行汇报处理来自ResourceManager和ApplicationMaster的命令。
Container
Container是YARN中的资源分配单位它封装了多维度的资源如内存、CPU、磁盘、网络等。当AM向RM申请资源时RM为AM返回的资源便是用Container表示的。YARN中每个任务均会对应一个Container且该任务只能在该Container中执行并仅能使用该容器代表的资源量。需要注意的是Container不同于MRv 1中的slot它是一个动态资源划分单位是根据应用程序的需求动态生成的。
Container 是一个抽象出来的逻辑资源单位。它对任务运行环境的抽象封装了内存、CPU、磁盘、网络等多维资源以及环境变量、启动命令等任务运行相关的信息当AM向RM申请资源时RM为AM返回的资源便是用Container表示的。
由 NodeManager 启动和管理并被它所监控。被 ResourceManager 进行调度。
YARN中每个任务均会对应一个Container且该任务只能在该Container中执行并仅能使用该Container代表的资源量。 注意Container不同于MRv1中的slot它是一个动态资源划分单位是根据应用程序的需求动态生成的。 Container是 Yarn 对资源做的一层抽象。就像我们平时开发过程中经常需要对底层一些东西进行封装只提供给上层一个调用接口一样Yarn 对资源的管理也是用到了这种思想。 Yarn 将CPU核数内存这些计算资源都封装成为一个个Container。 Job提交流程
当用户向YARN中提交一个应用程序后YARN将分两个阶段运行该应用程序 第一个阶段是启动ApplicationMaster 第二个阶段是由ApplicationMaster创建应用程序为它申请资源并监控它的整个运行过程直到运行成功。
流程概述 用户向 YARN 中提交应用程序其中包括 ApplicationMaster 程序启动 ApplicationMaster 的命令用户程序等 ResourceManager 为该程序分配第一个 Container并与对应的 NodeManager 通讯要求它在这个 Container 中启动应用程序 ApplicationMaster ApplicationMaster 首先向 ResourceManager注册这样用户可以直接通过 ResourceManager 查看应用程序的运行状态然后将为各个任务申请资源并监控它的运行状态直到运行结束重复 4 到 7 的步骤 ApplicationMaster 采用轮询的方式通过 RPC 协议向 ResourceManager 申请和领取资源 一旦 ApplicationMaster 申请到资源后便与对应的 NodeManager 通讯要求它启动任务 NodeManager为任务设置好运行环境包括环境变量、jar包、二进制程序等后将任务启动命令写到一个脚本中并通过运行该脚本启动任务。 各个任务通过某个RPC协议向ApplicationMaster汇报自己的状态和进度以让ApplicationMaster随时掌握各个任务的运行状态从而可以在任务失败时重新启动任务。 在应用程序运行的过程中用户可随时通过RPC协议向ApplicationMaster查询应用程序的当前运行状态。 应用程序运行完成后ApplicationMaster 向 ResourceManager 注销并关闭自己。
关于Yarn的RPC
在YARN中任何两个需相互通信的组件之间仅有一个RPC协议而对于任何一个RPC协议通信双方有一端是Client另一端为Server且Client总是主动连接Server因此YARN实际上采用的是拉式pull-based通信模型主要有以下几个RPC协议
Client与RM之间的协议—ClientRMProtocolClient通过该RPC协议提交应用程序查询应用程序状态等。Administrator与RM之间的通信协议—RMAdminProtocolAdministrator通过该RPC协议更新系统配置文件比如节点黑白名单、用户队列权限等。AM与RM之间的协议—AMRMProtocolJob AM通过该RPC协议向RM注册和撤销自己并为各个任务申请资源。AM与NM之间的协议—ContainerManagerAM通过该RPC协议要求NM启动或者停止Container获取各个Container的使用状态等信息。NM与RM之间的协议—ResourceTrackerNM通过该RPC协议向RM注册并定时发送心跳信息汇报当前节点的资源使用情况和Container运行情况。 注意 为了提高Hadoop的向后兼容性和不同版本之间的兼容性YARN中的序列化框架采用了Google开源的Protocol Buffers。 关于RPC可以看这篇文章。 调度策略
Hadoop作业调度器主要有三种FIFO、Capacity Scheduler和Fair Scheduler。
Yarn中FIFO、Capacity、Fair三种资源调度器区别对比如下 Yarn资源调度器 特点 适用场景 FIFO调度器 1)简单易懂无需额外配置。 2)应用按照提交的先后顺序先进先出运行。 3)不适合共享集群每个应用必须等待直到轮到自己运行。 非共享集群对任务执行顺序要求不高的场景。生产环境一般不用。 Capacity调度器开源Yarn默认使用 1)允许多个组织共享集群资源每个组织拥有专门的队列。 2)支持队列的层次划分以及队列资源的灵活配置。 3)可以限制队列的最大容量缓解资源竞争。 共享集群的场景多个组织或团队共享同一集群资源的情况。 Fair调度器CDH默认使用 1)公平地为所有运行的应用分配资源支持多个队列间的资源公平共享。 2)支持动态创建队列并通过一套规则系统确定应用的放置位置。 3)支持资源的抢占功能确保资源的公平分配。 1) 多个用户或组织在共享集群中需要公平地获得资源的场景。 2) 对队列级别的资源控制和细粒度调度策略要求较高的环境。
Hadoop2.x默认的资源调度器是Capacity Scheduler。(可以查看yarn-default.xml)
FIFO调度器First-In-Fist-Out Scheduler
Yarn中最简单的调度器。FIFO Scheduler 会将提交的应用程序按提交顺序放入一个先进先出的队列中进行资源分配时先给队列中最头上的应用分配资源待头上的应用资源需求满足后再给下一个应用分配资源以此类推。这种调度器调度资源时有可能某个资源需求大的应用占用所有集群资源从而导致其他的应用被阻塞。
FIFO调度器只支持单队列先进队列的任务先获取资源排在后面的任务只能等待不能同时保证其他任务获取运行资源这种调度器很少使用。
Capacity调度器Capacity Schduler
Yarn中默认配置的资源调度器允许多租户安全地共享一个大型集群。Capacity调度器中支持配置多个资源队列可以为每个资源队列指定最低、最高可使用的资源比例在进行资源分配时优先将空闲资源分配给“实际资源/预算资源”比值最低的队列每个资源队列内部采用FIFO调度策略。
Capacity调度器的核心思想是提前做预算在预算指导下分享集群资源。其特点如下
支持多租户共享集群通过配置可以限制每个用户使用的资源比例。集群资源由多个资源队列分享。每个队列需要预先配置资源分配比例最低、最高使用的资源比例即事先规划好预算比例。空闲资源优先分配给“实际资源/预算资源”比值最低的队列。每个队列内部任务采用FIFO调度策略。如果一个资源队列中资源有剩余可以共享给其他需要资源的队列但一旦该资源队列有任务提交运行共享给其他资源队列的资源会及时回收供该资源队列使用。
Capacity资源分配策略
Capacity Scheduler调度器中如果有多个资源队列这些个资源队列进行资源分配时优先分配给“实际资源/预算资源”比值最低的队列。每个队列中有多个Job给每个队列内的多个Job进行资源分配时默认按照Job的FIFO顺序进行资源分配用户也可以提交JOB时指定任务执行的优先级优先级最高的先分配资源。
Fair调度器Fair Scheduler
一个将Yarn资源公平的分配给各个Application的资源调度方式这种调度方式可以使所有Application随着时间的流逝可以获取相等的资源份额其设计目标就是根据定义的参数为所有的Application分配公平的资源。
FairScheduler资源调度核心思想就是通过资源平分的方式动态分配资源无需预先设定资源比例实现资源分配公平其特点如下
支持多租户共享集群。与Capacity调度器一样集群资源由多个资源队列分享。与Capacity调度器一样如果一个资源队列中资源有剩余可以共享给其他需要资源的队列但一旦该资源队列有任务提交运行共享给其他资源队列的资源会及时回收供该资源队列使用。与Capacity调度器一样可以设置队列最小资源允许将最小份额资源分配给资源队列保证该资源队列可以启动任务。默认情况允许所有Application程序运行也可以限制每个资源队列中同时运行Application的数量。根据Appliation的配置抢占和分配资源可以是友好的或者强制的默认不启用资源抢占。
Fair资源分配策略
Fair Scheduler支持多资源队列每个资源队列进行资源调度时按照配置指定的权重平均分配资源。在每个资源队列中job的资源调度策略有三种选择FIFO、Fair默认、DRF这三种Job调度策略解释如下。
FIFOJob按照先进先出进行资源调度如果该队列中有多个Job第一个Job分配完资源后还有资源供第二个Job运行那么可能存在多个Job并行运行的情况。这种情况下与Capacity调度器一样。FairFairScheduler中每个资源队列默认资源调度策略只基于内存调度分配资源按照不同Job的使用内存比例平均分配资源。DRF基于vcores和内调度分配资源。 备注DFR(Dominant Resource Fairness主导资源公平性)。 在Yarn中如果进行资源调度时只考虑单一资源类型如内存那么这个事情就很简单只需要将不同资源队列/Job按它们使用的内存量比例进行调度资源即可FIFO/Fair就是只基于内存进行资源调度分配。然而当涉及多个资源类型时情况就变得复杂例如一个用户的Application需要大量的CPU但使用很少内存而另一个用户的Application需要很少的CPU但大量的内存这里不能仅考虑内存比值来进行资源调度分配否则可能出现资源分配不合理情况这种情况除了内存之外还要考虑Application的Vcore使用情况这就可以使用DRF资源分配策略。 DRF(Dominant Resource Fairness,资源分配策略中会查看每个Application中主导资源Dominant Resource是什么并将其作为集群调度资源的衡量标准。例如yarn集群中共100个CPU和10TB内存应用程序A请求容器2个CPU300GB内存应用程序B请求容器6个CPU100GB内存。A的请求是集群的2%3%所以内存是主导资源B的请求是集群的6%1%所以CPU是主导资源由于B程序的容器请求主要资源是A程序容器请求主要资源的2倍6%/3%2所以在DRF资源分配策略下B程序最大可使用在集群2/3资源。 总结
今天梳理了关于Yarn的核心设计与实现由于要回老家过年了笔记本不太方便捋源码MR和Yarn的深入源码分析文章就暂时延后到年后回来再写。
我们目前见识了很多大数据技术的设计与实现会发现有很多类似的设计甚至可以用“新瓶装旧酒”来形容。无论大数据技术如何变化不变的是那些凝结了人类历史知识和经验的技术精华过年这几天我会专门开一个基础专题系列让我们重点看一下这些技术精华是什么。
最后提前祝大家新年快乐
