文章目錄

• why YARN
• MRv1 侷限性
• YARN設計動機
• YARN 設計思想
• YARN 基本架構
• ResourceManager(RM)
• ApplicationMaster(AM)
• NodeManager(NM)
• Container
• YARN高可用
• ResourceManager HA
• ResourceManager Recovery
• NodeManager Recovery
• YARN 工作流程
• 提交應用程式
• 啟動ApplicationMaster
• ApplicationMaster 註冊
• 資源獲取
• 請求啟動Container
• 啟動Container
• Container監控
• 登出ApplicationMaster

why YARN

MRv1 侷限性

1. 可靠性差：MRv1採用了master/slave結構，master存在單點故障問題，一旦出現問題可能導致整個叢集不可用。
2. 擴充套件性差：MRv1中JobTracker(master)同時兼備了資源管理和作業控制兩個功能，嚴重製約了Hadoop叢集的擴充套件性。
3. 資源利用率低：MRv1採用了基於槽位的資源分配模型，通常一個任務不用全部用完槽位對應的所有的資源，其他任務也無法使用這些沒有使用的資源。另外，Hadoop將槽位劃分為Map Slot和Reduce Slot兩種，且不允許它們之間共享，常常會導致一種槽位資源緊張而另一種槽位閒置的狀態(例如一個作業剛剛提交時，只會執行Map Task，此時Reduce Slot閒置)。
4. 無法支援多種計算框架：MRv1不能支援多種計算框架並存(例如記憶體計算框架、流式計算框架和迭代計算框架)。
   MRv2將資源管理功能抽象成了一個獨立的通用系統YARN，使得下一代MapReduce的核心從單一的計算框架MapReduce轉移為通用的資源管理系統YARN。下圖展示了MRv1和MRv2的對比：
   
   以MapReduce為核心的協議棧中，資源管理系統是可以替換的，但一旦MapReduce介面發生改變，所有的資源管理系統的實現都需要改變；以YARN為核心的協議棧中，所有框架都需要實現YARN定義的對外介面以執行在YARN之上。

YARN設計動機

YARN作為一個通用的資源管理系統，其目標是將短作業和長任務混合部署到一個叢集中，併為他們提供統一的資源管理和排程功能。YARN的設計需要解決以下兩類問題。

1. 提高叢集資源利用率
   為了儲存和處理海量資料，需要規模較大的伺服器叢集或者資料中心，一般這些叢集上執行著數量眾多的應用程式和服務，傳統的做法是讓這些不同型別的作業或任務對應一個單獨的叢集以避免互相干擾。這樣叢集被分成若干個小叢集，由於不同型別的任務需要的資源不同，所以這些小叢集的利用率通常很不均衡，並且叢集間的資源無法共享，有些叢集資源緊張而有些叢集處於閒置狀態。為了提高資源整體的利用率，一種解決方式是讓這些小叢集合併成一個大的叢集，讓任務可以共享大叢集的資源，並由一個資源管理系統統一進行資源管理和分配。
2. 服務自動化部署
   YARN需要提供服務統一管理系統，包括服務資源申請、服務自動化部署、服務容錯等功能。

YARN 設計思想

Hadoop1.0中，JobTracker同時負責資源管理和作業控制兩部分，如下圖所示。這種設計使得JobTracker的功能過多負載過重，未能將資源管理與程式相關的功能分開，造成第一代Hadoop難以支援多種計算框架

Hadoop2.0的基本設計思想是將資源管理和作業控制(包括作業監控、容錯等)拆分成兩個獨立的程序，從而衍生出了一個資源管理統一平臺，使得Hadoop不再侷限於僅支援MapReduce一種計算模型，而是可以無限融入多種計算框架，並且對這些框架進行統一管理和排程。如下圖所示：

資源管理系統與具體的應用程式無關，負責整個叢集的資源(記憶體，CPU，磁碟等)管理，而作業控制程序則是直接與應用程式相關的模組，每個作業控制程序只負責管理一個作業。這樣就將原來的JobTracker中的資源管理與作業排程模組分開了，不僅減輕了JobTracker的負載，也使得Hadoop支援更多的計算框架。

YARN 基本架構

YARN採用master/slave架構，其中ResourceManager為master，NodeManager為slave，ResourceManager負責對各個NodeManager上的資源進行統一管理和排程。當用戶提交一個應用程式時，需要提供一個ApplicationMaster用來向ResourceManager申請資源和啟動任務。由於不同的ApplicationMaster被分佈到不同的節點上，他們之間不會相互影響。下面是YARN的基本組成結構：

ResourceManager(RM)

RM是一個全域性的資源管理器，負責整個系統的資源管理和分配。主要有兩個元件構成：排程器(Scheduler)和應用管理器(Application Manager, ASM). 為了避免ResourceManager出現單點故障導致整個叢集不可用，YARN引入了兩個ResourceManager，當Active ResourceManager出現故障時，Standby ResourceManager會通過ZooKeeper選舉，自動提升為Active ResourceManager。

1. 排程器(Scheduler)
   排程器主要功能是根據資源容量和佇列等方面的限制，將系統中的資源分配給各個應用程式。YARN中的排程器是一個純排程器，不再從事任何與具體應用程式相關的工作，比如不負責監控或者跟蹤應用程式的執行狀態等，也不負責重新啟動因應用執行失敗或者硬體故障而產生的失敗任務，這些都交給ApplicationMaster來完成。
2. 應用程式管理器(Application Manager, ASM)
   負責管理整個系統的所有的應用程式，包括應用程式提交，與排程器協調資源以啟動ApplcationMaster，監控ApplcationMaster執行狀態並在失敗時重新啟動它。

