hadoop資源管理框架Yarn的知識體系
Yarn知識學習
下面是Yarn的知識體系圖，這篇文章會介紹所有涉及的知識點。
一、MRv1的架構和缺陷
Apache Hadoop 是一個開源軟體框架，可安裝在一個商用機器集群中，使機器可彼此通信並協同工作，以高度分散式的方式共同存儲和處理大量數據。
在 MapReduce 框架中，作業執行受兩種類型的進程式控制制：
- 一個稱為 JobTracker 的主要進程，它協調在集群上運行的所有作業，分配要在 TaskTracker 上運行的 map 和 reduce 任務。
- 許多稱為 TaskTracker 的下級進程，它們運行分配的任務並定期向 JobTracker 報告進度。
Apache Hadoop 的經典版本 (MRv1)
MapReduce1.x時存在的問題：
- 單點故障
- 節點壓力大
- 不易擴展
- 只支持MapReduce作業
大型 Apache Hadoop 集群 (MRv1) 上繁忙的 JobTracker
為了解決可伸縮性問題，一個簡單而又絕妙的想法應運而生：我們減少了單個 JobTracker 的職責，將部分職責委派給 TaskTracker，因為集群中有許多 TaskTracker。在新設計中，這個概念通過將 JobTracker 的雙重職責（集群資源管理和任務協調）分開為兩種不同類型的進程來反映。
不再擁有單個 JobTracker，一種新方法引入了一個集群管理器，它惟一的職責就是跟蹤集群中的活動節點和可用資源，並將它們分配給任務。對於提交給集群的每個作業，會啟動一個專用的、短暫的 JobTracker 來控制該作業中的任務的執行。有趣的是，短暫的 JobTracker 由在從屬節點上運行的 TaskTracker 啟動。因此，作業的生命周期的協調工作分散在集群中所有可用的機器上。得益於這種行為，更多工作可並行運行，可伸縮性得到了顯著提高。
演進成為Yarn
- ResourceManager 代替集群管理器
- ApplicationMaster 代替一個專用且短暫的 JobTracker
- NodeManager 代替 TaskTracker
- 一個分散式應用程序代替一個 MapReduce 作業
二、Yarn概述
Apache Hadoop YARN （Yet Another Resource Negotiator，另一種資源協調者）是一種新的 Hadoop 資源管理器，它是一個通用資源管理系統，可為上層應用提供統一的資源管理和調度。它將資源管理和處理組件分開，它的引入為集群在利用率、資源統一管理和數據共享等方面帶來了巨大好處。
- YARN是資源調度框架
- 通用的資源管理系統
- 為上層應用提供統一的資源管理和調度
三、Yarn的基礎服務組件
YARN是Hadoop 2.0中的資源管理[系統](http://www.2cto.com/os/)，它的基本設計思想是將MRv1中的JobTracker拆分成了兩個獨立的服務：一個全局的資源管理器ResourceManager和每個應用程序特有的ApplicationMaster。其中ResourceManager負責整個[系統](http://www.2cto.com/os/)的資源管理和分配，而ApplicationMaster負責單個應用程序的管理。
? 下面是Yarn的架構圖：
從上圖可以看出Yarn的核心組件有：
1、Resourcemanager
? RM是一個全局的資源管理器，集群只有一個，負責整個系統的資源管理和分配，包括處理客戶端請求、啟動/監控APP master、監控nodemanager、資源的分配與調度。它主要由兩個組件構成：調度器（Scheduler）和應用程序管理器（Applications Manager，ASM）。
（1） 調度器
? 調度器根據容量、隊列等限制條件（如每個隊列分配一定的資源，最多執行一定數量的作業等），將系統中的資源分配給各個正在運行的應用程序。需要注意的是，該調度器是一個「純調度器」，它不再從事任何與具體應用程序相關的工作，比如不負責監控或者跟蹤應用的執行狀態等，也不負責重新啟動因應用執行失敗或者硬體故障而產生的失敗任務，這些均交由應用程序相關的ApplicationMaster完成。
? 調度器僅根據各個應用程序的資源需求進行資源分配，而資源分配單位用一個抽象概念「資源容器」（Resource Container，簡稱Container）表示，Container是一個動態資源分配單位，它將內存、CPU、磁碟、網路等資源封裝在一起，從而限定每個任務使用的資源量。
? 此外，該調度器是一個可插拔的組件，用戶可根據自己的需要設計新的調度器，Yarn提供了多種直接可用的調度器，比如FIFO Scheduler、Fair Scheduler和Capacity Scheduler等。
（2） 應用程序管理器
? 應用程序管理器負責管理整個系統中所有應用程序，包括應用程序提交、與調度器協商資源以啟動ApplicationMaster、監控ApplicationMaster運行狀態並在失敗時重新啟動它等。
2、ApplicationMaster（AM）
? 在用戶提交一個應用程序時，一個稱為 ApplicationMaster 的輕量型進程實例會啟動來協調應用程序內的所有任務的執行。這包括監視任務，重新啟動失敗的任務，推測性地運行緩慢的任務，以及計算應用程序計數器值的總和。這些職責以前分配給所有作業的單個 JobTracker。ApplicationMaster 和屬於它的應用程序的任務均在受 NodeManager 控制的資源容器（Container）中運行。
功能：
- 數據切分
- 為應用程序申請資源並進一步分配給內部任務。
- 任務監控與容錯
- 負責協調來自resourcemanager的資源，並通過nodemanager監視任務的執行和資源使用情況。
? 有趣的是，ApplicationMaster 可在容器內運行任何類型的任務。例如，MapReduce ApplicationMaster 請求一個容器來啟動 map 或 reduce 任務，而 Giraph ApplicationMaster 請求一個容器來運行 Giraph 任務。還可以實現一個自定義的 ApplicationMaster 來運行特定的任務，進而發明出一種全新的分散式應用程序框架，改變大數據世界的格局。可以查閱 Apache Twill，它旨在簡化 YARN 之上的分散式應用程序的編寫。
? 在 YARN 中，MapReduce 降級為一個分散式應用程序的一個角色（但仍是一個非常流行且有用的角色），現在稱為 MRv2。MRv2 是經典 MapReduce 引擎（現在稱為 MRv1）的重現，運行在 YARN 之上。
3、NodeManager（NM）
? NodeManager 是 TaskTracker 的一種更加普通和高效的版本。沒有固定數量的 map 和 reduce slots，NodeManager 擁有許多動態創建的資源容器（Container）。容器的大小取決於它所包含的資源量，比如內存、CPU、磁碟和網路 IO。一個節點上的容器數量，由配置參數與專用於從屬後台進程和操作系統的資源以外的節點資源總量（比如總 CPU 數和總內存）共同決定。
功能：
- 單個節點上的資源管理和任務。
- 處理來自於resourcemanager的命令。
- 處理來自域ApplicationMaster的命令。
- 管理著抽象容器，這些抽象容器代表著一些特定程序使用針對每個節點的資源。
- 定時地向RM彙報本節點上的資源使用情況和各個Container的運行狀態（cpu和內存等資源）
4、Container
? Container是YARN中的資源抽象，它封裝了某個節點上的多維度資源，如內存、CPU、磁碟、網路等，當AM向RM申請資源時，RM為AM返回的資源便是用Container表示的。YARN會為每個任務分配一個Container，且該任務只能使用該Container中描述的資源。需要注意的是，Container不同於MRv1中的slot，它是一個動態資源劃分單位，是根據應用程序的需求動態生成的。目前為止，YARN僅支持CPU和內存兩種資源，且使用了輕量級資源隔離機制Cgroups進行資源隔離。
功能：
- 對task環境的抽象
- 描述一系列信息
- 任務運行資源的集合（cpu、內存、io等）
小結：
? Client向ResourceManager提交的每一個應用程序都必須有一個Application Master，它經過ResourceManager分配資源後，運行於某一個Slave節點的Container中，具體做事情的Task同樣也運行與某一個Slave節點的Container中。RM，NM，AM乃至普通的Container之間的通信，都是用RPC機制。
? ResourceManager是Master上一個獨立運行的進程，負責集群統一的資源管理、調度、分配等等；NodeManager是Slave上一個獨立運行的進程，負責上報節點的狀態；App Master和Container是運行在Slave上的組件，Container是yarn中分配資源的一個單位，包涵內存、CPU等等資源，yarn以Container為單位分配資源。
? ResourceManager、NodeManager 和容器都不關心應用程序或任務的類型。所有特定於應用程序框架的代碼都轉移到它的 ApplicationMaster，以便任何分散式框架都可以受 YARN 支持 — 只要有人為它實現了相應的 ApplicationMaster。
四、Yarn的作業執行流程
? 當用戶向YARN中提交一個應用程序後，YARN將分兩個階段運行該應用程序：第一個階段是啟動ApplicationMaster；第二個階段是由ApplicationMaster創建應用程序，為它申請資源，並監控它的整個運行過程，直到運行完成，如下圖所示。
根據上圖，可將YARN的工作流程分為如下幾個步驟：
- 用戶向YARN中提交應用程序，其中包括ApplicationMaster程序、啟動ApplicationMaster的命令、用戶程序等；
- ResourceManager為該應用程序分配第一個Container，並與對應的NodeManager通信，要求它在這個Container中啟動應用程序的ApplicationMaster；
- ApplicationMaster首先向ResourceManager註冊，用戶可以直接通過ResourceManager查看應用程序的運行狀態，然後它將為各個任務申請資源，並監控它的運行狀態，直到運行結束，即重複圖中的步驟4～7；
- ApplicationMaster採用輪詢的方式通過RPC協議向ResourceMaster申請和領取資源；
- 一旦ApplicationMaster申請到資源後，便與對應的NodeManager通信，要求它啟動任務；
- NodeManager為任務設置好運行環境（包括環境變數、JAR包、二進位程序等）後，將任務啟動命令寫到一個腳本中，並通過運行該腳本啟動任務；
- 各個任務通過某個RPC協議向ApplicationMaster彙報自己的狀態和進度，以讓ApplicationMaster隨時掌握各個任務的運行狀態，從而可以在任務失敗時重新啟動任務。在應用程序運行過程中，用戶可以隨時通過RPC向ApplicationMaster查詢應用程序的當前運行狀態；
- 應用程序運行完成後，ApplicationMaster向ResourceManager註銷並關閉自己。
上述Yarn作業執行流程可以抽象、直觀的表示為下面的流程圖：
?
分配一個容器後，ApplicationMaster 會要求 NodeManager（管理分配容器的主機）使用這些資源來啟動一個特定於應用程序的任務。此任務可以是在任何框架中編寫的任何進程（比如一個 MapReduce 任務或一個 Giraph 任務）。NodeManager 不會監視任務；它僅監視容器中的資源使用情況，舉例而言，如果一個容器消耗的內存比最初分配的更多，它會結束該容器。
? ApplicationMaster 會竭盡全力協調容器，啟動所有需要的任務來完成它的應用程序。它還監視應用程序及其任務的進度，在新請求的容器中重新啟動失敗的任務，以及向提交應用程序的客戶端報告進度。應用程序完成後，ApplicationMaster 會關閉自己並釋放自己的容器。
? 儘管 ResourceManager 不會對應用程序內的任務執行任何監視，但它會檢查 ApplicationMaster 的健康狀況。如果 ApplicationMaster 失敗，ResourceManager 可在一個新容器中重新啟動它。您可以認為 ResourceManager 負責管理 ApplicationMaster，而 ApplicationMasters 負責管理任務。
五、Yarn的資源調度模型
? YARN提供了一個資源管理平台能夠將集群中的資源統一進行管理。所有節點上的多維度資源都會根據申請抽象為一個個Container。
? YARN採用了雙層資源調度模型：
? RM中的資源調度器將資源分配給各個AM：資源分配過程是非同步的。資源調度器將資源分配給一個應用程序後，它不會立刻push給對應的AM，而是暫時放到一個緩衝區中，等待AM通過周期性的心跳主動來取；
? AM領取到資源後再進一步分配給它內部的各個任務：不屬於YARN平台的範疇，由用戶自行實現。
? 也就是說，ResourceManager分配集群資源的時候，以抽象的Container形式分配給各應用程序，至於應用程序的子任務如何使用這些資源，由應用程序自行決定。
? YARN目前採用的資源分配演算法有三種。但真實的調度器實現中還對演算法做了一定程度的優化。
（1）FIFO Scheduler
? FIFO Scheduler把應用按照提交的順序排成一個隊列，並且是一個先進先出的隊列，在進行資源分配的時候，先給隊列中排在最前面的應用分配資源，待其滿足資源需求後再給下一個應用分配資源，以此類推。
? FIFO Scheduler是最簡單也最容易的資源調度器，但它並不適用於共享集群。大的應用可能會佔用較多的集群資源，這就將導致其他應用被阻塞，而且它也沒有考慮應用的優先順序，因而應用場景非常受限。
（2）Capacity Scheduler
? Capacity Scheduler是Yahoo開發的多用戶調度器，它以隊列為單位劃分資源，每個隊列可設定一定比例的資源最低保證和使用上限，同時，每個用戶也可設定一定的資源使用上限以防止資源濫用。而當一個隊列的資源有剩餘時，可暫時將剩餘資源共享給其他隊列。總的來說，Capacity Scheduler主要有以下幾個特定：
? 容量保證。管理員可為每個隊列設置資源最低保證和資源使用上限，而所有提交到該隊列的應用程序共享這些資源；
? 靈活性。如果一個隊列中的資源有剩餘，可以暫時共享給那些需要資源的隊列，而一旦該隊列有新的應用程序提交，則其他隊列釋放的資源會歸還給該隊列；
? 多重租賃。支持多用戶共享集群和多應用程序同時運行，為防止單個應用程序、用戶或者隊列獨佔集群中的資源，管理員可為之增加多重約束（比如單個應用程序同時運行的任務數等）；
? 安全保證。每個隊列有嚴格的ACL列表規定它的訪問用戶，每個用戶可指定哪些用戶允許查看自己應用程序的運行狀態或者控制應用程序（比如殺死應用程序）。此外，管理員可指定隊列管理員和集群系統管理員；
? 動態更新配置文件。管理員可根據需要動態修改各種配置參數，以實現在線集群管理。
? 關於Capacity Scheduler更加詳細的信息，請參閱官方文檔。
（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三種）；
? 提供小應用程序響應時間。由於採用哦了最大最小公平演算法，小作業可以快速獲取資源並運行完成。
關於Fair Scheduler更加詳細的信息，請參閱官方文檔。
? 想要詳細了解調度器，可以參見資料：Yarn 調度器Scheduler詳解
六、Yarn的資源管理與配置參數
Yarn的內存管理：
? yarn允許用戶配置每個節點上可用的物理內存資源，注意，這裡是「可用的」，因為一個節點上內存會被若干個服務貢享，比如一部分給了yarn，一部分給了hdfs，一部分給了hbase等，yarn配置的只是自己可用的，配置參數如下：
? yarn.nodemanager.resource.memory-mb
? 表示該節點上yarn可以使用的物理內存總量，默認是8192m，注意，如果你的節點內存資源不夠8g，則需要調減這個值，yarn不會智能的探測節點物理內存總量。
? yarn.nodemanager.vmem-pmem-ratio
? 任務使用1m物理內存最多可以使用虛擬內存量，默認是2.1
? yarn.nodemanager.pmem-check-enabled
? 是否啟用一個線程檢查每個任務證使用的物理內存量，如果任務超出了分配值，則直接將其kill，默認是true。
? yarn.nodemanager.vmem-check-enabled
? 是否啟用一個線程檢查每個任務證使用的虛擬內存量，如果任務超出了分配值，則直接將其kill，默認是true。
? yarn.scheduler.minimum-allocation-mb
? 單個任務可以使用最小物理內存量，默認1024m，如果一個任務申請物理內存量少於該值，則該對應值改為這個數。
? yarn.scheduler.maximum-allocation-mb
? 單個任務可以申請的最多的內存量，默認8192m
Yarn cpu管理：
? 目前cpu被劃分為虛擬cpu，這裡的虛擬cpu是yarn自己引入的概念，初衷是考慮到不同節點cpu性能可能不同，每個cpu具有計算能力也是不一樣的，比如，某個物理cpu計算能力可能是另外一個物理cpu的2倍，這時候，你可以通過為第一個物理cpu多配置幾個虛擬cpu彌補這種差異。用戶提交作業時，可以指定每個任務需要的虛擬cpu個數。在yarn中，cpu相關配置參數如下：
? yarn.nodemanager.resource.cpu-vcores
? 表示該節點上yarn可使用的虛擬cpu個數，默認是8個，注意，目前推薦將該值為與物理cpu核數相同。如果你的節點cpu合數不夠8個，則需要調減小這個值，而yarn不會智能的探測節點物理cpu總數。
? yarn.scheduler.minimum-allocation-vcores
? 單個任務可申請最小cpu個數，默認1，如果一個任務申請的cpu個數少於該數，則該對應值被修改為這個數
? yarn.scheduler.maximum-allocation-vcores
? 單個任務可以申請最多虛擬cpu個數，默認是32.
? Yarn的內存相關配置參考：Yarn 內存分配管理機制及相關參數配置
七、構建Yarn應用程序
? 我們自己動手從頭到尾構建一個Yarn應用程序是比較複雜的，很多時候也是不必要的，可以根據需要的不同選擇一個優秀的分散式計算框架幫助我們構建應用程序，如需要DAG計算，則選擇Spark、Tez；需要流式處理，則選擇Spark、Samza或Storm。
? 也有一些開源項目幫助我們簡化Yarn應用程序的構建，如Slider、Twill，目前均處於孵化器狀態，暫時不討論。Yarn本身也自帶了一個例子「Distributed Shell Application」，向我們展示了如果通過Yarn Client API完成Client、Application Master與Yarn Daemons之間的交互。
? 構建Yarn應用程序的例子可以參閱：實現一個簡單的Application框架、hadoop Yarn 編程API
參考資料：
? YARN架構設計詳解
? YARN學習筆記——Overview and Architecture
? 分散式資源調度——YARN框架
? Apache Hadoop YARN
? Hadoop之YARN解析
? Yarn 調度器Scheduler詳解
? Yarn 內存分配管理機制及相關參數配置
? 理解Hadoop YARN架構
? hadoop Yarn 編程API
? Hadoop學習之路（二十四）YARN的資源調度
推薦閱讀：
