YARN任務(wù)提交啟動的流程是什么

本篇內(nèi)容介紹了“YARN任務(wù)提交啟動的流程是什么”的有關(guān)知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細閱讀，能夠?qū)W有所成！

【名詞概念】

首先來說明下yarn中的一些概念，后續(xù)流程中都會涉及到。

• ResourceManager（RM）

  負責整個集群的資源管理和分配，處理客戶端和AM的請求，為containr分配資源（將任務(wù)調(diào)度到不同的NM上運行），同時通過NM的心跳獲取所有container的運行狀態(tài)，并進行必要的失敗重試。

  
  

• NodeManager（NM）

  集群資源（CPU和內(nèi)存，還包括GPU等）的實際擁有者，接收RM和AM的請求，啟動具體的container，并通過心跳向RM匯報container的運行情況。

  
  

• Application

  對應(yīng)1.X版本中的job，它可以是一個MapReduce應(yīng)用，也可以是一個spark應(yīng)用，或者flink應(yīng)用等。

  
  

• ApplicationMaster（AM）

  每個Application都有一個ApplicationMaster，負責管理具體的某個應(yīng)用，包括向RM申請具體任務(wù)所需的資源，向NM請求啟動具體的任務(wù)，同時監(jiān)控所有任務(wù)的運行狀況，并進行必要的容錯處理。spark的driver，flink的jobManager都屬于AM。

  
  

• Container

  Container是YARN中的一個抽象概念，它是任務(wù)運行所需資源，環(huán)境變量，啟動參數(shù)等的一個封裝和抽象。

  
  

  一個Application中可以分為兩類Container，一類是前面提到的AM，一類是具體任務(wù)的container，常見的任務(wù)container有MR中的map任務(wù)、reduce任務(wù)、spark中的executor、flink的taskManager。
  

【整體流程】

首先通過一張圖來看下客戶端提交任務(wù)到最終運行的整體流程。

1. 客戶端向RM提交應(yīng)用，本質(zhì)上是向RM請求啟動AM

2. RM選擇合適的NM，并向NM發(fā)送請求，要求啟動AM

3. NM收到啟動AM的請求后，根據(jù)所攜帶的參數(shù)，下載AM所依賴的資源到本地

4. 完成依賴資源的本地化后，NM啟動AM進程

5. AM啟動后向RM進行注冊，并向RM申請啟動任務(wù)containr所需的資源

6. RM根據(jù)NM的資源匯報情況，向AM回復(fù)資源（container）的分配情況，即給請求的任務(wù)container分配具體的NM。

7. AM根據(jù)任務(wù)container分配的NM，向?qū)?yīng)的NM發(fā)送請求，要求啟動任務(wù)container

8. NM收到啟動任務(wù)container的請求后，同樣根據(jù)請求參數(shù)，先完成依賴資源的本地化，然后啟動任務(wù)container進程。

   
   

整體流程中有幾點需要注意：

• RM中為container分配container，是等待NM進行心跳匯報后，被動觸發(fā)進行的。

• 任務(wù)container的運行狀態(tài)，是NM通過心跳向RM匯報，RM再通過AM的心跳響應(yīng)告知對應(yīng)的AM。

【RM中的流程】

前面概念中提到了application、container以及AM。在RM中，分別用Application，Container，AppAttempt類來對應(yīng)這三個概念。整個任務(wù)提交運行流程也就圍繞這三個類實例的創(chuàng)建，以及各自的狀態(tài)機變化完成。

當然，還有一塊內(nèi)容未涉及，那就是調(diào)度器模塊，這里暫不深入，后續(xù)再單獨整理說明。

來看看任務(wù)提交運行在RM中的流程：

1. 客戶端向RM申請Application的ID

2. RM內(nèi)部生成application的唯一ID

3. 通過rpc響應(yīng)將applicaiton ID告知客戶端

4. 客戶端攜帶ID，以及container上下文，通過RPC向RM提交任務(wù)。

