Hadoop YARN介紹

YARN產生背景

MRv1的侷限

YARN是在MRv1基礎上演化而來的，它克服了MRv1中的各類侷限性。在正式介紹YARN以前，先了解下MRv1的一些侷限性，主要有如下幾個方面：

• 擴展性差。在MRv1中，JobTracker同時兼備了資源管理和做業控制兩個功能，這成爲系統的一個最大瓶頸，嚴重製約了Hadoop集羣擴展性。
• 可靠性差。MRv1採用了master/slave結構，其中，master存在單點故障問題，一旦它出現故障將致使整個集羣不可用。
• 資源利用率低。MRv1採用了基於槽位的資源分配模型，槽位是一種粗粒度的資源劃分單位，一般一個任務不會用完槽位對應的資源，且其餘任務也沒法使用這些空閒資源。此外，Hadoop將槽位分爲Map Slot和Reduce Slot兩種，且不容許它們之間共享，經常會致使一種槽位資源緊張而另一種閒置（好比一個做業剛剛提交時，只會運行Map Task，此時Reduce Slot閒置）。
• 沒法支持多種計算框架。隨着互聯網高速發展，MapReduce這種基於磁盤的離線計算框架已經不能知足應用要求，從而出現了一些新的計算框架，包括內存計算框架、流式計算框架和迭代式計算框架等，而MRv1不能支持多種計算框架並存。

爲了克服以上幾個缺點，Apache開始嘗試對Hadoop進行升級改造，進而誕生了更加先進的下一代MapReduce計算框架MRv2。正是因爲MRv2將資源管理功能抽象成了一個獨立的通用系統YARN，直接致使下一代MapReduce的核心從單一的計算框架MapReduce轉移爲通用的資源管理系統YARN。

集羣資源統一管理

隨着互聯網的高速發展，新的計算框架不斷出現，從支持離線處理的MapReduce，到支持在線處理的Storm，從迭代式計算框架Spark到流式處理框架S4，各類框架各有所長，各自解決了某一類應用問題。這時候就須要一個組件對同一個集羣上的不一樣計算框架進行資源的統一管理。

相比於「一種計算框架一個集羣」的模式，共享集羣的模式存在多種好處：

• 資源利用率高。若是每一個框架一個集羣，可能在某段時間內，有些計算框架的集羣資源緊張，而另一些集羣資源空閒。共享集羣模式則經過多種框架共享資源，使得集羣中的資源獲得更加充分的利用。
• 運維成本低。若是採用「一個框架一個集羣」的模式，則可能須要多個管理員管理這些集羣，進而增長運維成本，而共享模式一般須要少數管理員便可完成多個框架的統一管理。
• 數據共享。隨着數據量的暴增，跨集羣間的數據移動不只需花費更長的時間，且硬件成本也會大大增長，而共享集羣模式可以讓多種框架共享數據和硬件資源，將大大減少數據移動帶來的成本。

YARN基本設計思想

MRv1主要由編程模型、數據處理引擎（由Map Task和Reduce Task組成）和運行時環境三部分組成。爲了保證編程模型的向後兼容性，MRv2重用了MRv1中的編程模型和數據處理引擎，但運行時環境被徹底重寫。

MRv1的運行時環境主要由兩類服務組成，分別是JobTracker和TaskTracker。其中，JobTracker負責資源管理和做業控制。TaskTracker負責單個節點的資源管理和任務執行。

MRv1將資源管理和應用程序管理兩部分混雜在一塊兒，使得它在擴展性、容錯性和多框架支持等方面存在明顯缺陷。

而MRv2則經過將資源管理和應用程序管理兩部分剝離開，分別由ResourceManager和ApplicationMaster負責，其中ResourceManager專管資源管理和調度，而ApplicationMaster則負責與具體應用程序相關的任務切分、任務調度和容錯等，具體以下圖所示。

YARN基本架構

YARN是Hadoop 2.0中的資源管理系統，它的基本設計思想是將MRv1中的JobTracker拆分紅了兩個獨立的服務：一個全局的資源管理器ResourceManager和每一個應用程序特有的ApplicationMaster。其中ResourceManager負責整個系統的資源管理和分配，而ApplicationMaster負責單個應用程序的管理。

YARN整體上仍然是Master/Slave結構，在整個資源管理框架中，ResourceManager爲Master，NodeManager爲Slave，ResourceManager負責對各個NodeManager上的資源進行統一管理和調度。當用戶提交一個應用程序時，須要提供一個用以跟蹤和管理這個程序的ApplicationMaster，它負責向ResourceManager申請資源，並要求NodeManger啓動能夠佔用必定資源的任務。因爲不一樣的ApplicationMaster被分佈到不一樣的節點上，所以它們之間不會相互影響。

下圖描述了YARN的基本組成結構，YARN主要由ResourceManager、NodeManager、ApplicationMaster（圖中給出了MapReduce和MPI兩種計算框架的ApplicationMaster，分別爲MR AppMstr和MPI AppMstr）和Container等幾個組件構成。

