其他分享
首页 > 其他分享> > Hadoop-第七周

Hadoop-第七周

作者：互联网

一、理解RM基本职能和内部架构

ResourceManager是整个YARN集群中最重要的组件之一，它的设计直接决定了系统的可扩展性、可用性和容错性等特点，它的功能较多，包括ApplicationMaster管理（启动、停止等）、NodeManager管理、Application管理、状态机管理等

ResourceManager负责集群中所有资源的统一管理和分配，它接收来自各个节点的资源汇报信息，并把这些信息按照一定的策略分配给各个应用程序

1.1 ResourceManager基本职能

1.1.1 ResourceManager需通过两个RPC协议与NodeManager和AppMaster交互,具体如下 :

 

 

1.1.2ResourceManager主要完成以下几个功能 ：

 

1.2 ResouceManager内部架构

1.2.1 内部架构图

1.2.2 内部功能

 

 

二、理解NM基本职能和内部架构

 

NodeManager是运行在单个节点上的代理,它需要与应用程序的的ApplicationMaster和集群管理者ResourceManager交互: 从ApplicationMaster上接收有关Container的命令并执行之(比如启动,停止Container);

向ResourceManager汇报各个Container运行状态和节点健康状况,并领取有关Container的命令(比如清理Container)。

NodeManager是YARN中单个节点上的代理,它管理Hadoop集群中单个计算节点,功能包括与ResourceManager保持通信,管理Container的生命周期,

监控每个Container的资源使用(内存,CPU等)情况,追踪节点健康状况,管理日志和不同应用程序用到的附属服务

 

2.1 NodeManager基本职能

NodeManager需通过两个RPC协议与ResourceManager服务和各个应用程序的ApplicationMaster交互

2.1.1 ResourceTrackerProtocol协议

NodeManager通过该RPC协议向ResourceManager注册,汇报节点健康状况和Container运行状态,并领取ResourceManager下达的命令,包括重新初始化,清理Container占用资源等.在该RPC协议中,ResourceManager扮演RPC Server的角色,而NodeManager扮演RPC Client的角色

ResourceTrackerProtocol协议主要提供了以下两个RPC函数

(1) registerNodeManager

NodeManager启动时通过该RPC函数向ResourceManager注册,注册信息由RegisterNodeManagerRequest封装的,包括如下三部分内容 :

ResourceManager将通过registerNodeManager函数向NodeManager返回一个RegisterNodeManagerResponse类型的对象,主要包含以下信息 :

(2) nodeHeartbeat

NodeManager启动后,定期通过该RPC函数向ResourceManager汇报Container运行信息和节点健康状况,并领取新的命令,比如杀死一个Container

2.1.2 ContainerManagementProtocol协议

应用程序的ApplicationMaster通过该RPC协议向NodeManager发起针对Container的相关操作,包括启动Container,杀死Container,获取Container

ContainerManagementProtocol协议主要提供了以下三个RPC函数 :

 

2.2 NodeManager内部架构

 

三、理解资源调度器FairScheduler调度原理

3.1 代码

各个类作用的简要描述:

1. AllocationConfigurationException, 如果配置文件出错会抛出此异常.

2. AppSchedulable 一个可以提交task的实体, 继承于Schedulable,

3. FairScheduler 调度器的主体部分

4. FairSchedulerConfiguration的配置常量和默认值

5. FairSchedulerEventLog 封装了LOG, 用于把调度事件写到指定的log文件中

6. FifoAppComparator 继承于Comparator, 对比两个AppSchedulable的大小, 首先是Priority, 然后是startTime, 最后对比ApplicationId.

7. FSQueue, fairscheduler中的组信息 类

8. FSQueueSchedulable继承于Schedulable, 一个可以提交task的实体

9. FSSchedulerApp继承于SchedulerApp, 从调度器的角度来看, 每个在RM中正在运行的应用程序都是此类的实例.

10. NewJobWeightBooster, 实现了WeightAdjuster接口, 用于更新AppSchedulable的权重, Weight.

11. QueueManager, 维护一个组队列, 并提供更新方法, fairscheduler调用.

12. Schedulable一个可以提交task的实体

13. SchedulingAlgorithms, 工具类, 包括fair scheduler使用到的调度算法.

14. SchedulingMode, enum类型, 包括FAIR, FIFO. 每个组内的调度模式.

15. 接口WeightAdjuster, 权重修改接口

3.2 Fairscheduler的原理

