資源管理與調度系統-YARN的基本架構與原理
作者：尹正傑
版權聲明：原創作品，謝絕轉載！否則將追究法律責任。
為了能夠對集群中的資源進行統一管理和調度，Hadoop2.0引入了數據操作系統YARN。YARN的引入大大提高了集群的資源利用率，並降低了集群管理成本。
首先，YARN能夠將資源按需分配給各個應用程序，這大大提高了資源利用率，其次，YARN允許各類短作業和長服務混合部署在一個集群中。並提供了容錯，資源隔離及負載均衡等方面的支持，這大大簡化了作業和服務的部署和管理成本。
一.YARN產生背景
由於MRv1（MapReduce version 1）在擴展性，可靠性，資源利用率和多框架等方面存在明顯不足，Apache開始嘗試對MapReduce進行升級改造，進而誕生了更加先進的下一代MapReduce計算框架MRv2（MapReduce version 2）。 由於MRv2將資源管理模塊構建成了一個獨立的通用系統YARN，這直接使得MRv2的核心從計算框架MapReduce轉移為資產管理系統YARN。
相關文章可參考：https://issues.apache.org/jira/browse/MAPREDUCE-279。
1>.MRv1局限性
YARN是在MRv1基礎上演化而來的，它克服了MRv1架構中的各種局限性。在正式介紹YARN之前，我們先了解MRv1的一些局限性，這可概括為以下幾個方面：
（1）可靠性差
MRv1采用了master/slave結構，其中，master存在單點故障問題，一旦它出現故障將導致整個集群不可用。
（2）擴展性差
在MRv1中，JobTracker（master）同時兼備了資源管理和作業控制兩個功能，這成為系統的一個最大瓶頸，嚴重制約了Hadoop集群擴展性。
（3）資源利用概率底
MRv1采用了基於槽位的資源分配模型，槽位是一種粗粒度的資源划分單位，通常一個任務不會用完槽位對應的資源，且其他任務也無法使用這些的空閑資源。此外，Hadoop將槽位分為Map Slot和Reduce Slot兩種，且不允許它們之間共享，常常會導致一種槽位資源緊張而另外一種閑置（比如一個作業剛剛提交時，只會運行Map Task，此時Reduce Slot閑置）
（4）無法支持多種計算框架
隨着互聯網高速發展，MapReduce這種基於磁盤的離線計算框架已經不能滿足應用需求，從而出現了一些新的計算框架，包括內存計算框架，流式計算框架和迭代式計算框架等，而MRv1不能支持多種計算框架並存。
為了克服以上幾個缺點，Apache開始嘗試對Hadoop進行升級改造，進而誕生了更加先進的下一代MapReduce計算框架MRv2。正式由於MRv2將資源管理功能抽象成了一個獨立的通用系統YARN，直接導致下一代MapReduce的核心從單一的計算框架MapReduce轉移為通用的資源管理系統YARN。為了讓讀者更進一步理解以YARN為核心的軟件棧，我們將之與MapReduce為核心的軟件棧進行對比。
如下圖所示，在以MapReduce為核心的協議棧中，資源管理系統YARN是可插拔替換的，比如選擇Mesos替換YARN，一旦MapReduce接口改變，所有的資源管理系統的實現均需要跟着改變；但以YARN為核心的協議棧則不同，所有框架都需要實現YARN定義的對外接口以運行在YARN之上，這意味着Hadoop2.0可以打造一個以YARN為核心的生態系統。
2>. YARN設計動機
YARN作為一個通用的資源管理系統，其目標是將短作業和長服務混合部署到一個集群中，並為它們提供統一的資源管理和調度功能。YARN是大數據系統發展到一定階段的必然之物，除了YARN之外，目前市場上存在很多其他資源管理系統，典型的代表有Google的Borg與Omega和Kubernetes，Twitter的Mesos和騰訊的Torca。概括起來，這類系統的動機是解決兩類問題：提高集群資源利用率和服務自動化部署。 Brog： Google的Borg系統是一個集群管理器，可以運行數千個不同的應用程序中的數十萬個作業，這些作業分布在多個集群中，每個集群最多有數萬台計算機。2015年出版， 博主推薦閱讀一：https://ai.google/research/pubs/pub43438。 博主推薦閱讀二：https://www.infoq.com/news/2015/04/google-borg Omega： Omega，作為Borg的延伸，它的出現是出於提升Borg生態系統軟件工程的願望。Omega應用到了很多在Borg內已經被認證的成功的模式，但是是從頭開始來搭建以期更為一致的構架。Omega存儲了基於Paxos、圍繞transaction的集群的狀態，能夠被集群的控制面板（比如調度器）接觸到，使用了優化的進程控制來解決偶爾發生的沖突。這種分離允許Borgmaster的功能被區分成幾個並列的組建，而不是把所有變化都放到一個單獨的、巨石型的master里。許多Omega的創新（包括多個調度器）都被收錄進了Borg. 博主推薦閱讀：https://www.douban.com/note/547709628/?type=rec。 Kubernetes： 谷歌研發的第三個容器管理系統是Kubernetes。Kubernetes的研發和認知背景，是針對在谷歌外部的對Linux容器感興趣的開發者以及谷歌在公有雲底層商業增長的考慮。和Borg、Omega完全是谷歌內部系統相比，Kubernetes是開源的。 像Omega一樣，Kubernetes在其核心有一個被分享的持久存儲，有組件來檢測相關ojbect的變化。跟Omega不同的是，Omega把存儲直接暴露給信任的控制面板的組件，而在Kubernete中，是要完全由domain-specific的提供更高一層的版本控制認證、語義、政策的REST API來接觸，以服務更多的用戶。更重要的是，Kubernetes是由一支在集群層面應用開發能力更強的開發者開發的，他們主要的設計目標是用更容易的方法去部署和管理復雜的分布式系統，同時仍然能通過容器所提升的使用效率來受益。 博主推薦閱讀：https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/。 Mesos： Mesos使用與Linux內核相同的原理構建，僅在不同的抽象級別上構建。Mesos內核在每台機器上運行，並為API提供應用程序（例如，Hadoop，Spark，Kafka，Elasticsearch），用於整個數據中心和雲環境的資源管理和調度。 博主推薦閱讀：http://mesos.apache.org/ Torca： torca作為騰訊Typython雲平台的資源調度子系統，已經在網頁搜索，廣告方面廣泛應用。Torca屬於Monolithic架構，一個Torca集群由一個Central Manager和若干Execute Server組成。Central Manager是集群任務調度中心，Execute Server接收任務並負責相應執行。 博主推薦閱讀：http://www.360doc.com/content/17/0112/09/39325967_621918175.shtml。
1>.提高集群資源利用率
在大數據時代，為了存儲和處理海量數據，需要規模較大的服務器集群或者數據中心，一般來說，這些集群上運行着眾多類型負載的應用程序和服務，比如離線作業，流式作業，迭代式作業，Crawler Server，Web Server等，傳統的做法是，每種類型的作業或者服務對應一個單獨的集群，以避免互相干擾。這樣，集群被分割成數量眾多的小集群：Hadoop集群，HBase集群，Storm集群，Web Server集群等。
然而，由於不同類型的作業服務需要的資源量不同，因此，這些較小集群的利用率通常很不均衡，有的集群滿負荷，資源緊張，而另外一些則長時間閑置，資源利用率極低，而由於這些集群之間資源無法共享，因此造就了不同時間段不同集群資源利用率不同。
為了提高資源整體利用率，一種解決方案是將這些小集群合並成一個大集群，讓它們共享這個大集群的資源，並由一個資源統一調度系統進行資源管理和分配，這就誕生了類似與YARN的系統。從集群共享角度看，這類系統實際上將公司的所有硬件資源抽象一台大型計算機，供所有用戶使用。
2>.服務自動化部署
一旦將所有服務計算資源抽象成一個“大型計算機”后，就會產生一個問題：公司的各種服務如何進行部署？Brog/YARN/Mesos/Torca這類系統需要具備服務自動化部署的功能，因此，從服務部署的角度看，這類系統實際上是服務統一管理系統，這類系統提供服務資源申請，服務自動化部署，服務容錯等功能。
二.YARN設計思想
在Hadoop 1.0中，JobTracker由資源管理（TaskScheduler模塊實現）和作業控制兩部分組成，具體如下圖所示：
第一代Hadoop MapReduce之所以在可擴展性，資源利用率和多框架支持等方面存在不足，正式由於第一代Hadoop對JobTracker賦予的功能過多而造成負載過重，此外，從設計角度上看，第一代Hadoop未能夠將資源管理相關的功能和應用程序相關的功能分開，造成第一代Hadoop難以支持多種計算框架。
下一代MapReduce框架的基本設計思想是將JobTracker的兩個主要功能，及資源管理和作業控制（包括作業監控，容錯等），分拆成兩個獨立的進程，如下圖所示：
資源管理進程與具體應用程序無關，它負責整個集群的資源管理（內存，CPU，磁盤等），而作業控制進程則是直接與應用程序相關的模塊，且每個作業控制進程只負責管理一個作業（這說明每個作業控制進程的信息是不共享的，因此它們很可能將作業放在同一台物理機器上執行導致某台機器負載過大）。
這樣，通過原有JobTracker中與應用程序相關和無關的模塊分開，不僅減輕了JobTracker的負載，也使得Hadoop支持更多的計算框架。
從資源管理的角度看，下一代MapReduce框架衍生出了一個資源統一管理平台，它使得Hadoop不再局限與僅支持MapReduce一種計算模型，而是可無限融入多種計算框架，並且對這些框架進行統一管理和調度。
三.YARN的基本架構
YARN總體上采用master/slave架構，其中，ResourceManager為master，NodeManager為slave，ResourceManager負責對各個NodeManager上資源進行統一管理和調度。當用戶提交一個應用程序時，需要提供一個用以跟蹤和管理這個程序的ApplicationMaster，他負責向ResourceManager申請資源，並要求NodeManager啟動可以占用一定資源的任務，由於不同的ApplicationMaster被分布到不同的節點上，因此它們之間不會互相影響。
下圖描述了YARN的基本組成結構，YARN主要由ResourceManager，NodeManager，ApplicationMaster（圖中給出了MapReduce和MPI兩種計算框架的ApplicationMaster，分別為MR AppMstr和MPI AppMstr）和Container等幾個組件構成。
1>.ResourceManager（簡稱RM）
RM是一個全局的資源管理器，負責整個系統的資源管理和分配。他主要由兩個組件構成：調度器（Scheduler）和應用管理器（Applications Manager，簡稱ASM）。 （1）調度器（Scheduler） 調度器主要功能是根據資源容量，隊列等方面的限制條件（如每個隊列分配一定的資源，最多執行一定數量的作業等），將系統中的資源分配給各個應用程序。
YARN中的調度器是一個“純調度器”，他不在從事任何與具體應用程序相關的工作，比如不負責監控或者跟蹤應用的執行狀態等，也不負責重新啟動因應用執行失敗或者硬件故障而產生的失敗任務，這些均交由應用程序相關的ApplicationMaster完成。
調度器僅根據各個應用程序的資源需求進行資源分配，而資源分配單位用一個抽象概念“資源容器”（Resource Container，簡稱Container）表示，Container是一個動態資源分配單位，他將內存，CPU，磁盤，網絡等資源封裝在一起，從而限定每個任務使用的資源量。
在YARN中，資源調度器是一個可插拔的組件，用戶根據自己的需求設計新的調度器，YARN提供了多種直接可用的調度器，比如Fair Scheduler和Capacity Scheduler。 （2）應用管理器（Applications Manager，簡稱ASM）
應用程序管理器負責整個系統中的所有應用程序，包括應用程序提交，與調度器協商資源以啟動ApplicationMaster，監控ApplicationMaster運行狀態並在失敗時重新啟動他等。
為了避免單個ResourceManager出現單點故障導致整個集群不可用，YARN引入貯備ResourceManager實現HA，當Active ResourceManager出現故障時，Standby ResourceManager會通過zookeeper選舉，自動提升為Active ResourceManager。
2>.ApplicationMaster(簡稱AM)
用戶提交的每個應用程序均包含一個獨立的AM，其主要功能包括： （1）與RM調度器協商以獲取資源（用Container表示）。 （2）將得到的資源進一步分配給內部的任務。 （3）與NM通信已啟動/停止任務。 （4）監控所有任務的運行狀態，並在任務運行失敗時重新為任務申請資源以重啟任務。 當前YARN源代碼中自帶了兩個AM實現，一個是用於演示AM編寫方法的實例程序distributedshell，它可以申請一定數目的Container運行一個shell命令或shell腳本，另一個是運行MapReducer應用程序的AM，即MRAppMaster。很多開源的計算框架和服務為了能夠運行在YARN上，也提供了自己的ApplicationMaster實現，包括Open MPI，Spark，HBase，Impala等。
3>.NodeManager(簡稱NM)
NM是每個節點上的資源管理器，一方面，它會定時的向RM匯報本節點上的資源使用情況和各個Container的運行狀態，另一方面，它接受並處理來自AM的任務啟動/停止等各種請求。在一個集群中，NodeManager通常存在多個，由於YARN內置了容錯機制，單個NodeManager的故障不會對集群的應用程序運行產生嚴重影響。
4>.Container
Container是YARN中的基本資源分配單位，是對應用程序運行環境的抽象，並未應用程序提供資源隔離環境。它封裝了多維度的資源，如內存，CPU，磁盤，網絡等，當AM向RM申請資源時，RM為AM返回的資源便是用Container表示的。 YARN中每個任務均會對應一個Container，且該任務只能使用Container中描述的資源。 需要注意的是，Container不同於MRv1的slot，它是一個動態資源划分單位，是根據應用程序的需求動態生成的。Container最終是由ContainerExecutor啟動和運行的，YARN提供了三種可選的ContainerExecutor： （1）DefaultContainerExecutor 默認ContainerExecutor實現，直接以進程方式啟動Container，不提供任何隔離機制和安全機制，任何應用程序最終均是以YARN服務啟動着的身份運行的。 （2）LinuxContainerExecutor 提供了安全的Cgroups隔離的ContainerExecutor，它以應用程序提交者的身份運行Container，且使用Cgroups為Container提供CPU和內存隔離的運行環境。 （3）DockerContainerExecutor
基於Docker實現的ContainerExecutor，可直接在YARN集群中運行Docker Container。Docker是基於Linux Container技術構建的非常輕量級的虛擬機，目前被廣泛應用在服務器部署，自動化測試等場景中。
YARN內存隔離：https://issues.apache.org/jira/browse/YARN-3
Docker官網：https://www.docker.com/
四.YARN的高可用
YARN提供了恢復機制，這使得YARN在服務出現故障和人工重啟時，不會對正在運行的應用程序產生任何影響。
我們將從ResourceManager HA，ResourceManager Recovery和NodeManager Recovery三個方面討論YARN在高可用方面的設計。以下幾種高可用機制的實現，使得YARN成為一個通用的資源管理系統，這使得在一個集群中混合部署短作業和長服務變得可能。
1>.ResourceManager HA
ResourceManager負責集群中資源的調度和應用程序的管理，是YARN最核心的組件。由於采用了master/slave架構，這使得ResourceManager成為單點故障。為了避免ResourceManager故障導致整個集群不可用，YARN引入了Active/Standby ResourceManager，通過冗余方式解決單點故障。
當Active ResourceManager出現故障時，Standby ResourceManager可通過Zookeeper選舉成為Active ResourceManager，並通過ResourceManager Recovery機制恢復狀態。
關於YARN的HA部署可參考為之前的筆記：https://www.cnblogs.com/yinzhengjie/p/10726455.html
2>.ResourceManager Recovery
RecourseManager內置了重啟恢復功能，當ResourceManager就地重啟，或發生Active/Standby切換是，不會影響正在運行的應用程序運行。ResourceManager Recovery主要流程如下： （1）：保存元信息 Active ResourceManager運行過程中，會將應用程序的元數據，狀態信息以及安全憑證等數據持久化到狀態存儲系統（state-store）中，YARN支持三種可選的state-store，分別是： 1）基於zookeeper的state-store： zookeeper是ResourceManager HA必選的state-store，盡管ResourceManager Restart可選其他的state-store，但只有zookeeper能防止腦裂（split-brain）現象，即同時存在多個Active ResourceManager狀態信息的情況。 2）基於FileSystem的state-store： 支持HDFS和本地文件系統兩種方式，但不能防止腦裂（split-brain） 3）基於LevelDB的state-store： 基於LevelDB的state-store比前兩種方案更加輕量級。LevelDB能更好地支持原子操作，每次更新占用更少的IO資源，生成的文件數目更少。 LevelDB中文網：https://leveldb.org.cn/。 （2）：加載元信息 一旦Active ResourceManager 重啟或出現故障，新啟動的ResourceManager將從存儲系統中重新加載應用程序的相關數據，在此過程中，所有運行在各個NodeManager的Container仍然正常運行。 （3）：重構狀態信息 新的ResourceManager重啟完成后，各個NodeManager會向它重新注冊，並將所管理的Container回報給ResourceManager，這樣ResourceManager可動態重構資源分配信息，各個應用程序以及其對應Container等關鍵數據；同時，ApplicationMaster會向ResourceManager重新發送資源請求，以便ResourceManager重新為其分配資源。
3>.NodeManager Recovery
NodeManager內置了重新恢復功能，當NodeManager就第重啟時，之前正在運行的Contain不會被殺掉，而是有新的NodeManager接管，並繼續正常運行。
五.YARN工作流程
運行在YARN上的應用程序主要分為兩類：短作業和長服務，其中，短作業是值一定時間內（可能是秒級，分鍾級或小時級，盡管天級別或者更長時間的也存在，但非常少）可運行完成並退出的應用程序，比如MapReduce作業，Spark作業等；長服務是值不出意外，用不終止運行的應用程序，通常是一些在線服務，比如Storm Service（主要包括Nimbus和Supervisor兩類服務），HBase Service（包括Hmaster和RegionServer兩類服務）等，而它們本身作為一個框架或服務提供了訪問接口供用戶使用。盡管這兩類應用程序作用不同，一類直接運行數據處理程序，一類用於部署服務（在服務上再運行數據處理程序），但運行在YARN上的流程是想用的。
當用戶向YARN中提交一些應用程序后，YARN將分為兩個階段運行該應用程序：第一個階段是啟動ApplicationMaster；第二個階段是由ApplicationMaster創建應用程序，為它申請資源，並監控它的整個運行過程，直到運行成功。如下圖所示：
YARN的工作流程分為以下結果步驟： 1）提交應用程序 用戶通過客戶端與YARN ResourceManager通信以提交應用程序。應用程序中包括ApplicationMaster可之行代碼，啟動命令和資源需求，應用程序可執行代碼和資源需求，優先級，提交到的隊列等信息。 2）啟動ApplicationMaster ResourceManager為該應用程序分配第一個Container，並與對應的NodeManager通信，要求它在這個Container中啟動應用程序的ApplicationMaster，之后ApplicationMaster的生命周期直接被ResourceManager管理。 3）ApplicationMaster注冊 ApplicationMaster啟動后，首先，向ResourceManager注冊，這樣，用戶可以直接通過ResourceManager查看應用程序的運行狀態，然后，它將初始化應用程序，並按照一定的策略為內部申請資源，監控它們的運行狀態，直到運行結束，即重復步驟4-7。 4）獲取資源 ApplicationMaster采用輪詢的方式通過RPC協議向ResourceManager申請和領取資源。 5）請求啟動Container 一旦ApplicationMaster申請到資源后，則與對應的NodeManager通信，請求為其啟動任務（NodeManager會將任務放到Container中） 6）啟動Container NodeManager為任務設置好運行環境（包括環境變量，jar包，二進制程序等）后，將任務啟動命令寫到一個腳本中，並通過ContainerExecutor運行該腳本啟動任務。
7）Container監控 ApplicationMaster可通過兩種方式獲取各個Container運行的狀態以便在任務失敗時重新啟動任務： 方式一：ApplicationMaster與ResourceManager間維護了周期性心跳信息，每次通信可獲取自己分管的Container的運行狀態。 方式二：各個Container可通過某個RPC協議向ApplicationMaster匯報自己的狀態和進度（視具體情況而定，比如MapReduce和YARN均實現了該方式）。 8）注銷ApplicationMaster 應用程序運行完成后，ApplicationMaster向ResourceManager注銷，並退出執行。
博主推薦閱讀：“HBase ON YARN”（https://hortonworks.com/blog/hoya-hbase-on-yarn-application-architecture/）