接下來對YARN裏幾個重要的組件一一介紹。

1. ResourceManager(RM)

RM是一個全局的資源管理器,負責整個系統的資源管理和分配。它主要由兩個組件構成：調度器（Scheduler）和應用程序管理器（Applications Manager，ASM）。

（1）調度器（分配Container）

調度器根據容量、隊列等限制條件（如每一個隊列分配必定的資源，最多執行必定數量的做業等），將系統中的資源分配給各個正在運行的應用程序。須要注意的是，該調度器是一個「純調度器」，它再也不從事任何與具體應用程序相關的工做，好比不負責監控或者跟蹤應用的執行狀態等，也不負責從新啓動因應用執行失敗或者硬件故障而產生的失敗任務，這些均交由應用程序相關的ApplicationMaster完成。調度器僅根據各個應用程序的資源需求進行資源分配，而資源分配單位用一個抽象概念「資源容器」（Resource Container，簡稱Container）表示，Container是一個動態資源分配單位，它將內存、CPU、磁盤、網絡等資源封裝在一塊兒，從而限定每一個任務使用的資源量。此外，該調度器是一個可插拔的組件，用戶可根據本身的須要設計新的調度器，YARN提供了多種直接可用的調度器，好比Fair Scheduler和Capacity Scheduler等。

（2）應用程序管理器

應用程序管理器負責管理整個系統中全部應用程序，包括應用程序提交、與調度器協商資源以啓動ApplicationMaster、監控ApplicationMaster運行狀態並在失敗時從新啓動它等。

2. ApplicationMaster（AM）

用戶提交的每一個應用程序均包含一個AM，主要功能包括：

• 與RM調度器協商以獲取資源（以Container表示）
• 將獲得的任務進一步分配給內部的任務
• 與NM通訊以啓動/中止任務
• 監控全部任務運行狀態，並在任務失敗時從新爲任務申請資源以重啓任務

3. NodeManager（NM）

NM是每一個節點上的資源和任務管理器。一方面，它定時地向RM彙報本節點的資源使用狀況和Container運行狀態；另外一方面，它接受並處理來自AM的Container啓動/中止等各類請求。

4. Container

Container是YARN中的資源抽象，它封裝了某個節點上的多維資源，如CPU、內存、磁盤、網絡等。當AM向RM申請資源時，RM向AM返回的資源即是用Container表示的。YARN會爲每一個任務分配一個Container，且該任務只能使用該Container中描述的資源。Container是一個動態資源劃分單位，是根據應用程序的需求自動生成的。目前，YARN僅支持CPU和內存兩種資源。

YARN工做流程

運行在YARN上的應用程序主要分爲兩類：短應用程序和長應用程序。其中，短應用程序是指必定時間內可運行完成並正常退出的應用程序，如MapReduce做業、Spark DAG做業等。長應用程序是指不出意外，永不終止運行的應用程序，一般是一些服務，好比Storm Service（包括Nimbus和Supervisor兩類服務），HBase Service（包括HMaster和RegionServer兩類服務）等，而它們自己做爲一種框架提供編程接口供用戶使用。儘管這兩類應用程序做業不一樣，一類直接運行數據處理程序，一類用於部署服務（服務之上再運行數據處理程序），但運行在YARN上的流程是相同的。

當用戶向YARN中提交一個應用程序後，YARN將分兩個階段運行該應用程序：第一階段是啓動ApplicationMaster。第二階段是由ApplicationMaster建立應用程序，爲它申請資源，並監控它的整個運行過程，直到運行完成。具體以下：

1. 用戶向YARN中提交應用程序，其中包括ApplicationMaster程序、啓動ApplicationMaster的命令、用戶程序等。
2. ResourceManager爲該應用程序分配第一個Container，並與對應的NodeManager通訊，要求它在這個Container中啓動應用程序的ApplicationMaster。
3. ApplicationMaster首先向ResourceManager註冊，這樣用戶就能夠直接經過ResourceManager查看應用程序的運行狀態，而後它將爲各個任務申請資源，並監控它的運行狀態，直到運行結束，即重複步驟4~7。
4. ApplicationMaster採用輪詢的方式經過RPC協議向ResourceManager申請和領取資源。
5. 一旦ApplicationMaster申請到資源後，便與對應的NodeManager通訊，要求它啓動任務。
6. NodeManager爲任務設置好運行環境（包括環境變量、JAR包、二進制程序等）後，將任務啓動命令寫到一個腳本中，並經過運行該腳本啓動任務。
7. 各個任務經過某個RPC協議向ApplicationMaster彙報本身的狀態和進度，以讓ApplicationMaster隨時掌握各個任務的運行狀態，從而能夠在任務失敗時從新啓動任務。
8. 應用程序運行完成後，ApplicationMaster向ResourceManager註銷並關閉本身。

歡迎進入博客 ：linbingdong.com 獲取最新文章哦~

歡迎關注公衆號: FullStackPlan 獲取更多幹貨哦~