当 NM (NodeManager的简称)向RM (ResourceManager的简称)发送心跳后, 会调用调度器的nodeUpdate()方法,流程如下:

1. Processing the newly launched containers

2. Process completed containers

3. Assign new containers

a) Check for reserved applications

Reserved, 预留的意思, If we have have an application that has reserved a resource on this node already, we try to complete the reservation.

b) Schedule if there are no reservations. schedule at queue which is furthest below fair share.

    i. 这里首先获取所有组(getQueueSchedulables), 然后对他们排序, 使用SchedulingAlgorithms. FairShareComparator类排序.

    ii. 然后从第一个组开始, 把资源分配给它, 并开始组内分资源,

    iii. 如果未分配给第一组, 则分给下一组, 如果分给了第一组, 则继续到第一步. 若未分配给第一个组, 或重复分配给某一组, 或大于maxAssign, 则退出循环.

 

3.3 SchedulingAlgorithms.FairShareComparator排序算法

两个组, 排序的规则是:

1. 一个需要资源, 另外一个不需要资源, 则需要资源的排前面

2. 若都需要资源的话, 对比 使用的内存占minShare的比例, 比例小的排前面, (即尽量保证达到minShare)

3. 若比例相同的话, 计算出使用量与权重的比例, 小的排前面, 即权重大的优先, 使用量小的优先.

4. 若还是相同, 提交时间早的优先, app id小的排前面.

3.4 配置方法

首先在yarn-site.xml中，将配置参数yarn.resourcemanager.scheduler.class设置为org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.FairScheduler。

Fair Scheduler的配置选项包括两部分，其中一部分在yarn-site.xml中，主要用于配置调度器级别的参数，

另外一部分在一个自定义配置文件（默认是fair-scheduler.xml）中，主要用于配置各个队列的资源量、权重等信息。

3.4.1 配置文件yarn-site.xml\

（1） yarn.scheduler.fair.allocation.file ：自定义XML配置文件所在位置，该文件主要用于描述各个队列的属性，比如资源量、权重等，具体配置格式将在后面介绍。

（2）  yarn.scheduler.fair.user-as-default-queue：当应用程序未指定队列名时，是否指定用户名作为应用程序所在的队列名。如果设置为false或者未设置，所有未知队列的应用程序将被提交到default队列中，默认值为true。

（3）  yarn.scheduler.fair.preemption：是否启用抢占机制，默认值是false。

（4）  yarn.scheduler.fair.sizebasedweight：在一个队列内部分配资源时，默认情况下，采用公平轮询的方法将资源分配各各个应用程序，而该参数则提供了另外一种资源分配方式：按照应用程序资源需求数目分配资源，即需求资源数量越多，分配的资源越多。默认情况下，该参数值为false。

（5）  yarn.scheduler.assignmultiple：是否启动批量分配功能。当一个节点出现大量资源时，可以一次分配完成，也可以多次分配完成。默认情况下，该参数值为false。

（6）  yarn.scheduler.fair.max.assign：如果开启批量分配功能，可指定一次分配的container数目。默认情况下，该参数值为-1，表示不限制。

（7）  yarn.scheduler.fair.locality.threshold.node：当应用程序请求某个节点上资源时，它可以接受的可跳过的最大资源调度机会。当按照分配策略，可将一个节点上的资源分配给某个应用程序时，如果该节点不是应用程序期望的节点，可选择跳过该分配机会暂时将资源分配给其他应用程序，直到出现满足该应用程序需的节点资源出现。通常而言，一次心跳代表一次调度机会，而该参数则表示跳过调度机会占节点总数的比例，默认情况下，该值为-1.0，表示不跳过任何调度机会。

（8）  yarn.scheduler.fair.locality.threshold.rack：当应用程序请求某个机架上资源时，它可以接受的可跳过的最大资源调度机会。

（9）  yarn.scheduler.increment-allocation-mb：内存规整化单位，默认是1024，这意味着，如果一个Container请求资源是1.5GB，则将被调度器规整化为ceiling(1.5 GB / 1GB) * 1G=2GB。

（10）  yarn.scheduler.increment-allocation-vcores：虚拟CPU规整化单位，默认是1，含义与内存规整化单位类似。

3.4.2 自定义配置文件

Fair Scheduler允许用户将队列信息专门放到一个配置文件（默认是fair-scheduler.xml），对于每个队列，管理员可配置以下几个选项：

