YARN 权威指南 NOTE1
本文主要是阅读《HADOOP YARN 权威指南》所记录的学习笔记。整体来说，该书主要介绍了YARN的基础知识，包括YARN的使用，安装，架构等。不涉及代码实现。
如今，越来越多的应用迁移到yarn上。MR on yarn， Spark on yarn， Hbase on yarn， storm on yarn 。这些系统借助yarn获得了更好的资源调度，资源隔离，弹性伸缩，容灾容错等。
1. YARN组件（第三章 YARN的核心概念）
1.1 ResourceManager
是一个调度器，根绝应用程序的资源请求严格的限制系统的可用资源
1.2 ApplicationMaster
实际上是一个特定框架的实例。负责与ResourceManager协商资源，并合NodeManager协同工作来执行和监控Container以及他们的资源消耗。它有责任与ResourceManager协商并获取合适的资源container，跟踪他们的状态，以及监控他们的进程。
1.3 Container
一个ApplicationMaster可以请求非常具体的资源。
-
资源名称（主机名称，机架名称，以及可能复杂的网络拓扑）
-
内存（大小）
-
CPU（核数/类型）
-
其他资源（disk io gpu）
一个应用程序通过ApplicationMaster请求特定的资源需求来满足他的资源需求，Scheduler会分配一个container来响应资源请求。
一个ResourceRequest具有如下形式 <资源名称，优先级，资源需求，container数量>
-
资源名称：资源期望所在的主机名，机架名，*表示没有特殊需求
-
优先级：是应用程序内部的优先级。应用的优先级会调整内部多个ResourceRequest的次序
-
资源需求： cpu mem
本质上container是一种资源分配形式。container只是使用服务器行指定资源的权利。ApplicationMaster必须提供更多的信息给NodeManager才能启动Container。Container的启动API是和平台无关的，包括：
-
启动container内进程的命令行
-
环境变量
-
启动container所需要的本地资源。如jar共享对象以及辅助的数据文件
-
安全相关的令牌
2. YARN组件的功能概述（第四章 YARN组件的功能概述）
2.1 YARN Scheduler概述
-
FIFO调度器：不考虑作业的优先级和范围
-
Capacity调度器：管理员使用总槽（或处理器）容量的预定值配置一个或者多个队列。这样子分配保证了每个队列的最小使用资源量。管理员为每个队列配置了软限制和可选的硬限制。每个队列都有严格的ACL（访问控制列表）用以控制那些用户可以向哪些队列提交任务。 Capacity允许共享集群。同时给予每个用户或者组一定的最小资源保证。这些最小值在不需要的时候可以被舍弃掉，超出的容量将会给那些最饥饿的队列。其中饥饿程度用运行中或者已用的队列容量来衡量。
-
Fair调度器：支持层次化队列。可以保证最小资源，设置队列最大资源；可以设置运行job数
2.2 Container
Container是单个节点上如RAM CPU核核磁盘等物理资源的集合。
2.3 NodeManager
是yarn节点上的“工作进程”的代理。管理计算节点，职责包括和ResourceManager保持通信，管理container的生命周期。监控container的资源使用情况。
在启动的时候向ResourceManager注册，然后发送包含自身的心跳，并等待来自ResourceManager的指令。它的主要目标是管理ResourceManager分配给他的container
2.4 ApplicationMaster
与ResourceManager协商资源
与NodeManager系统工作来执行监控任务
2.5 资源模型
image
2.6 管理应用程序的依赖文件
当启动一个container时候，ApplicationMaster可以指定该Container需要的所有文件。因此，这些文件都应该被本地化。
可见行
-
public：可以被任何用户的container访问
-
private：节点上同一用户的应用程序共享访问
-
application：被同意应用程序的container共享
localResource生命周期
-
Public：localResource在container或者应用程序结束也不会被删除。但是在磁盘紧张是会删除。
-
Private：和public具有相同的生命周期
-
Application：应用程序结束后立即被删除
3. 基本的YARN管理（第六章 YARN的管理）
-
Capacity 调度器配置：capacity-scheduler.xml
-
管理yarn作业：yarn application 命令
-
设置container的内存：yarn-site.xml
image
-
设置mapreduce配置项：mapred-site.xml
image
4. YARN 的架构指南（第七章 YARN的架构指南）
4.1 ResourceManager
image
-
客户端和resourceManager交互
-
admin service
-
cliend service
-
web service
-
application ACLs Manager
-
-
应用程序和resourceManager交互
-
ApplicationMasterService：注册/取消/终止注册请求 ；container分配/释放请求
-
AMLivelinessMonitor：监控am的存活
-
-
节点与resourceManager通信
-
Resource Track Service：NodeManager周期性的发送心跳给RM，该组件负责相应所有来自于节点的RPC请求。 注册新节点/相应节点的心跳
-
NMLivelinessMonitor：NM存活监控，该组件跟踪跟踪每个节点的标识符和它最后的心跳时间。任何没有在配置的时间间隔发送心跳的节点被认为死亡，且在RM中超时，所有运行在超时节点上container被标记为死亡。而且不会有新的container调度到该节点上。
-
Node-list Manager：RM内存中的一个集合。包含有效的节点和被排除的节点。
-
-
ResourceManager核心组件
-
ApplicationsManager：负责管理已提交的应用程序的集合。在应用程序提交后，首先检查应用程序的规格，拒绝applicationMaster请求资源不合法的应用程序等。记录和管理已经结束的应用程序。
-
ApplicationMaster Launcher：维护一个线程池来设置环境，和NodeManager通信来拉起新提交的AppMaster。
-
YARN SCheduler ：调度器
-
ContainerAllocationExpirer
-
-
安全相关组件
- Secret Manager：负责管理令牌和私钥，这些用于对各个RPC接口的请求上进行认证/授权。
4.2 NodeManager
image
-
NodeStatusUpdater：该组件向ResourceManager发送注册信息。/ 通知NM来杀死container
-
ContainerManager：核心组件，管理运行在NM上的container
NodeManager的重要功能：
-
container启动
-
用户日志管理和聚集
-
MR shuffle 辅助服务
4.3 ApplicationMaster
每个应用程序的ApplicationMaster都是一个引导进程，一旦应用程序的提交通过了，且自身加载完成，他就启动所有工作。
image
一旦AM成功启动，将负责一下内容：
-
初始化向RM报告自己活跃信息的进程
-
计算应用程序的资源需求
-
将需求转化为Scheduler 能够理解的ReqsourceRequest
-
与调度器协商资源
-
与NodeManager合作使用分配的Container
-
跟踪正在运行的container的状态，监控他们的进程
-
对container或者节点失败的情况进行处理，在必要的情况下重新申请资源。
4.4 Container
container运行环境
-
静态信息
-
动态信息
5 YARN Capacity调度器（第八章 YARN中Capacity调度器）
Capacity通过队列的容量属性，最小用户占比和限制属性来支持这些特征。他的目的是共享一个单个的yarn集群，同时保证每个组织所分配的容量。为了提高利用率，组织可以使用属于其他组织的闲用资源。Capacity也执行严格的限制来避免单个应用程序，用户或者队列独占集群从而影响其他租户。
YARN中的调度是更细粒度和动态的。YARN中的队列仅是一个物理节点上一个逻辑资源图。
5.1 配置
Yarn-site.xml中配置
yarn.resourcemanager.scheduler.class: xxx.xxx.xxx.CapacityScheduler
命令 yarn readmin -refreshQueue 重新加载配置文件
5.2 队列
YARN中一个基本的调度单元是队列。一个队列或者是多个用户提交的应用程序的逻辑集合，或是多个队列的逻辑集合。
-
一个简短的队列名
-
一个完整的队列路径
-
相关的子队列活应用程序列表
-
该队列保证的容量
-
队列能够达到的最大容量
-
活跃用户列表和用户之间共享的限制
-
队列的状态
-
访问队列的ACL权限
5.3 层级队列
层级队列确保首先保证子队列共享组织的资源，然后才允许其他组织使用该队列空闲的资源。这种设计使每个组织有更多的控制权保证他们资源以可预见的方式使用。调度算法的工作方式如下：
-
在层级结构的每一层，每一个父队列根据需求值来保证子队列的顺序。在任何时候队列的排序是由每个队列根据当前使用的资源占容量的比例确定的。（如果比例相同 根据队列的路径名称确认）
-
根队列知道如何将集群容量分配给第一层的父队列，并对每一层的父队列进行递归调用。
-
每个夫队列对所有的字队列也遵循相同的容量限制并以此来调度。
-
叶子队列管理活跃的应用程序，可能来自多个用户。并以FIFO方式调度资源。同时遵循每个用户可以使用队列资源的限制。
image
层级队列的配置
-
Propety：yarn.scheduler.capacity.root.queues
-
Value:finance-wizards,grump-engineers,marketing-moguls
-
Propety:yarn.scheduler.capacity.finance-wizards.queues
-
Value:metr-acc,thrifty-treasyrers
5.4 层次队列Capacity管理
xxx
5.5 用户级别限制
字队列具有额外的责任来确保调度由不同的用户提交到该队列应用程序的公平性。在Capacity中用户只被允许提交任务到子队列中。
针对叶子队列 进行用户限制。所有用户的限制都是基于队列的容量。minimum-user-limit-percent ,表示只用来决定一个用户最少能占用队列容量的比例。
5.6 预定
虽然一个节点上有空闲资源，但是在大小上他们还不足以满足最优先的应用程序的资源请求。这种情况通常发生在大内存的应用程序。当这样的程序在籍群众运行时，一个普通程序的container运行结束后，从而释放前面使用的资源进入调度的周期，节点将用有空闲的资源，但是大内存应用程序并不能利用到他们，因为资源仍然太小。如果任其发展，这种会造成资源密集型应用程序的饥饿。
通过预定的功能，capacity调度器解决了这个问题。对于拥有预定的调度器调度流程如下：
-
当一个节点报告完成了一个container，从而增加一定量的空闲可用资源。调度器根据容量和最大容量选择合适的队列。
-
在该队列，调度通过FIFO顺序选择应用程序，同时要考虑用户级别限制。一旦找到一个有资源需求的应用程序，检查该节点的空闲容量是否满足该应用程序的资源需求。
-
如果大小不匹配，capacity调度器立即在该节点珊瑚创建一个container的预定
-
一旦一个节点上为一个应用程序创建一个预定，调度器就不会把资源分配给其他队列，应用程序，或者container，直到该container预定的资源需求得到满足。
-
有预定的节点最终回报告有足够的container已经结束。这样该节点的空闲资源能够匹配预定的大小。这时，capacity把预定标记为完成。然后删除这个预定，并在该节点上分配一个container。
-
与此同时，其他节点可以满足该应用程序的资源需求，这样该程序可能不需要之前的预定。这样的情况下，当下一次为预定的节点做调度时，就取消这个预定。
-
为限定预定的数量无限增长，防止潜在的调度死锁。capacity限定每个节点只能有一个活跃的预定来解决这个问题。
5.7 队列状态
-
运行
-
终止
5.8 应用程序的限定
yarn.scheduler.capacity.maximum-applications: 活跃应用程序的总数。
yarn.scheduler.capacity.<queue-path>.maximum-applications：每个队列最大允许应用程序总数。
网友评论