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與異常的映射。