5. RM的rpc服務(wù)將請求轉(zhuǎn)發(fā)給內(nèi)部的AppManager模塊。

6. AppManager創(chuàng)建一個App實例對象（RMAppImpl）。

7. 隨后向該實例對象發(fā)送start事件。

8. RMAppImpl收到事件后，向狀態(tài)存儲服務(wù)請求保存App狀態(tài)，狀態(tài)從NEW變?yōu)镹EW_SAVING。

9. 狀態(tài)存儲服務(wù)完成APP信息的存儲后，再以事件的形式告知RMAppImpl。

10. RMAppImpl向調(diào)度器發(fā)送添加APP的事件，狀態(tài)從NEW_SAVING變?yōu)镾UBMITTED。

11. 調(diào)度器收到消息后，進行相應(yīng)的處理動作，然后告知RMAppImpl應(yīng)用被接受。

12. RMAppImpl創(chuàng)建Attempt實例對象（RMAppAttemptImpl），

13. 然后，向其發(fā)送start事件，隨后狀態(tài)從SUBMITTED變?yōu)锳CCEPTED。

14. Attempt創(chuàng)建后，先向ApplicationMasterService進行注冊，使其在內(nèi)存中有對應(yīng)的記錄，方便后面真正的AM進程進行注冊。

15. 然后，向調(diào)度器發(fā)送添加Attempt事件。

16. 調(diào)度器同樣進行一系列的處理，包括權(quán)限判斷，隊列應(yīng)用計數(shù)等，在內(nèi)存中記錄相關(guān)信息，最后通知Attempt成功添加。

17. Attempt調(diào)用調(diào)度器的接口，申請啟動AM所需的資源，同時狀態(tài)從NEW變?yōu)镾UBMITTED。

18. 當有NM節(jié)點向RM發(fā)送心跳請求時，RM內(nèi)部最終會以事件的形式通知到調(diào)度器，調(diào)度器則選擇合適的應(yīng)用為其分配資源。

19. 資源分配過程中，會新建Container對象（RMContainerImpl）。

20. 然后向Container對象發(fā)送start事件。

21. container收到start事件后，告知attempt，資源已經(jīng)完成分配。自身狀態(tài)從NEW切換為ALLOCATED。

22. attempt收到事件后，通過接口向調(diào)度器獲取已分配的資源，然后狀態(tài)從SUBMITTED切換為SCHEDULED。

23. 調(diào)度器的接口處理過程中會向container發(fā)送acquire事件。Container的狀態(tài)從ALLOCATED切換為ACQUIRED。

24. 隨后，attempt向狀態(tài)存儲模塊發(fā)送請求，要求存儲attempt的信息。自身狀態(tài)從SCHEDULED切換為ALLOCATED_SAVING。

25. 狀態(tài)存儲完成后，以事件的形式告訴attempt。

26. attmpt向AMLaunch模塊發(fā)送啟動AM的請求。自身狀態(tài)從ALLOCATED_SAVING切換為ALLOCATED。

27. AMLaunch通過RPC協(xié)議向指定的NM發(fā)送startContainer的請求。

28. AMLaunch告知Attempt，container已啟動，Attempt的狀態(tài)從ALLOCATED切換為LAUNCHED。

29. NM收到請求后，啟動AM進程

30. AM進程啟動后向RM中的ApplicationMasterService進行注冊。

31. ApplicationMasterService收到注冊請求后，告知對應(yīng)的Attempt。Attempt的狀態(tài)從LAUNCHED切為RUNNING。

32. Attempt收到AM進程并成功注冊的消息后，進而告訴RMAppImpl。App的狀態(tài)從ACCEPTED轉(zhuǎn)換為RUNNING。

注：NM通過心跳告知RM節(jié)點上container的運行狀態(tài)，RM內(nèi)部處理該消息最終通知對應(yīng)container，container狀態(tài)從ACQUIRED轉(zhuǎn)為RUNNING。

【NM中的流程】

