分布式資源管理框架YARN

1. YARN概述

??YARN是“Yet Another Resource Negotiator”的簡稱。
??在進一步了解 YARN 框架之前我們需要知道，相比較而言，MapReduce 則是 YARN 的一個特例。 YARN 則是 MapReduce 的一個更加通用和高級的框架形式，并在其上增加了更多的功能。例如通過加載分布式執行腳本可以在集群節點上執行獨立的腳本任務，并且更多功能正在被追加中。
??所以我們可以看到，YARN 可以直接運行在 MapReduce 運行的框架上而不會造成更多的干擾，并且會為集群的運算帶來更多的好處。更一步的開發顯示了 YARN 會允許開發者根據自己的需求運行不同版的MapReduce 在集群中，這將為開發者提供更為便捷的服務。
??普遍認為，云計算包括以下幾個層次的服務: IaaS、PaaS和SaaS。這里所謂的層次，是分層體系架構意義上的“層次”。laas. Paas、 Saas分別實現在基礎設施層、軟件開放運行平臺層、應用軟件層。

• IaaS(Infrastructure-as-a-Service):基礎設施即服務。消費者通過Internet可以從完善的計算機基礎設施獲得服務。laas 通過網絡向用戶提供計算機(物理機和虛擬機)、存儲空間、網絡連接、負載均衡和防火墻等基本計算資源;用戶在此基礎上部署和運行各種軟件，包括操作系統和應用程序等。
• PaaS(Platform-as-a-Service):平臺即服務。PaaS 是將軟件研發的平臺作為一種服務，以SaaS的模式提交給用戶。平臺通常包括操作系統、編程語言的運行環境、數據庫和Web服務器等，用戶可以在平臺上部署和運行自己的應用。通常而言，用戶不能管理和控制底層的基礎設施，只能控制自已部署的應用。
• SaaS(Software-as-a-Service):軟件即服務。它是一種通過Internet提供軟件的模式，用戶無需購買軟件，而是向提供商租用基于Web的軟件，來管理企業經營活動。云提供商在云端安裝和運行應用軟件，云用戶通過云客戶端(比如Web瀏覽器)使用軟件。

??從云計算分層概念上講，YARN可看做PAAS層，它能夠為不同類型的應用程序提供統一的管理和調度。

2. YARN 設計目標

??通用的統一資源管理系統
??同時運行長應用程序和短應用程序

• 長應用程序
  通常情況下，永不停止運行
  Service（Spark、Storm）、HTTP Server等
• 短應用程序
  短時間（秒級、分鐘級、小時級）內會運行結束的程序
  MR job、Spark Job等

3.Hadoop1 MapReduce (架構理解圖)

4. YARN架構

關于上圖架構 ,主要包括以下幾種角色
ResourceManager(RM)：
??主要接收客戶端任務請求，接收和監控NodeManager(NM)的資源情況匯報，負責資源的分配與調度，啟動和監控ApplicationMaster(AM)。
NodeManager：
??主要是節點上的資源管理，啟動Container運行task計算，上報資源、container情況給RM和任務處理情況給AM。
ApplicationMaster：
??主要是單個Application(Job)的task管理和調度，向RM進行資源的申請，向NM發launch Container指令，接收NM的task處理狀態信息。

ResourceManager是Yarn的核心, 負責調度Application master, 來給每個NodeManager分配資源, 資源儲存在Container中, 此處的資源包括JVM,內存等, 然后將程序copy到container中運行, container還需要回報狀態給App master, 再有app master匯報給Resource manager, nodeManager也要按時匯報ResourceManager當前節點的資源使用情況.
下面簡單介紹以下提交一個job的處理過程
1、client submit一個job到RM，進入RM中的Scheduler隊列供調度(Scheduler負責申請資源)
2、RM根據NM匯報的資源情況(NM會定時匯報資源和container使用情況)，請求一個合適的NM launch container，以啟動運行AM
3、AM啟動后，注冊到RM上，以使client可以查到AM的信息，便于client直接和AM通信
4、AM啟動后，根據Job 相關的split的task情況，會和RM協商申請container資源
5、RM分配給AM container資源后，根據container的信息，向對應的NM 請求launch container
6、NM啟動container運行task，運行過程中向AM匯報進度狀態信息，類似于MRv1中 task的匯報；同時NM也會定時的向RM匯報container的使用情況。
7、在application(job)執行過程中，client可以和AM通信，獲取application相關的進度和狀態信息。
8、在application(job)完成后，AM通知RM clear自己的相關信息，并關閉，釋放自己占用的container。

