Hadoop Yarn源码

Hadoop 2.6.0下面的关于Yarn工程，如下所示，主要有以下七个module：

hadoop-yarn-api：和外部平台交互的接口
hadoop-yarn-applications
hadoop-yarn-client
hadoop-yarn-common：yarn client和server可以用到的一些实用工具
hadoop-yarn-registry
hadoop-yarn-server：hadoop-yarn-api的具体实现

hadoop-yarn-server-application

hadoop-yarn-server-common:resource manager 和node manager 共享的API

hadoop-yarn-server-nodemanager：代替TaskTracker

hadoop-yarn-server-resourcemanager:代替JobTracker

hadoop-yarn-server-tests

hadoop-yarn-web-proxy

hadoop-yarn-site

图1 yarn工程中的README文件截图

底下有一句话十分重要，

Almost all of the yarn components as well as the mapreduce framework use

state-machines for all the data objects.

Yarn的大部分组件都是使用状态机来表述的，这个在看董西成老师的Hadoop技术内幕－Yarn的那本书的时候，他将各种状态机描述的都相当清楚，然而还是想对着源码去分析，因为虽然看完，我能看明白，但是真的记不住～囧

通过简单对yarn工程的组织架构分析，我们先来看hadoop-yarn-api部分的代码：

图2 hadoop-yarn-api的代码组织截图

hadoop-yarn-api下有api,conf,exceptions,factories,factory.providers,server.api,util这几个package组成，先看api这个package

它主要定义了以下四种协议(Protocal)：

ApplicationClientProtocol：主要用于client向RM提交新应用，查询应用信息，节点信息，预留资源，终止应用等
ApplicationHistoryProtocol：主要用于获取那些已经运行完的应用信息
ApplicationMasterProtocol：主要作用于健在的ApplicationMaster实例和ResourceManager之间，用于AM向RM注册或者取消注册，请求和占有资源
ContainerManagerProtocol: 主要作用于AM和NodeManager，用于启动和终止容器，获取运行中的容器状态

ApplicationClientProtocol ( client->RM ) 这个协议定义了以下的方法:

图3 ApplicationClientProtocol 里面定义的方法截图

getNewApplication: 客户端提交新应用需要获得一个ApplicationId，这个就是获取id的方法，ResourceManager返回一个新的，单调递增的ApplicationId和一些细节诸如：集群上的最大资源容量等。传入的参数是GetNewApplicationResponse，返回的参数类型是GetNewApplicationRequest这些可以在图3上看到，后面就不再赘述了

submitApplication:客户端提交一个新应用给ResourceManager。客户端通过SubmitApplicationRequest将一些细节的东西，比如：queue,需要在ApplicationMaster上运行的资源，发射ApplicationMaster的相关的ContainerLaunchContext等。ResourceManager在接到submission之后，如果它拒绝这个submission,它就抛出一个异常，否则立刻发送一个empty SubmitApplicationResponse。然而，需要注意的是调用该方法之前，需要调用getApplicationReport来保证应用已经得到了合适的提交。由于RM可能发生故障或者重启，从ResourceManager里获得一个SubmitApplicationResponse并不能保证RM记住了这个应用。如果RM发生了故障或者RM重启发生在RM成功保存应用状态之前，那么后续getApplicationReport将会抛出一个ApplicationNotFoundException.因此，当遇到这种情况时，客户端需要重新提交该应用with同样的ApplicationSubmissionContext。另外，在提交应用的过程中，它会检查应用是否已尽存在，如果应用已经存在，它会简单的返回SubmitApplicationResponse. 在安全模式下，RM会在接收application submission之前，验证用户是否在访问队列中

forceKillApplication:客户端用来请求RM终止这个已经提交的应用。客户端通过KillApplicationRequest提供特定的ApplicationId，告诉RM这个应用需要被终止，在安全模式下需要检查下用户权限。一般，RM拒绝这个请求，就会抛出一个异常，否则返回一个空的response.(安全模式下的情况就不再赘述了)

getApplicationReport:客户端从RM获得应用Report的接口，通过在GetApplicationReportRequest中提供ApplicationID,来告知是哪个应用

getClusterMetrics：客户端从RM获取集群的metrics(RM响应的GetClusterMetricsResponse中包含YarnClusterMetrics中比如集群中当前的节点数目)

getApplications: 用于客户端从RM中获取匹配的应用（通过过滤器得到对应的application）的report

getClusterNodes:客户端从集群中的所有节点的report

getQueueInfo:客户端从RM中获取队列信息的接口（包括：已经使用／总共资源大小，child queues，正在运行的应用）

getQueueUserAcls: 获取当前用户队列的ACL信息

getDelegationToken: 客户端获取授权token，使得containers 能够获取和要用到这些token的service交互

renewDelegationToken

cancelDelegationToken

moveApplicationAcrossQueues: 将应用移动到另一个队列中

getApplicationAttemptReport: 获取Application Attempt状态的report

getApplicationAttempts:获取所有Application Attempt状态的report

getContainerReport:获取指定containerId的report

getContainers:获取一个Application Attempt的Containers的report

submitReservation：客户端给RM预定资源，以备在特殊情况下能从集群中获取到资源运行程序

updateReservation:

deleteReservation:

getNodeToLabels:获取节点对应的Label集合

getClusterNodeLabels:获取集群中所有节点的Label

ApplicationHistoryProtocol （client -> ApplicationHistoryServer）定义了如下几种方法：

