文章目錄
hadoop 2.0引入了數據操作系統YARN，YARN能夠將資源按需分配給各個應用程序，大大提高了資源利用率，其次，YARN將短作業和長作業混合部署到一個集羣中，並提供了容錯、自願隔離及負載均衡等方面的支持，大大簡化了作業和服務的部署和管理成本。
why YARN
MRv1 侷限性
- 可靠性差：MRv1採用了master/slave結構，master存在單點故障問題，一旦出現問題可能導致整個集羣不可用。
- 擴展性差：MRv1中JobTracker(master)同時兼備了資源管理和作業控制兩個功能，嚴重製約了Hadoop集羣的擴展性。
- 資源利用率低：MRv1採用了基於槽位的資源分配模型，通常一個任務不用全部用完槽位對應的所有的資源，其他任務也無法使用這些沒有使用的資源。另外，Hadoop將槽位劃分爲Map Slot和Reduce Slot兩種，且不允許它們之間共享，常常會導致一種槽位資源緊張而另一種槽位閒置的狀態(例如一個作業剛剛提交時，只會運行Map Task，此時Reduce Slot閒置)。
- 無法支持多種計算框架：MRv1不能支持多種計算框架並存(例如內存計算框架、流式計算框架和迭代計算框架)。
MRv2將資源管理功能抽象成了一個獨立的通用系統YARN，使得下一代MapReduce的核心從單一的計算框架MapReduce轉移爲通用的資源管理系統YARN。下圖展示了MRv1和MRv2的對比：
![在這裏插入圖片描述]()
以MapReduce爲核心的協議棧中，資源管理系統是可以替換的，但一旦MapReduce接口發生改變，所有的資源管理系統的實現都需要改變；以YARN爲核心的協議棧中，所有框架都需要實現YARN定義的對外接口以運行在YARN之上。
YARN設計動機
YARN作爲一個通用的資源管理系統，其目標是將短作業和長任務混合部署到一個集羣中，併爲他們提供統一的資源管理和調度功能。YARN的設計需要解決以下兩類問題。
- 提高集羣資源利用率
爲了存儲和處理海量數據，需要規模較大的服務器集羣或者數據中心，一般這些集羣上運行着數量衆多的應用程序和服務，傳統的做法是讓這些不同類型的作業或任務對應一個單獨的集羣以避免互相干擾。這樣集羣被分成若干個小集羣，由於不同類型的任務需要的資源不同，所以這些小集羣的利用率通常很不均衡，並且集羣間的資源無法共享，有些集羣資源緊張而有些集羣處於閒置狀態。爲了提高資源整體的利用率，一種解決方式是讓這些小集羣合併成一個大的集羣，讓任務可以共享大集羣的資源，並由一個資源管理系統統一進行資源管理和分配。 - 服務自動化部署
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。
- 調度器(Scheduler)
調度器主要功能是根據資源容量和隊列等方面的限制，將系統中的資源分配給各個應用程序。YARN中的調度器是一個純調度器，不再從事任何與具體應用程序相關的工作，比如不負責監控或者跟蹤應用程序的執行狀態等，也不負責重新啓動因應用執行失敗或者硬件故障而產生的失敗任務，這些都交給ApplicationMaster來完成。 - 應用程序管理器(Application Manager, ASM)
負責管理整個系統的所有的應用程序，包括應用程序提交，與調度器協調資源以啓動ApplcationMaster，監控ApplcationMaster運行狀態並在失敗時重新啓動它。
ApplicationMaster(AM)
用戶提交的每個應用程序均包含一個獨立的AM，其主要功能包括：
- 與RM調度器協商以獲取資源(用Container表示)
- 得到的資源進一步分配給內部的任務
- 與NM通信以啓動、停止服務
- 監控所有任務的運行狀態，並在任務運行失敗時重新爲任務申請資源以重啓任務。
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的工作流程如下：
- 保存元信息：Active ResourceManager運行過程中會將應用程序的元信息、狀態信息以及安全憑證等數據持久化到狀態存儲系統(state-store)中，YARN支持三種可選的state-store, 分別是：
(1) 基於ZooKeeper的state-store，只有這種形式能防止腦裂基於ZooKeeper的state-store，只有這種形式能防止腦裂
(2) 基於FileSystem的state-store
(3) 基於LevelDB的state-store, 比起前兩種方案更加輕量級，LevelDB能更好的支持原子操作，每次更新佔用更少的IO資源，生成的文件數目更少。 - 加載元信息：一旦Active ResourceManager重啓或出現故障，新啓動的ResourceManager將從存儲系統中重新加載應用程序的相關數據，在此過程中，所有運行在各個NodeManager的Container仍正常運行。
- 重構狀態信息：新的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註銷，並退出執行。