@
詳解Yarn基礎架構及其設計思想
1.Hadoop Yarn 目錄組織結構
- YARN API（hadoop-yarn-api 目錄）：給出了 YARN 內部涉及的 4 個主要 RPC 協議的 Java 聲明和 Protocol Buffers 定義，這 4 個 RPC 協議分別是 ApplicationClientProtocol、 ApplicationMasterProtocol、ContainerManagementProtocol 和 ResourceManagerAdmi nistrationProtocol。
- YARN Common（hadoop-yarn-common 目錄）：該部分包含了 YARN 底層庫實現， 包括事件庫、服務庫、狀態機庫、Web 界面庫等；
- YARN Applications（hadoop-yarn-applications 目錄）：該部分包含了兩個 Application 編程實例，分別是 distributedshell 和 Unmanaged AM；
- YARN Client（hadoop-yarn-client 目錄）：該部分封裝了幾個與 YARN RPC 協議交互 相關的庫，方便用戶開發應用程序；
- YARN Server（hadoop-yarn-server 目錄）：該部分給出了 YARN 的核心實現，包括 ResourceManager、NodeManager、資源管理器等核心組件的實現。
2.Yarn 產生背景
2.1 MRv1局限性
我們都知道Yarn是MRV2中才有的Hadoop組成部分，是MRv1存在各種局限性導致，其局限性大致概括為以下方面：
- 拓展性差：在MRv1中，JobTracker同時兼備了資源管理和作業控制兩個功能，這 成為系統的一個最大瓶頸，嚴重制約了 Hadoop 集群擴展性。
- 可靠性差。MRv1 采用了 master/slave 結構，其中，master 存在單點故障問題，一旦 它出現故障將導致整個集群不可用。
- 資源利用率低。MRv1 采用了基於槽位的資源分配模型，槽位是一種粗粒度的資源 划分單位，通常一個任務不會用完槽位對應的資源，且其他任務也無法使用這些空 閑資源。此外，Hadoop 將槽位分為 Map Slot 和 Reduce Slot 兩種，且不允許它們之 間共享，常常會導致一種槽位資源緊張而另外一種閑置（比如一個作業剛剛提交時， 只會運行 Map Task，此時 Reduce Slot 閑置）。
- 無法支持多種計算框架。隨着互聯網高速發展，MapReduce 這種基於磁盤的離線計 算框架已經不能滿足應用要求，從而出現了一些新的計算框架，包括內存計算框架、 流式計算框架和迭代式計算框架等，而 MRv1 不能支持多種計算框架並存。
正是由於 MRv2 將資源管理功能抽象成了一個 獨立的通用系統 YARN，直接導致下一代 MapReduce 的核心從單一的計算框架 MapReduce轉移為通用的資源管理系統 YARN。
2.2 輕量級彈性計算平台
隨着互聯網的高速發展，基於數據密集型應用的計算框架不斷出現，從支持離線處理 的 MapReduce，到支持在線處理的 Storm，從迭代式計算框架 Spark 到流式處理框架 S4，等等。各種框架有其應用的場景。而在實際互聯網公司中，這幾種框架不是選其一，而是根據場景有不同的選擇共同構建整個計算框架。考慮成本、運維、數據共享等等因素，實際更希望的是將這些框架都部署到一個公共的集群中，共享集群資源，並對資源進行統一管理，同時采用某種資源隔離方案(如輕量級 cgroups)對各個任務進行隔離，這樣便誕生了輕量級彈性計算平台。YARN 便是彈性計算平台的典型代表。
YARN 實際上是一個彈性計算平台，它的目標已經不再局限於支持 MapReduce 一種計算框架，而是朝着對多種框架進行統一管理的方向發展。
相比於“一種計算框架一個集群”的模式，共享集群的模式存在多種好處：
- 資源利用率高。如果每個框架一個集群，見下圖，則往往由於應用程序數量 和資源需求的不均衡性，使得在某段時間內，有些計算框架的集群資源緊張，而另 外一些集群資源空閑。共享集群模式則通過多種框架共享資源，使得集群中的資源 得到更加充分的利用；
- 運維成本低。如果采用“一個框架一個集群”的模式，則可能需要多個管理員管理 這些集群，進而增加運維成本，而共享模式通常需要少數管理員即可完成多個框架 的統一管理。
- 數據共享。隨着數據量的暴增，跨集群間的數據移動不僅需花費更長的時間，且硬 件成本也會大大增加，而共享集群模式可讓多種框架共享數據和硬件資源，將大大 減小數據移動帶來的成本。
3YARN基本設計思想
3.1 基本框架對比
在 Hadoop 1.0 中，JobTracker 由資源管理（由 TaskScheduler 模塊實現）和作業控制（由 JobTracker 中多個模塊共同實現）兩部分組成。當前 Hadoop MapReduce 之所以在可擴展性、資源利用率和多框架支持等方面存在不足，正是由於 Hadoop 對 JobTracker 賦予的功能過多而造成負載過重(正如一些公司既想要打工人能夠做開發還要能做產品最好還能寫前端並做UI的話，美名曰，“全棧”)。此外，從設計角度上看，Hadoop 未能夠將資 源管理相關的功能與應用程序相關的功能分開，造成 Hadoop 難以支持多種計算框架。
而Hadoop2.x框架的基本設計思想是將 JobTracker 的兩個主要功能，即資源管理和作業控制（包括作業監控、容錯等），分拆成兩獨立的進程。資源管理進 程與具體應用程序無關，它負責整個集群的資源（內存、CPU、磁盤等）管理，而作業控 制進程則是直接與應用程序相關的模塊，且每個作業控制進程只負責管理一個作業。這樣， 通過將原有 JobTracker 中與應用程序相關和無關的模塊分開，不僅減輕了 JobTracker 負載， 也使得 Hadoop 支持更多的計算框架。
從資源管理角度看，MRv2 框架實際上衍生出了一個資源統一管理平台 YARN，它使得 Hadoop 不再局限於僅支持 MapReduce 一種計算模型，而是可無限融入多 種計算框架，且對這些框架進行統一管理和調度。
4 YARN基本架構
4.1 YARN基本組成結構
YARN 總體上仍然是 Master/Slave 結構，在整個資源管理框架中，ResourceManager 為 Master，NodeManager 為 Slave，ResourceManager 負責對各個 NodeManager 上的資源進行 統一管理和調度。當用戶提交一個應用程序時，需要提供一個用以跟蹤和管理這個程序的 ApplicationMaster，它負責向 ResourceManager 申請資源，並要求 NodeManger 啟動可以占 用一定資源的任務。由於不同的 ApplicationMaster 被分布到不同的節點上，因此它們之間 不會相互影響。
YARN 主要由 ResourceManager、NodeManager、 ApplicationMaster（圖中給出了 MapReduce 和 MPI 兩種計算框架的 ApplicationMaster，分 別為 MR AppMstr 和 MPI AppMstr）和 Container 等幾個組件構成。
-
1. ResourceManager（RM）
-
RM 是一個全局的資源管理器，負責整個系統的資源管理和分配。它主要由兩個組件 構成：調度器（Scheduler）和應用程序管理器（Applications Manager，AM）。
- （1）調度器：調度器根據容量、隊列等限制條件（如每個隊列分配一定的資源，最多執行一定數量的作業等），將系統中的資源分配給各個正在運行的應用程序。
該調度器是 一個“純調度器”，它不再從事任何與具體應用程序相關的工作，比如不負責監控或者跟蹤 應用的執行狀態等，也不負責重新啟動因應用執行失敗或者硬件故障而產生的失敗任務， 這些均交由應用程序相關的 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 和內存兩種資源， 且使用了輕量級資源隔離機制 Cgroups 進行資源隔離。
5 YARN的通信機制
RPC 協議是連接各個組件的“大動脈”，了解不同組件之間的 RPC 協議有助於我們更深入地學習 YARN 框架。在 YARN 中，任何兩個需相互通信的組件之間僅有一個 RPC 協 議，而對於任何一個 RPC 協議，通信雙方有一端是 Client，另一端為 Server，且 Client 總 是主動連接 Server 的，因此，YARN 實際上采用的是拉式（pull-based）通信模型。YARN 主要由以 下幾個 RPC 協議組成：
- JobClient（作業提交客戶端）與 RM 之間的協議 —ApplicationClientProtocol ： JobClient 通過該 RPC 協議提交應用程序、查詢應用程序狀態等。
- Admin（管理員）與 RM 之間的通信協議—ResourceManagerAdministrationProtocol： Admin 通過該 RPC 協議更新系統配置文件，比如節點黑白名單、用戶隊列權限等。
- **AM 與 RM 之間的協議—ApplicationMasterProtocol **：AM 通過該 RPC 協議向 RM 注冊和撤銷自己，並為各個任務申請資源。
- AM 與 NM 之 間 的 協 議 —ContainerManagementProtocol ：AM 通 過 該 RPC 要 求 NM 啟動或者停止 Container，獲取各個 Container 的使用狀態等信息。
- NM 與 RM 之間的協議—ResourceTracker ：NM 通過該 RPC 協議向 RM 注冊，並 定時發送心跳信息匯報當前節點的資源使用情況和 Container 運行情況。
6 YARN 工作流程
運行在 YARN 上的應用程序主要分為兩類 ：短應用程序和長應用程序，其中，
短應 用程序是指一定時間內（可能是秒級、分鍾級或小時級，盡管天級別或者更長時間的也存 在，但非常少）可運行完成並正常退出的應用程序。比如：MapReduce作業。
長應用程序是指不出意外，永不終止運行的 應用程序，通常是一些服務，比如 Storm Service（主要包括 Nimbus 和 Supervisor 兩類服 務），HBase Service（包括 Hmaster 和 RegionServer 兩類服務） 等。
盡管這兩類應用程序作用不同，一類直接運行數據處理程序，一類用於部署服務（服務之上再運行數據處理程序），但運行在 YARN 上的流程是相同的。
當用戶向 YARN 中提交一個應用程序后，YARN 將分兩個階段運行該應用程序 ：第一 個階段是啟動 ApplicationMaster ；第二個階段是由 ApplicationMaster 創建應用程序，為它 申請資源，並監控它的整個運行過程，直到運行完成。
步驟：
- 1.用 戶 向 YARN 中 提 交 應 用 程 序， 其 中 包 括 MRAppMaster 程 序、 啟 動 MRAppMaster 的命令、用戶程序等。(MRAppMstr 程序在客戶端生成，這一步已經將應用程序先行程序提交到RM的Application Manager模塊進行處理，但此時運行程序所需的jar包、環境變量、切片信息等提交到HDFS之上，需要等MRAPPMstr返回一個可用的Container的時候在節點提交執行。可以理解為惰性處理，減少資源占用，做到需要什么提交什么)
- 2.ResourceManager 為該應用程序分配第一個 Container，並與對應的 Node-Manager 通信，要求它在這個 Container 中啟動應用程序的MRAppMaster。（APPMaster就是先頭兵，這時的操作是RM的ApplicationManager來進行處理）
- 3.MRAppMaster 首先向 ResourceManager 注冊， 這樣用戶可以直接通過ResourceManage 查看應用程序的運行狀態，然后它將為各個任務申請資源，並監控它的運行狀態，直到整個應用運行結束。
- 4.MRAppMaster 采用輪詢的方式通過 RPC 協議向 ResourceManager 申請和 領取資源。
- 5.一旦 MRAppMaster 申請到資源后，便與對應的 NodeManager 通信，要求 它啟動任務。(理解集群中不同節點的資源動態變動，可用Container以及不同的Task可以在不同的節點運行)
- 6.NodeManager 為任務設置好運行環境（包括環境變量、JAR 包、二進制程序 等）后，將任務啟動命令寫到一個腳本中，並通過運行該腳本啟動任務。（此時，客戶端才真正上傳具體Task需要的Jar包等等運行資源，同時NodeManager通過調用資源運行對應的Task任務）；
- 7.各個任務通過某個 RPC 協議向 MRAppMaster 匯報自己的狀態和進度，以 讓 MRApplicationMaster 隨時掌握各個任務的運行狀態，從而可以在任務失敗時重新啟動任務。 在應用程序運行過程中，用戶可隨時通過 RPC 向 MRAppMaster 查詢應用程序的當 前運行狀態。
- 步驟4~7是重復執行的
- 8.應用程序運行完成后，MRAppMaster 向 ResourceManager 注銷並關閉自己。
可將 YARN 看做一個雲操作系統，它負責為應用程序啟 動 ApplicationMaster（相當於主線程），然后再由 ApplicationMaster 負責數據切分、任務分配、 啟動和監控等工作，而由 ApplicationMaster 啟動的各個 Task（相當於子線程）僅負責自己的計 算任務。當所有任務計算完成后，ApplicationMaster 認為應用程序運行完成，然后退出。
實例運行
- step1.客戶端程序提交任務到自身所在的節點；
- step2:客戶端獲取一個YARNRunner向ResourceManager（以下簡稱RM）申請一個Application
- step3：RM將該應用程序的資源路徑返回給YARNRunner；
- step4：客戶端程序將運行所需的資源提交到YARN上，提交的內容包括：MRAppMaster程序（MRAppMaster運行程序）、MRAppMaster啟動腳本程序、用戶程序(真正的MapReduce處理程序)等。RM內部分別管理ApplicationManager和ResourceManager管理對象，分別負責和MRAppMaster交互與Resource資源的管理。
- step5：資源提交完畢，並將應用程序作為一個Task放置在調度器中。RM為提交的程序選擇一個空閑的NodeManager(以下簡稱NM)分配第一個Container，並與對應的NM通信，要求NM在當前容器中運行MRAppMaster。（MRAppMaster負責這個程序的運行狀態及進度監控調度等等）。
- step6：MRAppMaster啟動之后先向RM注冊自己。
- step7：然后通過輪詢方式通過RPC協議向RM為自己內部的任務申請資源和領取資源，通過HDFS復制一份Job需要的相關信息，並依據信息向RM申請運行任務的資源。
- step8：MRAppMaster向RM申請MapTask需要的資源，RM分配對應的NM信息給MRAppMaster，MRAppMaster與對應的NM通信，將對應的程序腳本發送給NM。（NM會為任務設置好對應的運行環境，包括環境變量、JAR包、二進制程序等）。NM接受此腳本並開始啟動對應的任務。開啟對應的MapTask任務，MapTask會對數據進行分區排序。
- step9：MRAppMaster在所有MapTask任務結束，MRAppMaster向RM申請資源並運行ReduceTask，ReduceTask會從Maptask 獲取運行數據，執行ReduceTask。
- step10 程序運行結束，MRAppmaster向RM注銷並關閉自己。
7.多角度理解YARN
7.1並行計算
將 YARN 看做一個雲操作系統，它負責為應用程序啟 動 ApplicationMaster（相當於主線程），然后再由 ApplicationMaster 負責數據切分、任務分配、 啟動和監控等工作，而由 ApplicationMaster 啟動的各個 Task（相當於子線程）僅負責自己的計 算任務。當所有任務計算完成后，ApplicationMaster 認為應用程序運行完成，然后退出。
7.2資源管理系統
資源管理系統的主要功能是對集群中各類資源進行抽象，並根據各種應用程序或者服 務的要求，按照一定的調度策略，將資源分配給它們使用，同時需采用一定的資源隔離機制防止應用程序或者服務之間因資源搶占而相互干擾。YARN 正是一個資源管理系統，它的出現弱化了計算框架之爭，引入 YARN 這一層后，各種計算框架可各自發揮自己的優勢， 並由 YARN 進行統一管理，進而運行在一個大集群上。
7.3雲計算
雲計算包括以下幾個層次的服務 ：IaaS、PaaS 和 SaaS。
IaaS(Infrastructure-as-a-Service) ：基礎設施即服務。消費者通過 Internet 可以從完善的計算機基礎設施獲得服務。Iaas 通過網絡向用戶提供計算機（物理機和虛擬機）、存儲空間、 網絡連接、負載均衡和防火牆等基本計算資源 ；用戶在此基礎上部署和運行各種軟件，包括操作系統和應用程序等。如阿里雲、華為雲等雲平台。
PaaS(Platform-as-a-Service) ：平台即服務。PaaS 是將軟件研發的平台作為一種服務， 以 SaaS 的模式提交給用戶。平台通常包括操作系統、編程語言的運行環境、數據庫和 Web 服務器等，用戶可以在平台上部署和運行自己的應用。通常而言，用戶不能管理和控制底 層的基礎設施，只能控制自己部署的應用。
SaaS(Software-as-a-Service)：軟件即服務。它是一種通過 Internet 提供軟件的模式，用 戶無需購買軟件，而是向提供商租用基於 Web 的軟件，來管理企業經營活動。雲提供商在 雲端安裝和運行應用軟件，雲用戶通過雲客戶端（比如 Web 瀏覽器）使用軟件。
從雲計算分層概念上講，YARN 可看做 PAAS 層，它能夠為不同類型的應用程序提供 統一的管理和調度。
總結
YARN 的設計理念和基本架構，包括 YARN 產生背 景、Hadoop 術語解釋和版本變遷、YARN 架構和通信協議等。
從編程模型角度看，YARN 與傳統並行編程模式非常像，但兼具了分布式和並行兩個特點 ；從資源管理系統角度看， YARN 將扮演為上層計算框架提供計算資源的角色 ；從雲計算角度看，YARN 可看做輕量 級的 PAAS 層。