1. Hadoop 2.0 中的資源管理

http://dongxicheng.org/mapreduce-nextgen/hadoop-1-and-2-resource-manage/

Hadoop 2.0指的是版本為Apache Hadoop 0.23.x、2.x或者CDH4系列的Hadoop，內(nèi)核主要由HDFS、MapReduce和YARN三個系統(tǒng)組成，其中，YARN是一個資源管理系統(tǒng)，負責集群資源管理和調(diào)度，MapReduce則是運行在YARN上離線處理框架，它與Hadoop 1.0中的MapReduce在編程模型（新舊API）和數(shù)據(jù)處理引擎（MapTask和ReduceTask）兩個方面是相同的。

讓我們回歸到資源分配的本質(zhì)，即根據(jù)任務資源需求為其分配系統(tǒng)中的各類資源。在實際系統(tǒng)中，資源本身是多維度的，包括CPU、內(nèi)存、網(wǎng)絡I/O和磁盤I/O等，因此，如果想精確控制資源分配，不能再有slot的概念，最直接的方法是讓任務直接向調(diào)度器申請自己需要的資源（比如某個任務可申請1.5GB 內(nèi)存和1個CPU），而調(diào)度器則按照任務實際需求為其精細地分配對應的資源量，不再簡單的將一個Slot分配給它，Hadoop 2.0正式采用了這種基于真實資源量的資源分配方案。

Hadoop 2.0（YARN）允許每個節(jié)點（NodeManager）配置可用的CPU和內(nèi)存資源總量，而中央調(diào)度器則會根據(jù)這些資源總量分配給應用程序。節(jié)點（NodeManager）配置參數(shù)如下：

（1）yarn.nodemanager.resource.memory-mb

可分配的物理內(nèi)存總量，默認是8*1024，即8GB。

（2）yarn.nodemanager.vmem-pmem-ratio

任務使用單位物理內(nèi)存量對應最多可使用的虛擬內(nèi)存量，默認值是2.1，表示每使用1MB的物理內(nèi)存，最多可以使用2.1MB的虛擬內(nèi)存總量。

（3）yarn.nodemanager.resource.cpu-vcore

可分配的虛擬CPU個數(shù)，默認是8。為了更細粒度的劃分CPU資源和考慮到CPU性能異構性，YARN允許管理員根據(jù)實際需要和CPU性能將每個物理CPU劃分成若干個虛擬CPU，而每管理員可為每個節(jié)點單獨配置可用的虛擬CPU個數(shù)，且用戶提交應用程序時，也可指定每個任務需要的虛擬CPU個數(shù)。比如node1節(jié)點上有8個CPU，node2上有16個CPU，且node1 CPU性能是node2的2倍，那么可為這兩個節(jié)點配置相同數(shù)目的虛擬CPU個數(shù)，比如均為32，由于用戶設置虛擬CPU個數(shù)必須是整數(shù)，每個任務至少使用node2 的半個CPU（不能更少了）。

此外，Hadoop 2.0還引入了基于cgroups的輕量級資源隔離方案，這大大降低了同節(jié)點上任務間的相互干擾，而Hadoop 1.0僅采用了基于JVM的資源隔離，粒度非常粗糙。

盡管Hadoop 2.中的資源管理方案看似比較完美，但仍存在以下幾個問題：

（1）?資源總量仍是靜態(tài)配置的，不可以動態(tài)修改。這個已在完善中，具體可參考：

https://issues.apache.org/jira/browse/YARN-291

（2）CPU是通過引入的“虛擬CPU”設置的，而虛擬CPU的概念是模糊的，有歧義的，而社區(qū)正在嘗試借鑒amazon EC2中的ECU概念對其進行規(guī)整化，具體參考：

https://issues.apache.org/jira/browse/YARN-1024

https://issues.apache.org/jira/browse/YARN-972

（3）無法支持以組為單位的資源申請，比如申請一組符合某種要求的資源，目前社區(qū)也在添加，具體參考：

https://issues.apache.org/jira/browse/YARN-624

（4）調(diào)度語義不完善，比如目前應用程序只能申請的同一個節(jié)點上相同優(yōu)先級的資源種類必須唯一，比如來自節(jié)點node1上優(yōu)先級為3的資源大小是<1 vcore 2048 mb>，則不能再有自他大小，否則將會被覆蓋掉。目前社區(qū)正在完善，具體參考：

https://issues.apache.org/jira/browse/YARN-314

因此，在資源管理方面，Hadoop 2.0比1.0先進的多，它摒棄了基于slot的資源管理方案，采用了基于真實資源的管理方案，這將在資源利用率、資源控制、資源隔離等方面有明顯改善，隨著Hadoop 2.0調(diào)度語義的豐富和完善，它必將發(fā)揮越來越大的作用。

2. Yarn 框架原理及運行機制

2.1 Yarn 框架

?