ApplicationMaster(AM)

使用者提交的每個應用程式均包含一個獨立的AM，其主要功能包括：

1. 與RM排程器協商以獲取資源(用Container表示)
2. 得到的資源進一步分配給內部的任務
3. 與NM通訊以啟動、停止服務
4. 監控所有任務的執行狀態，並在任務執行失敗時重新為任務申請資源以重啟任務。

NodeManager(NM)

NM是每個節點上的資源管理器，它會定時的向RM彙報本節點上的資源使用情況和各個Container的執行狀態，另一方面它接收並處理來自AM的任務啟動、停止等各種請求。在一個叢集中，NodeManager通常存在多個，由於YARN內建了容錯機制，單個NodeManager的故障不會對叢集中的應用程式的執行產生嚴重的影響。

Container

Container是YARN中的資源分配單位，是對應用程式執行環境的抽象，併為應用程式提供資源隔離環境。它封裝了多維度的資源，如記憶體、CPU、磁碟、網路等。當AM向RM申請資源時，RM為AM返回的資源便是用Container表示的。YARN提供了三種可選的ContainerExecutor：DefaultContainerExecutor，LinuxContainerExecutor，DockerContainerExecutor。

YARN高可用

YARN提供了恢復機制，使得YARN在服務出現故障或人工重啟時，不會對正在執行的應用程式產生任何影響。

ResourceManager HA

ResourceManager負責整個叢集中資源的排程和應用程式管理，是YARN最核心的元件。由於YARN採用了master/slave架構，為了避免ResourceManager故障導致整個叢集不可用，YARN引入了Active/Standby ResourceManager，當Active ResourceManager出現故障時，Standby ResourceManager可通過ZooKeeper選舉成為Active ResourceManager，並通過ResourceManager Recovery機制恢復狀態。

ResourceManager Recovery

ResourceManager 內建了重啟恢復功能，當ResourceManager重啟或者出現Acitve，Standby切換時，不會影響正在執行的應用程式。ResourceManager Recovery的工作流程如下：

1. 儲存元資訊：Active ResourceManager執行過程中會將應用程式的元資訊、狀態資訊以及安全憑證等資料持久化到狀態儲存系統(state-store)中，YARN支援三種可選的state-store, 分別是：
   (1) 基於ZooKeeper的state-store，只有這種形式能防止腦裂基於ZooKeeper的state-store，只有這種形式能防止腦裂
   (2) 基於FileSystem的state-store
   (3) 基於LevelDB的state-store, 比起前兩種方案更加輕量級，LevelDB能更好的支援原子操作，每次更新佔用更少的IO資源，生成的檔案數目更少。
2. 載入元資訊：一旦Active ResourceManager重啟或出現故障，新啟動的ResourceManager將從儲存系統中重新載入應用程式的相關資料，在此過程中，所有執行在各個NodeManager的Container仍正常執行。
3. 重構狀態資訊：新的ResourceManager重新啟動後，各個NodeManager會向它重新註冊， 並將所管理的Container彙報給ResourceManager，ResourceManager可動態重構資源分配資訊、各個應用程式以及其對應Container等關鍵資料；同時ApplicationMaster會向ResourceManager重新發送資源請求，以便ResourceManager重新為其分配資源。

NodeManager Recovery

NodeManager 內建了重啟恢復功能，當NodeManager就地重啟時，之前執行的Container不會被殺掉，而是由新的NodeManager接管並繼續正常執行。

YARN 工作流程

執行在YARN上的應用程式主要分為兩類：短作業和長服務，短作業是指一定時間內可完成並退出的應用程式：如MapReduce作業、Spark作業；長服務是指不出意外永不終止執行的應用程式，如Storm Service、Hbase Service等。兩類應用程式儘管作用不同，但執行在YARN上的流程是相同的。YARN工作流程圖如下：

YARN的工作流程分為以下幾個步驟：

提交應用程式

使用者通過客戶端與YARN ResourceManager通訊，提交應用程式，應用程式中需包含ApplicationMaster可執行程式碼、啟動命令和資源需求、應用程式可執行程式碼和資源需求、優先順序、提交到的佇列等資訊。

啟動ApplicationMaster

ResourceManager為該應用程式分配第一個Container，並與對應的NodeManager通訊，要求它在這個Container中啟動應用程式的ApplicationMaster，之後ApplicationMaster的生命週期直接被ResourceManager管理。

ApplicationMaster 註冊

ApplicationMaster啟動後，會向ResourceManager註冊，這樣使用者可以直接通過ResourceManager檢視應用程式的執行狀態，然後初始化應用程式，並按照一定的策略為內部任務申請資源，監控它們的執行狀態，直到執行結束。

資源獲取

ApplicationMaster採用輪詢的方式通過RPC協議向ResourceManager申請和領取資源。

請求啟動Container

一旦ApplicationMaster申請到資源後，則與對應的NodeManager通訊，請求為其啟動任務。

啟動Container

NodeManager為任務設定好執行環境(包括環境變數、jar包、二進位制程式等)後，將任務啟動命令寫到一個指令碼中，並通過ContainerExecutor執行該指令碼啟動任務。

Container監控

ApplicationMaster可通過兩種方式獲取各個Container的執行狀態，以便在任務失敗時重新啟動任務：
(1) ApplicationMaster與ResourceManager間維護了週期性心跳資訊，每次通訊可獲取分管的Container的執行狀態
(2) 各個Container可通過某個RPC協議向ApplicationMaster彙報自己的狀態和進度

登出ApplicationMaster

應用程式執行完成後，ApplicationMaster向ResourceManager登出，並退出執行。