5.YARN調度管理

yarn分為一級調度管理和二級調度管理

• 一級調度管理 (更近底層,更接近于操作資源, 更偏向于應用層和底層結合)
  計算資源管理(cpu,內存等,計算復雜消耗的cpu多)
  App生命周期管理
• 二級調度管理 (自己代碼的算法等, 更偏向于應用層)
  App內部的計算模型管理
  多樣化的計算模型

6. YARN 服務組件

• 組件： Client、 runjar 、 MRAppMaster、ResourceManager、Application Master NodeManager、Container yarnchild
• container 容器 （1.啟動 appmaster 2.container 列表 yarnchild）
• 其他組件

YARN 總體上仍然是Master/Slave(主/從) 結構，在整個資源管理框架中，ResourceManager 為主Master ，NodeManager 為從Slave。
ResourceManager：
??負責對各個NodeManager 上的資源進行統一管理和調度（自身的資源使用情況 自身的運行情況 以及所給的命令）
RM: 從不主動 通過心跳來完成 （1NM 報活 2RM 下達命令）
??當用戶提交一個應用程序時，需要提供一個用以跟蹤和管理這個程序的AM ApplicationMaster，它負責向ResourceManager 申請資源，并要求NodeManger啟動container。
appMaster–RM–NM–container
application-specific協議（AM–yarnChild ）
am在通知nodemanager啟動container的時候container-launch-specification
由于不同的ApplicationMaster 被分布到不同的節點上，因此它們之間不會相互影響
ResourceManager全局的資源管理器，整個集群只有一個，負責集群資源的統一管理和調度分配。
功能 :處理客戶端請求runjar client獲取AM

• 啟動/監控ApplicationMaster
• RM 啟動第一個container（先啟動appmaster ）AM 再次與RM 申請資源
• 監控NodeManager （注意只能監聽容器和整臺機器的資源使用情況 不能查看具體的任務）

資源分配與調度
第一個容器在啟動（AM） container-launch-specification
容器運行 AM–yarnchild application-specific
Application Master
管理一個在YARN 內運行的應用程序的每個實例，這個應用在每個container中的進程都交給AM管理
mr在運行的時候 – 申請am — 申請子資源 — 返回容器的列表 – 機器的資源使用情況 — 節點數據
功能

• 數據切分 （找尋數據在哪個節點上，并且在這個節點上啟動container）
• 為應用程序申請資源，并進一步分配給內部任務
• 任務監控與容錯（yarnchild 宕機 appmaster能夠監聽1到 再去申請啟動）
• 負責協調來自ResourceManager的資源，幵通過NodeManager監視容器的執行和資源使用（CPU、內存等的資源分配）。

NodeManager
整個集群有多個，負責單節點資源管理和使用
功能

• 單個節點上的資源管理和任務管理（監控生命周期）
• 處理來自ResourceManager的命令（分配資源的命令）
• 處理來自ApplicationMaster的命令（啟動容器的命令）
  ApplicationManager container —> NodeManager

NodeManager管理抽象容器，這些容器代表著可供一個特定應用程序使用的針對每個節點的資源。yarnchild
定時地向RM匯報本節點上的資源使用情況和各個Container的運行狀態。(心跳機制匯報)
Container
YARN中的資源抽象，封裝某個節點上多維度資源，如內存、CPU、磁盤、網絡等，當AM向RM申請資源時，RM向AM返回的資源便是用Container表示的。
YARN 會為每個任務分配一個Container，且該任務只能使用該Container中描述的資源。
功能

• 對任務運行環境的抽象
• 描述一系列信息
• 任務運行資源（節點、內存、CPU）
• 任務啟動命令
• 任務運行環境

JobHistoryServer
??JobHistoryServer(將各個容器中的日志合并在一起展示 mr運行結果之后 進行合并結果日志的一個進程)、只是適用于mr框架，作業歷史服務,記錄歷史情況 , 通過mr-jobhistory-daemon.sh start historyserver 來啟動, 啟動成功會出現JobHistoryServer進程 , 并且可以從19888端口進行查看日志詳細信息
TimelineServer
??通用的日志服務器
??用來寫日志服務數據 , 一般來寫與第三方結合的日志服務數據(比如spark等) 所有計算框架的日志合并

7.YARN 優勢