(1) ResourceManager：以下簡稱RM。YARN的中控模塊，負責統(tǒng)一規(guī)劃資源的使用。它接收來自NM的匯報，建立AM，并將資源派送給AM。?
(2) NodeManager：以下簡稱MM。YARN中的資源結點模塊，負責啟動管理container。
(3) ApplicationMaster：以下簡稱AM。YARN中每個應用都會啟動一個AM，負責向RM申請資源，請求NM啟動container，并告訴container做什么事情。?
(4) Container：對任務運行環(huán)境的抽象。它描述一系列信息：任務運行資源（包括節(jié)點、內(nèi)存、CPU）、任務啟動命令、任務運行環(huán)境? Hadoop 2.0 中重構根本的思想是將 MR JobTracker 兩個主要的功能分離成單獨的組件，這兩個功能是?資源管理和任務調(diào)度 / 監(jiān)控。新的資源管理器全局管理所有應用程序計算資源的分配，每一個應用的 ApplicationMaster 負責相應的調(diào)度和協(xié)調(diào)。一個應用程序無非是一個單獨的傳統(tǒng)的 MapReduce 任務或者是一個 DAG( 有向無環(huán)圖 ) 任務。ResourceManager 和每一臺機器的節(jié)點管理服務器能夠管理用戶在那臺機器上的進程并能對計算進行組織。 事實上，每一個應用的 ApplicationMaster 是一個詳細的框架庫，它結合從 ResourceManager 獲得的資源和 NodeManager 協(xié)同工作來運行和監(jiān)控任務。
上圖中 ResourceManager 支持分層級的應用隊列，這些隊列享有集群一定比例的資源。從某種意義上講它就是一個純粹的調(diào)度器，它在執(zhí)行過程中不對應用進行監(jiān)控和狀態(tài)跟蹤。同樣，它也不能重啟因應用失敗或者硬件錯誤而運行失敗的任務。 ResourceManager 是基于應用程序對資源的需求進行調(diào)度的 ; 每一個應用程序需要不同類型的資源，因此就需要不同的容器。資源包括：內(nèi)存，CPU，磁盤，網(wǎng)絡等等。可以看出，這同現(xiàn) Mapreduce 固定類型的資源使用模型有顯著區(qū)別，它給集群的使用帶來負面的影響。資源管理器提供一個調(diào)度策略的插件，它負責將集群資源分配給多個隊列和應用程序。調(diào)度插件可以基于現(xiàn)有的能力調(diào)度和公平調(diào)度模型。 上圖中 NodeManager 是每一臺機器框架的代理，是執(zhí)行應用程序的容器，監(jiān)控應用程序的資源使用情況 (CPU，內(nèi)存，硬盤，網(wǎng)絡 ) 并且向調(diào)度器匯報。
每一個應用的 ApplicationMaster 的職責有：向調(diào)度器索要適當?shù)馁Y源容器，運行任務，跟蹤應用程序的狀態(tài)和監(jiān)控它們的進程，處理任務的失敗原因。

2.2?Yarn 框架相對于老的 MapReduce 框架的優(yōu)勢呢

1. 這個設計大大減小了 JobTracker（也就是現(xiàn)在的 ResourceManager）的資源消耗，并且讓監(jiān)測每一個 Job 子任務 (tasks) 狀態(tài)的程序分布式化了，更安全、更優(yōu)美。
???? 2. 在新的 Yarn 中，ApplicationMaster 是一個可變更的部分，用戶可以對不同的編程模型寫自己的 AppMst，讓更多類型的編程模型能夠跑在 Hadoop 集群中，可以參考 hadoop Yarn 官方配置模板中的 mapred-site.xml 配置。
???? 3. 對于資源的表示以內(nèi)存為單位 ( 在目前版本的 Yarn 中，沒有考慮 cpu 的占用 )，比之前以剩余 slot 數(shù)目更合理。
???? 4. 老的框架中，JobTracker 一個很大的負擔就是監(jiān)控 job 下的 tasks 的運行狀況，現(xiàn)在，這個部分就扔給 ApplicationMaster 做了，而 ResourceManager 中有一個模塊叫做 ApplicationsMasters( 注意不是 ApplicationMaster)，它是監(jiān)測 ApplicationMaster 的運行狀況，如果出問題，會將其在其他機器上重啟。
???? 5. Container 是 Yarn 為了將來作資源隔離而提出的一個框架。這一點應該借鑒了 Mesos 的工作，目前是一個框架，僅僅提供 java 虛擬機內(nèi)存的隔離 ,hadoop 團隊的設計思路應該后續(xù)能支持更多的資源調(diào)度和控制 , 既然資源表示成內(nèi)存量，那就沒有了之前的 map slot/reduce slot 分開造成集群資源閑置的尷尬情況。

2.3 以 Yarn 為基礎的 Hadoop 2.0 生態(tài)系統(tǒng)

新一代的 YARN 容器框架，是傳統(tǒng)的MR Hadoop容器框架的升級版本，之前的MR部署架構依賴于JobTracker和TaskTracker的交互模式，而新一代的YARN容器框架，則采用了ResourceManager和NodeManager的交互模式，更高層次的抽象和架構設計，是的YARN容器框架能夠支撐多種計算引擎運行，包括傳統(tǒng)的Hadoop MR和現(xiàn)在的比較新的SPARK。?Hadoop 2.0 中的資源管理框架，它是一個框架管理器，為各種框架進行資源分配和提供運行時環(huán)境。而 MRv2 則是運行在YARN之上的第一個計算框架，其他計算框架，比如Spark、Storm等，都正在往YARN上移植。 (1)離線計算框架：MapReduce? (2)DAG計算框架：Tez? (3)流式計算框架：Storm? (4)內(nèi)存計算框架：Spark? (5)圖計算框架：Giraph，Graphlib 注：以上內(nèi)容皆來自于互聯(lián)網(wǎng)。

總結

以上是生活随笔為你收集整理的Hadoop 2.0 中的资源管理框架 - YARN(Yet Another Resource Negotiator)的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。