（1）  minResources ：最少资源保证量，设置格式为“X mb, Y vcores”，当一个队列的最少资源保证量未满足时，它将优先于其他同级队列获得资源，对于不同的调度策略（后面会详细介绍），最少资源保证量的含义不同，对于fair策略，则只考虑内存资源，即如果一个队列使用的内存资源超过了它的最少资源量，则认为它已得到了满足；对于drf策略，则考虑主资源使用的资源量，即如果一个队列的主资源量超过它的最少资源量，则认为它已得到了满足。

（2）  maxResources：最多可以使用的资源量，fair scheduler会保证每个队列使用的资源量不会超过该队列的最多可使用资源量。

（3）  maxRunningApps：最多同时运行的应用程序数目。通过限制该数目，可防止超量Map Task同时运行时产生的中间输出结果撑爆磁盘。

（4）  minSharePreemptionTimeout：最小共享量抢占时间。如果一个资源池在该时间内使用的资源量一直低于最小资源量，则开始抢占资源。

（5）  schedulingMode/schedulingPolicy：队列采用的调度模式，可以是fifo、fair或者drf。

（6）  aclSubmitApps：可向队列中提交应用程序的Linux用户或用户组列表，默认情况下为“*”，表示任何用户均可以向该队列提交应用程序。需要注意的是，该属性具有继承性，即子队列的列表会继承父队列的列表。配置该属性时，用户之间或用户组之间用“，”分割，用户和用户组之间用空格分割，比如“user1, user2 group1,group2”。

（7）  aclAdministerApps：该队列的管理员列表。一个队列的管理员可管理该队列中的资源和应用程序，比如可杀死任意应用程序。

3.4.3 管理员也可通过以下参数设置以上属性的默认值：

 

（1）  userMaxJobsDefault：用户的maxRunningJobs属性的默认值。

（2） defaultMinSharePreemptionTimeout ：队列的minSharePreemptionTimeout属性的默认值。

（3）  defaultPoolSchedulingMode：队列的schedulingMode属性的默认值。

（4）  fairSharePreemptionTimeout：公平共享量抢占时间。如果一个资源池在该时间内使用资源量一直低于公平共享量的一半，则开始抢占资源。
 

3.4.4 举例

yarn-site.xml

<property>
  <name>yarn.resourcemanager.scheduler.class</name>
  <value>org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.FairScheduler</value>
</property>
fair-scheduler.xml

<?xml version="1.0"?>
<allocations>
  <queue name="sample_queue">
    <minResources>1000</minResources>
    <maxResources>9000</maxResources>
    <maxRunningApps>50</maxRunningApps>
    <weight>2.0</weight>
    <schedulingMode>fair</schedulingMode>
    <aclSubmitApps> sample_queue,yuling.sh</aclSubmitApps>
    <aclAdministerApps> sample_queue,yuling.sh</aclAdministerApps>
  </queue>
  <queue name="default">
    <minResources>1000</minResources>
    <maxResources>9000</maxResources>
    <maxRunningApps>50</maxRunningApps>
    <weight>2.0</weight>
    <schedulingMode>fair</schedulingMode>
    <aclSubmitApps> yuling.sh</aclSubmitApps>
    <aclAdministerApps> a</aclAdministerApps>
  </queue>
 
  <userMaxAppsDefault>5</userMaxAppsDefault>
</allocations>

3.4.5 疑问解答

1、fair-scheduler.xml中的weight的作用是什么？怎么样能测出来weight的作用？

 weight主要用在资源共享之时，weight越大，拿到的资源越多。比如一个pool中有20GB内存用不了，这时候可以共享给其他pool，其他每个pool拿多少，就是由权重决定的

2、使用fair调度策略，会不会出现负载不均衡的现象？网上说：默认批处理会出现负载不均衡，但每次都是均衡的， 涉及到yarn.scheduler.fair.max.assign 和yarn.scheduler.assignmultiple 两个配置项。这块到底是什么样的？

fair也会出现，均衡不均衡是相对的，只不多这两个参数可以缓解。

3、动态更新资源配额
Fair Scheduler除了需要在yarn-site.xml文件中启用和配置之外，还需要一个XML文件来配置资源池以及配额，而该XML中每个资源池的配额可以动态更新，之后使用命令：yarn rmadmin –refreshQueues 来使得其生效即可，不用重启Yarn集群。

需要注意的是：动态更新只支持修改资源池配额，如果是新增或减少资源池，则需要重启Yarn集群。
 

四、理解资源调度器CapacityScheduler调度原理

4.1 基本思想