更快地MapReduce計算
??YARN利用異步模型對MapReduce框架的一些關鍵邏輯結構（如JobInprogress、TaskInProgress等）進行了重寫，相比于MRv1，具有更快地計算速度。
對多框架支持
?? YARN不再是一個單純的計算框架，而是一個框架管理器，用戶可以將各種各樣的計算框架移植到YARN之上。
框架升級更容易
??在YARN中，各種計算框架不再是作為一個服務部署到集群的各個節點上（比如MapReduce框架，不再需要部署JobTracler、TaskTracker等服務），而是被封裝成一個用戶程序庫（lib）存放在客戶端，當需要對計算框架進行升級時，只需升級用戶程序庫即可。

8.YARN 工作流程

??當用戶向YARN中提交一個應用程序后，YARN將分兩個階段運行該應用程序

• 第一個階段是啟動ApplicationMaster；
• 第二個階段是由ApplicationMaster創建應用程序，為它申請資源，并監控它的整個運行過程，直到運行完成
• 在整個工作流程當中，ResourceManager和NodeManager都是通過心跳保持聯系的，NodeManager會通過心跳信息向ResourceManager匯報自己所在節點的資源使用情況。
  
  

9.YARN通信協議

??RPC協議是連接各個組件的“大動脈”，了解不同組件之間的RPC協議有助于我們更深人地學習YARN框架。在YARN中，任何兩個需相互通信的組件之間僅有一個RPC協議，面對于任何一個RPC協議，通信雙方有一端是Client, 另一端為Server, 且Client總是主動連接 Server的，因此，YARN實際上采用的是拉式(ull-based) 通信模型。如下圖所示，箭頭指向的組件是RPC Server, 而箭頭尾部的組件是RPC Client,
YARN主要由以下幾個RPC協議組成:
??(1)JobClient(作業提交客戶端)與RM之間的協議—ApplicationClientProtocol
JobClient通過該RPC協議提交應用程序、查詢應用程序狀態等。
??(2)Admin(管理員)與RM之間的通信協議----ResourceManagerAdministrationProtocol:
Admin通過該RPC協議更新系統配置文件，比如節點黑白名單、用戶隊列權限等。
??(3)AM與RM之間的協議一ApplicationMasterProtocol: AM通過該RPC協議向RM注冊和撒銷自己，并為各個任務申請資源。
??(4)AM與NM之間的協議一-ContainerManagementProtocol: AM通過該RPC要求NM啟動或者停止Container,獲取各個Container的使用狀態等信息。
??(5)NM與RM之間的協議一-ResuceTracker: NM通過該RPC協議向RM注冊，并定時發送心跳信息匯報當前節點的資源使用情況和Container運行情況。

10.YARN資源管理