與RM不同，在NM中并不感知container是具體任務(wù)還是AM，因此內(nèi)部只有application和container，任務(wù)運行流程也就圍繞這兩個類實例的創(chuàng)建，狀態(tài)機的變化及周邊配套模塊完成。

在NM中，任務(wù)運行的流程如下圖所示：

1. NM內(nèi)部的containerManagerImpl處理啟動container的請求，先新建一個AppImpl（App的具體實現(xiàn)，后面簡稱為App）的實例對象，然后向該APP發(fā)送一個初始化事件，然后新建一個ContainerImpl（Container的具體實現(xiàn)，后面簡稱為Container）對象。

2. App向日志聚合模塊發(fā)送請求，告知App啟動，要求進行相應(yīng)的初始化動作，同時狀態(tài)從NEW變?yōu)镮NITING。

3. 日志聚合模塊完成app的初始化動作后，通過事件告知App。

4. APP收到事件后，接著向資源本地化服務(wù)模塊發(fā)送請求，要求完成App所依賴資源的下載。

5. 資源本地化服務(wù)模塊完成對應(yīng)的資源下載后，通過事件告知App。

6. App收到事件后，向Container發(fā)送初始化事件，同時狀態(tài)從INITING變?yōu)镽UNNING。

7. Container同樣向資源本地化服務(wù)模塊發(fā)送請求，要求完成Container所依賴資源的下載，此時狀態(tài)從NEW變?yōu)長OCALIZING。

8. 資源本地化服務(wù)模塊每成功完成一個資源的下載，都會以事件的形式通知Container。

9. 當Container感知所有依賴資源都完成本地化后，通過事件告知資源本地化服務(wù)模塊進行清理動作（這里的清理動作不是清理資源文件，而是結(jié)束相應(yīng)的資源下載進程）。

10. Container繼續(xù)向Container啟動服務(wù)模塊發(fā)送請求，要求啟動具體的Container進程，隨后狀態(tài)從LOCALIZING變?yōu)長OCALIZED。

11. Container啟動服務(wù)模塊根據(jù)Container上下文，設(shè)置環(huán)境變量、啟動參數(shù)生成啟動腳本，并創(chuàng)建Container的進程，然后通過事件告知Container。

    Container收到進程啟動的事件后，狀態(tài)從LOCALIZED變?yōu)镽UNNING。

12. 當Container的進程運行結(jié)束后，其對應(yīng)的創(chuàng)建線程獲取其結(jié)束碼，并通知Container。（假設(shè)這里為運行成功并正常結(jié)束）

13. Container收到事件后，向資源本地化服務(wù)模塊發(fā)送請求，要求清理資源文件，然后狀態(tài)從RUNNING切換為EXITED_WITH_SUCCESS。

14. 資源本地化服務(wù)模塊對Container的資源文件進行清理后，告知Container。

15. Container通知日志聚合模塊運行結(jié)束，讓其準備進行日志聚合。

16. 隨后也通知App，Container運行結(jié)束，最后狀態(tài)切換為DONE。

17. App感知Container運行結(jié)束后，只是在內(nèi)存中進行相關(guān)的記錄，NM通過心跳向RM上報所有container的運行狀況。RM會再通過心跳告知AM，當AM得知所有任務(wù)均結(jié)束時，向RM進行注銷，并自身退出。RM得知AM結(jié)束后，進行相應(yīng)的處理動作，最終告知該應(yīng)用對應(yīng)任務(wù)containerd的NM，應(yīng)用結(jié)束。NM內(nèi)部最終告知App。

18. App收到消息后，通知資源本地化服務(wù)模塊進行資源的清理。然后自身狀態(tài)從RUNNING切換為APPLICATION_RESOURCE_CLEANUP。

19. 資源化本地服務(wù)模塊完成資源清理后事件通知App。

20. App通知日志聚合模塊進行日志聚合，最后狀態(tài)變?yōu)镕INISHED。

“YARN任務(wù)提交啟動的流程是什么”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識可以關(guān)注億速云網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實用文章！