容量调度器以队列为单位划分资源，每个队列都有资源使用的下限和上限。每个用户也可以设定资源使用上限。一个队列的剩余资源可以共享给另一个队列，其他队列使用后还可以归还。管理员可以约束单个队列、用户或作业的资源使用。支持资源密集型作业，可以给某些作业分配多个slot（这是比较特殊的一点）。支持作业优先级，但不支持资源抢占。

这里明确一下用户、队列和作业之间的关系。Hadoop以队列为单位管理资源，每个队列分配到一定的资源，用户只能向一个或几个队列提交作业。队列管理体现为两方面：1. 用户权限管理：Hadoop用户管理模块建立在操作系统用户和用户组之间的映射之上，允许一个操作系统用户或者用户组对应一个或者多个队列。同时可以配置每个队列的管理员用户。队列信息配置在mapred-site.xml文件中，包括队列的名称，是否启用权限管理功能等信息，且不支持动态加载。队列权限选项配置在mapred-queue-acls.xml文件中，可以配置某个用户或用户组在某个队列中的某种权限。权限包括作业提交权限和作业管理权限。2. 系统资源管理：管理员可以配置每个队列和每个用户的可用资源量信息，为调度器提供调度依据。这些信息配置在调度器自己的配置文件（如Capacity-Scheduler.xml）中。关于每个配置文件的常见内容见附录。

 

4.2 整体架构

总体来说，容量调度器的工作流程分5个步骤：

1. 用户提交作业到JobTracker。

2. JobTracker将提交的作业交给Capacity Scheduler的监听器JobQueuesManager，并将作业加入等待队列，由JobInitializationPoller线程初始化。

3. TaskTracker通过心跳信息要求JobTracker为其分配任务。

4. JobTracker调用Capacity Scheduler的assignTasks方法为其分配任务。

5. JobTracker将分配到的任务返回给TaskTracker。

接下，我们结合源代码依次研究上述过程。
 

4.3  实现细节

容量调度器（Capacity Scheduler）原理和源码研究

 

五、熟悉YARN应用程序设计方法

YARN上的应用程序主要分为短应用程序（MapReduce）和长应用程序（Storm）

通常而言，编写一个YARN Appcalition会涉及3个RPC协议：

  1. ApplicationClientProtocol
  2. ApplicationMasterProtocol
  3. ContainerManagementProtocol

5.1  客户端编写流程

步骤一 Client通过RPC函数ApplicationClientProtocol#getNewApplication从ResourceManager中获取唯一的application ID

步骤二 Client通过RPC函数ApplicationClientProtocol#submitApplication将ApplicationMaster提交到ResourceManager上

客户端编程库（Yarnclient）

ApplicationMaster设计

AM需要与RM和NM两个服务交互
通过与RM交互，AM可获得任务计算所需的资源
通过与NM交互，AM可启动计算任务（container），并监控直到运行完成

AM-RM编写流程

  1. AM通过RPC函数ApplicationMasterProtocol#registerApplicationMaster向ResourceManager注册
    一旦ApplicationMaster注册成功，RM会为它返回一个RegisterApplicationMasterResponse类型的返回值，该对象包含应用程序可申请的最大资源量、应用程序访问控制列表等信息
  2. ApplicationMaster通过RPC函数ApplicationMasterProtocol#allocate向RM申请资源（以container形式表示）
  3. Application通过RPC函数ApplicationMasterProtocol#finishApplicationMaster告诉Res应用程序执行完毕，并退出。
    ApplicationMaster将重复步骤2，不断为应用程序申请资源，知道资源得到满足或者整个应用程序运行完成。

AM-NM编写流程

  1. ApplicationMaster将申请到的资源二次分配给内部的任务，并通过RPC函数ContainerManagementProtocol#startContainer与对应的NM通信以启动Container（包含任务描述，资源描述等信息），该函数的参数类型为StartContainerRequest，主要包含一个类型为StartContainerRequest的字段
  2. 为了实时掌握各个Container运行状态，AM可通过RPC函数ContainerManagementProtocol#getContainerStatus向NM询问Container运行状态，一旦发现某个Container运行失败，ApplicationMaster可尝试重新为对应的任务申请资源
  3. 一旦一个Container运行失败后，AM可通过RPC函数ContainerManagementProcotol#stopContainer释放Container。

ApplicationMaster编程库

AM-RM编程库

AM-NM编程库

 

 

Yarn应用程序开发和设计流程

 

标签：Container,第七,ResourceManager,队列,Hadoop,应用程序,RPC,NodeManager
来源： https://blog.csdn.net/weixin_44588186/article/details/116143418