?? 資源調度和資源隔離是YARN作為一個資源管理系統，最重要和最基礎的兩個功能。資源調度由ResourceManager完成，而資源隔離由各個NM實現。
??ResourceManager將某個NodeManager上資源分配給任務（這就是所謂的“資源調度”）后，NodeManager需按照要求為任務提供相應的資源，甚至保證這些資源應具有獨占性，為任務運行提供基礎的保證，這就是所謂的資源隔離。
??當談及到資源時，我們通常指內存，CPU和IO三種資源。Hadoop YARN同時支持內存和CPU兩種資源的調度。
??內存資源的多少會會決定任務的生死，如果內存不夠，任務可能會運行失敗；相比之下，CPU資源則不同，它只會決定任務運行的快慢，不會對生死產生影響。
??YARN允許用戶配置每個節點上可用的物理內存資源，注意，這里是“可用的”，因為一個節點上的內存會被若干個服務共享，比如一部分給YARN，一部分給HDFS，一部分給HBase等，
YARN配置的只是自己可以使用的，配置參數如下：
?? (1) yarn.nodemanager.resource.memory-mb
表示該節點上YARN可使用的物理內存總重，默認是8192(MB)，注意，如果你的節點內存資源不夠8CB,則懦要調減這個值，而YARN不會智能的探測節點的物理內存總里。
?? (2) yarn.nodemanager.vmem-pmem-ratio
任務每使用1MB物理內存，最多可使用虛擬內存里，默認是2.1.
?? (3) yarn.nodemanager.pmem-check-enabled
是否啟動一個線程檢查每個任務正使用的物理內存里，如果任務超出分配值，則直接將其殺掉，默認是true
?? (4) yarn.nodemanager.vmem-check-enabled
是否啟動一個線程檢查每個任務正使用的虛擬內存里，如果任務超出分配值，則直接將其殺掉，默認是true
?? (5) yarn.scheduler.minimum-allocation-mb
單個任務可申請的最少物理內存里，默認是1024(MB)，如果一個任務申請的物理內存重少于該值，則該對應的值改這個數。
?? (6) yarn.scheduler.maximum-allocation-mb
單個任務可申請的最多物理內存里，默認是8192(MB)。
?? 默認情況下，YARN采用了線程監控的方法判斷任務是否超量使用內存，一旦發現超量，則直接將其殺死。由于Cgroups對內存的控制缺乏靈活性（即任務任何時刻不能超過內存上限，如果超過，則直接將其殺死或者報OOM），而Java進程在創建瞬間內存將翻倍，之后驟降到正常值，這種情況下，采用線程監控的方式更加靈活（當發現進程樹內存瞬間翻倍超過設定值時，可認為是正常現象，不會將任務殺死），因此YARN未提供Cgroups內存隔離機制。
?? 目前的CPU被劃分成虛擬CPU（CPU virtual Core），這里的虛擬CPU是YARN自己引入的概念，初衷是，考慮到不同節點的CPU性能可能不同，每個CPU具有的計算能力也是不一樣的，比如某個物理CPU的計算能力可能是另外一個物理CPU的2倍，這時候，你可以通過為第一個物理CPU多配置幾個虛擬CPU彌補這種差異。用戶提交作業時，可以指定每個任務需要的虛擬CPU個數。在YARN中，CPU相關配置參數如下：
?? (1) yarn.nodemanager.resource.cpu-vcores
表示該節點上YARN可使用的虛擬CPU個數, 默認是8.注意.目前推薦將該值設為與物理CPU核數數目相同,如果你的節點CPU核數不8個,則懦要調小這個值,而YARN不會智能的探測點物理CPU總數.
?? (2) yarn.scheduler.minimum-allocation-vcores
單個任務可申請的最小虛擬cpu個數默認是1, 如果一個任務申請的CPU個數少于該數.則該對應的值改為這個數.
?? (3) yarn.scheduler.maximum-allocation-vcores
單個任務可申請的最多虛擬CPU個數,默認是32。

12、AM與RM的詳細交互

?? 用戶向YARN ResourceManager提交應用程序，RM收到提交申請后，先向資源調度器申請用以啟動AM 的資源，待申請到資源后，再由ApplicationMasterLauncher與對應的NodeManager通信，從而啟動應用程序的ApplicationMaster。
?? ApplicationMaster啟動完成后，ApplicationMasterLaucher會通過事件的形式，將剛剛啟動的Application Master注冊到AMLiveMonitor，以啟動心跳監控。
?? ApplicationMaster啟動后，先向ApplicatinMaterService注冊，并將自己所在host、端口號等信息匯報給它。
?? AM運行過程中，周期性地向ApplicationMaserService回報心跳信息（信息中包含想要申請的資源描述）。
?? ApplicationMasterService每次收到ApplicationMaster心跳信息好后，將通知AMLivelinessMonitor更新應用程序的最新回報心跳的時間。
?? 應用程序運行完成后，AM向AMService發送請求，注銷自己。
?? AMService收到注銷請求后，標注應用程序運行狀態完成，同時通知 AMLivelinessMonitor移除對它的心跳監控。

13.YARN 核心組件

14.Hadoop 發行版本

• Apache Hadoop
• Cloudera — CDH
• Hortonworks — HDP
• MapR
• EMC、IBM
• Intel、華為
• 其他

Cloudera Hadoop
?? 2008 年成立的 Cloudera 是最早將 Hadoop 商用的公司，為合作伙伴提供 Hadoop 的商用解決方案，主要是包括支持，咨詢服務，培訓。
2009年Hadoop的創始人 Doug Cutting也加盟 Cloudera公司。Cloudera 產品主要為CDH，Cloudera Manager，Cloudera Support
CDH是Cloudera的Hadoop發行版，完全開源，比Apache Hadoop在兼容性，安全性，穩定性上有所增強。
?? Cloudera Manager是集群的軟件分發及管理監控平臺，可以在幾個小時內部署好一個Hadoop集群，并對集群的節點及服務進行實時監控。Cloudera Support即是對Hadoop的技術支持。
?? Cloudera 的標價為每年每個節點4000美元。Cloudera開發并貢獻了可實時處理大數據的Impala項目。

16.Hortonworks Hadoop

