Hadoop Yarn源码 - day1

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

1. hadoop-yarn-api：和外部平台交互的接口
2. hadoop-yarn-applications
3. hadoop-yarn-client
4. hadoop-yarn-common：yarn client和server能够用到的一些实用工具
5. hadoop-yarn-registry
6. 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

7. 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与异常的映射。