1、YARN背景介紹
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爲核心的軟件棧與以YARN爲核心的軟件棧的對比情況，在以MapReduce爲核心的軟件棧中，資源管理系統YARN是可插拔替換的，比如選擇Mesos替換YARN，一旦MapReduce接口改變，所有的資源管理系統的實現均需要跟着改變；但以YARN爲核心的軟件棧則不同，所有框架都需要實現YARN定義的對外接口以運行在YARN之上，這意味着Hadoop2.X可以打造一個以YARN爲核心的生態系統。
隨着互聯網的高速發展，基於數據密集型應用的計算框架不斷出現，從支持離線處理的MapReduce，到支持在線處理的Storm，從迭代式計算框架Spark到流式處理框架S4，各種框架誕生於不同的公司或者實驗室，它們各有所長，各自解決了某一類應用問題。而在大部分互聯網公司中，這幾種框架可能同時被採用，比如在搜索引擎公司中，一種可能的技術方案如下：網頁建立索引採用MapReduce框架，自然語言處理/數據挖掘採用Spark（如網頁PageRank計算、聚類分類算法等），對性能要求很高的數據挖掘算法用MPI等。考慮到資源利用率、運維成本、數據共享等因素，公司一般希望將所有這些框架都部署到一個公共的集羣中，讓它們共享集羣的資源，並對資源進行統一使用，同時採用某種資源隔離方案（如輕量級cgroups）對各個任務進行隔離，這樣便誕生了輕量級計算平臺，如下圖所示，YARN便是彈性計算平臺的典型代表。
YARN是一個彈性計算平臺，它的目標已經不再侷限於支持MapReduce一種計算框架，而是朝着對多種框架進行統一管理的方向發展。相比於“一種計算框架一個集羣”的模式，共享集羣的模式存在多種好處：
資源利用率高。如果每個框架一個集羣，則往往由於應用程序數量和資源需求的不均衡性，使得在某段時間內，有些計算框架的集羣資源緊張，而另外一些集羣資源空閒。共享集羣模式則通過多種框架共享資源，使得集羣中的資源得到更加充分的利用。
運維成本低。如果採用“一個框架一個集羣”的模式，則可能需要多個管理員管理這些集羣，進而增加運維成本，而共享集羣模式通常僅需要少數管理員即可完成多個框架的統一管理。
數據共享。隨着數據量的暴增，跨集羣間的數據移動不僅需要花費更長的時間，且硬件成本也會大大增加，而共享集羣模式可讓多種框架共享數據和硬件資源，將大大減小數據移動帶來的成本。
2、YARN基本架構
YARN總體上仍然是Master/Slave結構，在整個資源管理框架中，ResourceManager爲Master，NodeManager爲Slave，ResourceManager負責對各個NodeManager上的資源進行統一管理和調度。當用戶提交一個應用程序時，需要提供一個用以跟蹤和管理這個程序的ApplicationMaster，它負責向ResourceManager申請資源，並要求NodeManager啓動可以佔用一定資源的任務。由於不同的ApplicationMaster被分佈到不同的節點上，因此它們之間不會相互影響。
下圖描述了YARN的基本組成結構，YARN主要由ResourceManager、NodeManager、ApplicationMaster（圖中給出了MapReduce和MPI兩種計算框架的ApplicationMaster，分別爲MRAppMstr和MPI AppMstr）和Container等幾個組件構成。
A、ResourceManager（RM）
RM是一個全局的資源管理器，負責整個集羣中所有資源的統一管理和分配，它接收來自各個節點（NodeManager）的資源彙報信息，並把這些信息按照一定的策略分配給各個應用程序（實際上是ApplicationMaster）。
整體上來講，ResourceManager需通過兩個RPC協議與NodeManager和（各個應用程序的）ApplicationMaster交互，如下圖所示：
根據上圖，各個RPC協議的具體工作內容描述如下：
ResourceTracker：NodeManager通過該RPC協議向ResourceManager註冊、彙報節點健康狀況和Container運行狀態，並領取ResourceManager下達的命令，這些命令包括重新初始化、清理Container等，在該RPC協議中，ResourceManager扮演RPC Server的角色（由內部組件ResourceTrackerService實現），而NodeManager扮演RPC Client的角色，換句話說，NodeManager與ResourceManager之間採用了”pull模型“，NodeManager總是週期性地主動向ResourceManager發起請求，並通過領取下達給自己的命令；
ApplicationMasterProtocol：應用程序的ApplicationMaster通過該RPC協議向ResourceManager註冊、申請資源和釋放資源。在該協議中，ApplicationMaster扮演RPC Client的角色，而ResourceManager扮演RPC Server的角色，換句話說，ResourceManager與ApplicationMaster之間也採用了”pull模型“；
ApplicationClientProtocol：應用程序的客戶端通過該RPC協議向ResourceManager提交應用程序、查詢應用程序狀態和控制應用（比如殺死應用程序）等。在該協議中，應用程序客戶端扮演RPC Client的角色，而ResourceManager扮演RPC Server的角色。
概括起來，ResourceManagert主要完成以下幾個功能：
與客戶端交互，處理來自客戶端的請求；
啓動和管理ApplicationMaster，並在它運行失敗時重新啓動它；
管理NodeManager，接收來自NodeManager的資源彙報信息，並向NodeManager下達管理命令（比如殺死Container等）；
資源管理與調度，接收來自ApplicationMaster的資源申請請求，併爲之分配資源等。
從另一個角度進行總結，RM主要由兩個組件構成：調度器（Scheduler）和應用程序管理器（Application Manager，ASM）。
（1）調度器
調度器根據容量、隊列等限制條件（如每個隊列分配一定的資源，最多執行一定數量的作業等），將系統中的資源分配給各個正在運行的應用程序。需要注意的是，該調度器是一個“純調度器”，它不再從事任何與具體應用程序相關的工作，比如不負責監控或者跟蹤應用的執行狀態等，也不負責重新啓動因應用執行失敗或者硬件故障而產生的失敗任務，這些均交由應用程序相關的ApplicationMaster完成。調度器僅根據各個應用程序的資源需求進行資源分配，而資源分配單位用一個抽象概念“資源容器”（Resource Container，簡稱Container）表示，Container是一個動態資源分配單位，它將內存、CPU、磁盤網絡等資源封裝在一起，從而限定每個任務使用的資源量。此外，該調度器是一個可插拔的組件，用戶可根據自己的需要設計新的調度器，YARN提供了多種直接可用的調度器，比如Fair Scheduler和Capacity Scheduler等。
（2）應用程序管理器
應用程序管理器負責整個系統中所有應用程序，包括應用提交、與調度器協商資源以啓動ApplicationMaster、監控ApplicationMaster運行狀態並在失敗時重新啓動它等。
B、ApplicationMaster（AM）
用戶提交的每個應用程序均包含一個AM，主要功能包括：
與RM調度器協商以獲取資源（用Container表示）；
將得到的任務進一步分配給內部的任務；
與NM通信以啓動/停止任務；
監控所有任務運行狀態，並在任務運行失敗時重新爲任務申請資源以重啓任務。
當前YARN自帶了兩個AM實現，一個是用於演示AM編寫方法的實例程序distributedshell，它可以申請一定數目的Container以並行運行一個Shell命令或者Shell腳本；另一個是運行MapReduce應用程序的AM——MRAppMaster。
ApplicationMaster管理部分主要由三個服務構成，分別是ApplicationMaster Launcher、AMLivelinessMonitor和ApplicationMasterService，它們共同管理應用程序的ApplicationMaster的生存週期。ApplicationMaster的啓動流程如下圖所示：
從ResourceManager獲得資源到啓動ApplicationMaster的詳細過程，描述如下：
步驟1：用戶向YARN ResourceManager提交應用程序，ResourceManager收到提交請求後，先向資源調度器申請用以啓動ApplicationMaster的資源，待申請到資源後，再由ApplicationMasterLauncher與對應的NodeManager通信，從而啓動應用程序的ApplicationMaster；
步驟2：ApplicationMaster啓動完成後，ApplicationMasterLauncher會通過事件的形式，將剛剛啓動的ApplicationMaster註冊到AMLivelinessMonitor，以啓動心跳監控；
步驟3： ApplicationMaster啓動後，先向ApplicationMasterService註冊，並將自己所在host、端口號等信息彙報給它；
步驟4：ApplicationMaster運行過程中，週期性地向ApplicationMasterService彙報”心跳“信息（包含想要申請的資源描述）；
步驟5：ApplicationMasterService每次收到ApplicationMaster的心跳信息後，將通知AMLivelinessMonitor更新該應用程序的最近彙報心跳的時間；
步驟6：當應用程序運行完成後，ApplicationMaster向ApplicationMasterService發送請求，註銷自己；
步驟7：ApplicationMasterService收到註銷請求後，標註應用程序運行狀態爲完成，同時通知AMLivelinessMonitor移除對它的心跳監控。
C、NodeManager（NM）
NodeManager是YARN中單個節點上的代理，它管理Hadoop集羣中單個計算節點，功能包括與ResourceManager保持童心、管理Container的生命週期、監控每個Container的資源使用（內存、CPU等）情況、追蹤節點健康狀況、管理日誌和不同應用程序用到的附屬服務（auxiliary service）。總結來說就是兩點：一方面，它會定時地向RM彙報本節點上的資源使用情況和各個Container的運行狀態；另一方面，它接收並處理來自AM的Container啓動/停止等各種請求。
整體上來講，NodeManager需通過兩個RPC協議與ResourceManager服務以及各個應用程序的ApplicationMaster交互，如下圖所示：
（1）ResourceTrackerProtocol協議
NodeManager通過該RPC協議向ResourceManager註冊、彙報節點健康狀況和Container運行狀態，並領取ResourceManager下達的命令，包括重新初始化、清理Container佔用資源等。在該RPC協議中，ResourceManager扮演RPC Server的角色，而NodeManager扮演RPC Client的角色（由內部組件NodeStatusUpdater實現），換句話說，NodeManager與ResourceManager之間採用了“pull模型”，NodeManager總是週期性地主動向ResourceManager發起請求，並領取下達給自己的命令。
NodeStatusUpdater：NodeStatusUpdater是NodeManager與ResourceManager通信的唯一通道。當NodeManager啓動時，該組件負責向ResourceManager註冊，並彙報節點上總的可用資源（該值在運行過程中不再彙報）；之後，該組件週期性與ResourceManager通信，彙報各個Container的狀態更新，包括節點上正運行的Container、已完成的Container等信息，同時ResourceManager會爲之返回待清理Container列表、待清理應用程序列表、診斷信息、各種Token等信息。
（2）ContainerManagementProtocol協議
應用程序的ApplicationMaster通過該RPC協議向NodeManager發起針對Container的相關操作，包括啓動Container、殺死Container、獲取Container執行狀態等。在該協議中，ApplicationMaster扮演RPC Client的角色，而NodeManager與ApplicationMaster扮演RPC Server的角色（由內部組件ContainerManager實現），換句話說，NodeManager與ApplicationMaster之間採用了“push模型”，ApplicationMaster可以將Container相關操作第一時間告訴NodeManager，相比於“pull模型”，可大大降低時間延遲。
ContainerManager：ContainerManager是NodeManager中最核心的組件之一，它由多個子組件構成，每個子組件負責一部分功能，共同協作管理運行在該節點上的所有Container。
D、 Container
Container是YARN中的資源抽象，它封裝了某個節點上的多維度資源，如內存、CPU、磁盤、網絡等，當AM向RM申請資源時，RM爲AM返回的資源便是用Container表示的。YARN會爲每個任務分配一個Container，且該任務只能使用該Container中描述的資源。需要注意的是，Container不同於MRv1中的slot，它是一個動態資源劃分單位，是根據應用程序的需求動態生成的。當前，YARN僅支持CPU和內存兩種資源，且使用了輕量級資源隔離機制Cgroups進行資源隔離。
3、資源隔離
資源隔離是指爲不同人物提供可獨立使用的計算資源以避免它們相互干擾。當前存在很多資源隔離技術，比如硬件虛擬化、虛擬機、Cgroups、Linux Container等。
YARN對內存資源和CPU資源採用了不同的資源隔離方案，對於內存資源，它是一種限制性資源，它的量的大小直接決定了應用程序的死活。爲了能夠更靈活地控制內存使用量，YARN提供了兩種可選方案：線程監控方案和基於輕量級資源隔離技術Cgroups的方案。默認情況下YARN採用線程監控的方案控制內存使用，即每個NodeManager會啓動一個額外監控線程監控每個Container內存資源使用量，一旦發現它超過約定的資源量，即將其殺死。採用這種機制的另一個原因是Java中創建子進程採用了“fork()+exec()”的方案，子進程啓動瞬間，它使用的內存量與父進程一致。從外面來看，一個進程使用的內存量可能瞬間翻倍，然後又降下來，採用線程監控的方法可防止這種情況下導致swap操作（因此，默認情況下YARN採用的是線程監控的方案）。另一種可選的方案則基於輕量級資源隔離技術Cgroups，Cgroups是Linux內核提供的彈性資源隔離機制，可以嚴格限制內存使用上限，一旦進程使用資源量超過事先定義的上限值，則可將其殺死。對於CPU資源，它是一種彈性資源，它的量的大小不會直接影響應用程序的死活，因此採用了Cgroups。
Cgroups（Control groups）是Linux內核提供的一種可以限制、記錄、隔離進程組所使用的物理資源（如CPU、內存、IO等）的機制，最初由Google的工程師提出，後來整合進Linux內核。Cgroups最初的目標是爲資源管理提供一個統一的框架，既整合現有的cpuset等子系統，也爲未來開發新的子系統提供接口，以使得Cgroups適用於多種應用場合，從單個進程的資源控制到實現操作系統層次的虛擬化的應用場景均支持。總結起來，Cgroups提供以下功能：
限制進程組使用的資源量。比如，內存子系統可以爲進程組設定一個內存使用上限，一旦進程組使用的內存達到限額，再申請內存，就會觸發OOM；
進程組的優先級控制。比如，可以使用CPU子系統爲某個進程組分配特定cpu share（Hadoop YARN正是使用了該功能）。
對進程組使用的資源量進行記賬。比如，可以記錄某個進程組使用的CPU時間，以便對不同進程組擁有者計費；
進程組控制。比如，可將某個進程組掛起和恢復。
4、YARN工作流程
運行在YARN上的應用程序主要分爲兩類：短應用程序和長應用程序。其中，短應用程序是指一定時間內（可能是秒級、分鐘級或小時級，儘管天級別或者更長時間的也存在，但非常少）可運行完成並正常退出的應用程序，比如MapReduce作業、Tez DAG作業等。長應用程序是指不出意外，永不停止運行的應用程序，通常是一些服務，比如Storm Service（主要包括Nimbus和Supervisor兩類服務），HBase Service（包括Hmaster和RegionServer兩類服務）等，而它們本身作爲一個框架提供了編程接口供用戶使用。儘管這兩類應用程序作用不同，一類直接運行數據處理程序，一類用於部署服務（服務之上再運行數據處理程序），但運行在YARN上的流程是相同的。
當用戶向YARN中提交一個應用程序後，YARN將分兩個階段運行該應用程序：第一個階段是啓動ApplicationMaster；第二個階段是由ApplicationMaster創建應用程序，爲它申請資源，並監控它的整個運行過程，直到運行完成，如下圖所示。
根據上圖，可將YARN的工作流程分爲如下幾個步驟：
步驟1：用戶向YARN中提交應用程序，其中包括ApplicationMaster程序、啓動ApplicationMaster的命令、用戶程序等；
步驟2：ResourceManager爲該應用程序分配第一個Container，並與對應的NodeManager通信，要求它在這個Container中啓動應用程序的ApplicationMaster；
步驟3：ApplicationMaster首先向ResourceManager註冊，這樣用戶可以直接通過ResourceManager查看應用程序的運行狀態，然後它將爲各個任務申請資源，並監控它的運行狀態，直到運行結束，即重複圖中的步驟4～7；
步驟4：ApplicationMaster採用輪詢的方式通過RPC協議向ResourceMaster申請和領取資源；
步驟5：一旦ApplicationMaster申請到資源後，便與對應的NodeManager通信，要求它啓動任務；
步驟6：NodeManager爲任務設置好運行環境（包括環境變量、JAR包、二進制程序等）後，將任務啓動命令寫到一個腳本中，並通過運行該腳本啓動任務；
步驟7：各個任務通過某個RPC協議向ApplicationMaster彙報自己的狀態和進度，以讓ApplicationMaster隨時掌握各個任務的運行狀態，從而可以在任務失敗時重新啓動任務。在應用程序運行過程中，用戶可以隨時通過RPC向ApplicationMaster查詢應用程序的當前運行狀態；
步驟8：應用程序運行完成後，ApplicationMaster向ResourceManager註銷並關閉自己。
5、YARN資源調度器
資源調度器是YARN中最核心的組件之一，且是插拔式的，它定義了一整套接口規範以便用戶可按照需要實現自己的調度器。YARN自帶了FIFO、Capacity Scheduler和Fair Scheduler三種常用的資源調度器，當然，用戶可按照接口規範編寫一個新的資源調度器，並通過簡單的配置使它運行起來。
（1）FIFO Scheduler
FIFO Scheduler把應用按照提交的順序排成一個隊列，並且是一個先進先出的隊列，在進行資源分配的時候，先給隊列中排在最前面的應用分配資源，待其滿足資源需求後再給下一個應用分配資源，以此類推。
FIFO Scheduler是最簡單也最容易的資源調度器，但它並不適用於共享集羣。大的應用可能會佔用較多的集羣資源，這就將導致其他應用被阻塞，而且它也沒有考慮應用的優先級，因而應用場景非常受限。
（2）Capacity Scheduler
Capacity Scheduler是Yahoo開發的多用戶調度器，它以隊列爲單位劃分資源，每個隊列可設定一定比例的資源最低保證和使用上限，同時，每個用戶也可設定一定的資源使用上限以防止資源濫用。而當一個隊列的資源有剩餘時，可暫時將剩餘資源共享給其他隊列。總的來說，Capacity Scheduler主要有以下幾個特定：
容量保證。管理員可爲每個隊列設置資源最低保證和資源使用上限，而所有提交到該隊列的應用程序共享這些資源；
靈活性。如果一個隊列中的資源有剩餘，可以暫時共享給那些需要資源的隊列，而一旦該隊列有新的應用程序提交，則其他隊列釋放的資源會歸還給該隊列；
多重租賃。支持多用戶共享集羣和多應用程序同時運行，爲防止單個應用程序、用戶或者隊列獨佔集羣中的資源，管理員可爲之增加多重約束（比如單個應用程序同時運行的任務數等）；
安全保證。每個隊列有嚴格的ACL列表規定它的訪問用戶，每個用戶可指定哪些用戶允許查看自己應用程序的運行狀態或者控制應用程序（比如殺死應用程序）。此外，管理員可指定隊列管理員和集羣系統管理員；
動態更新配置文件。管理員可根據需要動態修改各種配置參數，以實現在線集羣管理。
（3）Fair Scheduler
Fair Scheduler是Facebook開發的多用戶調度器，同Capacity Scheduler類似。它以隊列爲單位劃分資源，每個隊列可設定一定比例的資源最低保證和使用上限，同時，每個用戶也可設定一定的資源使用上限以防止資源濫用；當一個隊列的資源有剩餘時，可暫時將剩餘資源共享給其他隊列。當然，Fair Scheduler也存在很多與Capacity Scheduler不同之處，主要體現在以下幾個方面：
資源公平共享。在每個隊列中，Fair Scheduler可選擇按照FIFO、Fair或DRF（即Dominant Resource Fairness算法）策略爲應用程序分配資源。其中，Fair策略是一種基於最大最小公平算法實現的資源多路複用方式，默認情況下，每個隊列內部採用該方式分配資源。這意味着，如果一個隊列中有兩個應用程序同時運行，則每個應用程序得到1/2的資源；如果有三個應用程序同時運行，則每個應用程序可得到1/3的資源；
支持資源搶戰。當某個隊列中有剩餘資源時，調度器會將這些資源共享給其他隊列，而當該隊列中有新的應用程序提交時，調度器要爲它回收資源。爲了儘可能降低不必要的計算浪費，調度器採用了先等待再強制回收的策略，即如果等待一段時間後尚有未歸還的資源，則會進行資源搶戰；從那些超額使用資源的隊列中殺死一部分任務，進而釋放資源；
負載均衡。Fair Scheduler提供了一個機遇任務數目的負載均衡機制，該機制儘可能將系統中的任務均勻分配到各個節點上。此外，用戶也可以根據自己的需要設計負載均衡機制；
調度策略配置靈活。Fair Scheduler允許管理員爲每個隊列單獨設置調度策略（當前支持FIFO、Fair或DRF三種）；
提供小應用程序相應時間。由於採用哦了最大最小公平算法，小作業可以快速獲取資源並運行完成。
更多大數據技術精彩內容，歡迎關注
參考文獻：
——《Hadoop技術內幕 深入解析YARN架構設計與實現原理》
——《CSDN其他博文》