?? 2011年成立的Hortonworks是雅虎與硅谷風投公司Benchmark Capital合資組建的公司
?? 公司成立之初就吸納了大約25名至30名專門研究Hadoop的雅虎工程師，上述工程師均在2005年開始協助雅虎開發Hadoop，這些工程師貢獻了Hadoop 80%的代碼。
雅虎工程副總裁、雅虎Hadoop開發團隊負責人Eric Baldeschwieler出任Hortonworks的首席執行官。
?? Hortonworks 的主打產品是Hortonworks Data Platform (HDP)，也同樣是100%開源的產品，HDP除了常見的項目外還包含了Ambari，一款開源的安裝和管理系統。
?? HCatalog，一個元數據管理系統，HCatalog現已集成到Facebook 開源的Hive中。Hortonworks的Stinger開創性地極大地優化了Hive項目。Hortonworks為入門提供了一個非常好的，易于使用的沙盒。
?? Hortonworks開發了很多增強特性并提交至核心主干，這使得Apache Hadoop能夠在包括Windows Server和Windows Azure在內的Microsoft Windows平臺上本地運行。定價以集群為基礎，每10個節點每年為12500美元。

17.MapR Hadoop

?? 2009年成立的MapR公司在Hadoop領域顯得有點特立獨行，它提供了一款獨特的發行版 。
?? Hadoop在性能(在Hadoop1.X及其之前的設計中，所有的meta data操作都要通過集中式的NameNode來進行，NameNode有可能是性能的瓶頸;M/R 應用程序需要通過NameNode來訪問HDFS, 這就涉及到額外的進程切換和網絡傳輸開銷)，可用性與擴展性(NameNode，JobTracker單點問題)，企業級應用上的弱點(比如完全可讀寫的文件系統，snapshot，mirror等等)各大廠商均知，MapR則認為，Hadoop的這些缺陷來自于其架構設計本身，小修小補不能解決問題。
?? 他們選擇了一條艱難得多的路： 用新架構重寫HDFS，同時在API級別，和目前的Hadoop 發行版保持兼容。這家2009年成立的創業公司，在蟄伏了兩年之后，終于一鳴驚人，大放異彩。
?? 成功實現了“構建一個HDFS的私有替代品，這個替代品比當前的開源版本快三倍，自帶快照功能，而且支持無NameNode單點故障(SPOF)，并且在API上和開源版兼容，所以可以考慮將其作為替代方案”。
?? MapR版本不再需要單獨的NameNode機器，元數據分散在集群中，也類似數據默認存儲三份，正如OpenStack對象存儲系統Swift的設計。
?? 也不再需要用網絡附加存儲(NAS)來協助NameNode做元數據備份，提高了機器使用率。還有個重要的特點是可以使用nfs直接訪問hdfs，提供了與舊有應用的兼容性
鏡像功能也很適合做數據備份，而且支持跨數據中心的鏡像，快照功能對于數據的恢復作用明顯。MapR還領導著Apache Drill項目，該項目是Google Dremel的開源實現，目的是在Hadoop上執行類似SQL的交互實時查詢。
?? MapR有免費和商業兩個版本，免費版本在功能上有所縮減。據報道MapR標價也為每年每個節點4000美元。

Intel和華為等發行 Hadoop
?? Intel的商業版本，主要是強調其能提供全面的軟硬件解決方案設計，針對硬件具有更好的性能優化，以及提供集群管理工具和安裝工具簡化了 Hadoop 的安裝和配置，能夠提供項目規劃到實施各階段專業的咨詢服務，實際中采購Intel版本貌似動力不足。
華為在硬件上具有天然的優勢，在網絡，虛擬化，PC機等都有很強的硬件實力。華為的 ?? FusionInsight Hadoop版本基于Apache Hadoop，構建NameNode、 JobTracker、HiveServer的HA功能，進程故障后系統自動Failover，無需人工干預，這個也是對Hadoop的小修補，遠不如MapR解決的徹底。華為在Hadoop社區中的Contributor和Committer也是國內最多的，算是國內技術實力較強的公司。
?? Microsoft和Hortonworks相互合作，特別是合作將Apache Hadoop引入到Windows Server操作系統和Windows Azure云服務中。
?? Oracle通過將自己的軟硬件與Cloudera的Apache Hadoop發行版本結合到一起，提供一個大數據應用產品。
?? 像SAP、Talend這樣的軟件提供商則同時支持幾個不同的發行版本。

總結

以上是生活随笔為你收集整理的Hadoop——分布式资源管理框架YARN总结的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。