图4 ApplicationHistoryProtocol方法截图

东西和上面的差不多，只是ApplicationClientProtocol是和ResourceManager交互，该协议是和ApplicationHistoryServer，不再赘述了

ApplicationMasterProtocol(AM->RM) 定义了三种方法：

图5 ApplicationMasterProtocol 方法截图

allocate:AM传入ResourceRequest列表，返回分配给AllocateRequest未使用的容器。除此之外，还可以将它不想用的资源加入黑名单（ApplicationMaster can also blacklist resources which it does’t want to use）

它也发送心跳让ResourceManager知道ApplicationMaster健在。因此，应用需要周期性的调用改方法来证明健在。频率取决于YarnConfiguration的RM_AM_EXPIRY_INTERVAL_MS，这个值默认是DEFAULT_RM_AM_EXPIRY_INTERVAL_MS。

finishApplicationMaster:AM向RM通知它已经完成了（成功或失败）。AM需要提供它最后的状态以及失败情况下的诊断等

registerApplicationMaster:AM向RM注册，AM需要提供一些参数，诸如：RPC 调用的端口，HTTP tracking的url等等。RM返回一些关键的参数诸如集群中的最大资源容量

ContainerManagerProtocol协议（AM-> NM）

图6 ContainerManagerProtocol方法截图

getContainerStatuses:AM向NM请求当前运行的Container的状态，传入的参数是ContainerID的列表，返回的参数是查询成功的ContainerStatus列表和查询失败的ContainerID和异常的映射

startContainers:AM向NM请求启动Containers，传的是StartContainerRequest的列表。AM需要提供一些参数，比如：分配资源的容量,安全token(如果开启，需要提供)，启动容器的命令，处理环境，必要的二进制文件/jar/shared-objects(共享对象？共享内存？)。NodeManager发送一个响应StartContainerResponse包含成功启动的Container列表，一个containerId和异常映射表（对于每一个启动失败的容器，便于指明失败的原因），所有服务的元数据映射(allServicesMetaData map between the names of auxiliary service and their corresponding meta-data)。key是辅助服务的名称，Value是对应的元数据。

stopContainers:AM向NM请求关闭Containers,传的是ContainerId列表（封装在StopContainersRequest里面）。对应的NodeManager返回的是成功关闭的ContainerId列表和停止失败的ContainerID与异常的映射。

转载于:https://www.cnblogs.com/nashiyue/p/5866064.html

Hadoop Yarn源码 - day1相关推荐

linux eclipse 关联源码,获取Hadoop的源码和通过Eclipse关联Hadoop的源码
一.获取Hadoop的源码首先通过官网下载hadoop-2.5.2-src.tar.gz的软件包,下载好之后解压发现出现了一些错误,无法解压缩, 因此有部分源码我们无法解压 ,因此在这里我讲述一下如 ...
Yarn 源码 | 分布式资源调度引擎 Yarn 内核源码剖析
曾有人调侃:HBase 没有资源什么事情也做不了,Spark 占用了资源却没有事情可做? 那 YARN了解一下? 01 YARN! 伴随着Hadoop生态的发展,不断涌现了多种多样的技术组件 Hive ...
第二章：小朱笔记hadoop之源码分析-脚本分析
第二章:小朱笔记hadoop之源码分析-脚本分析第一节:start-all.sh 第二节:hadoop-config.sh 第三节:hadoop-env.sh 第四节:start-dfs.sh 第五 ...
第七章：小朱笔记hadoop之源码分析-hdfs分析第四节：namenode-LeaseManagerMonitor
第七章:小朱笔记hadoop之源码分析-hdfs分析第四节:namenode分析 4.4 namenode文件租约分析LeaseManagerMonitor 文件租约就是将操作的文件和操作它的客户端 ...
第七章：小朱笔记hadoop之源码分析-hdfs分析第三节：hdfs实现分析
第七章:小朱笔记hadoop之源码分析-hdfs分析第三节:hdfs实现分析 3.3 namenode (1)FSDirectory FSDirectory用来管理HDFS整个文件系统的namesp ...
第七章：小朱笔记hadoop之源码分析-hdfs分析第四节：namenode分析-namenode启动过程分析...
第七章:小朱笔记hadoop之源码分析-hdfs分析第四节:namenode分析 4.1 namenode启动过程分析 org.apache.hadoop.hdfs.server.namenode. ...
第七章：小朱笔记hadoop之源码分析-hdfs分析 Datanode 心跳分析
第七章:小朱笔记hadoop之源码分析-hdfs分析第五节:Datanode 分析 5.2 Datanode 心跳分析 (1)offerService分析写道 (a)检查心跳间隔是否超时,如是向n ...
第七章：小朱笔记hadoop之源码分析-hdfs分析第五节：Datanode 分析
第七章:小朱笔记hadoop之源码分析-hdfs分析第五节:Datanode 分析 5.1 Datanode 启动过程分析 5.2 Datanode 心跳分析 5.3 Datanode 注册分析 5 ...
YARN源码分析(一)-----ApplicationMaster
前言在之前两周主要学了HDFS中的一些模块知识,其中的许多都或多或少有我们借鉴学习的地方,现在将目光转向另外一个块,被誉为MRv2,就是yarn,在Yarn中,解决了MR中JobTracker单点的 ...

Hadoop Yarn源码 - day1

Hadoop Yarn源码 - day1相关推荐

最新文章

热门文章