更快、更強——解析Hadoop新一代MapReduce架構Yarn-CSDN.NET http://www.csdn.net/article/2014-02-10/2818355
Yarn架構
Yarn/MRv2最基本的想法是将原JobTracker主要的資源管理和job排程/監視功能分開作為兩個單獨的守護程序。有一個全局的ResourceManager(RM)和每個Application有一個ApplicationMaster(AM)，Application相當于map-reduce job或者DAG jobs。ResourceManager和NodeManager(NM)組成了基本的資料計算架構。ResourceManager協調叢集的資源利用，任何client或者運作着的applicatitonMaster想要運作job或者task都得向RM申請一定的資源。ApplicatonMaster是一個架構特殊的庫，對于MapReduce架構而言有它自己的AM實作，使用者也可以實作自己的AM，在運作的時候，AM會與NM一起來啟動和監視tasks。
背景
Yarn是一個分布式的資源管理系統，用以提高分布式的叢集環境下的資源使用率，這些資源包括記憶體、IO、網絡、磁盤等。其産生的原因是為了解決原MapReduce架構的不足。最初MapReduce的committer們還可以周期性的在已有的代碼上進行修改，可是随着代碼的增加以及原MapReduce架構設計的不足，在原MapReduce架構上進行修改變得越來越困難，是以MapReduce的committer們決定從架構上重新設計MapReduce,使下一代的MapReduce(MRv2/Yarn)架構具有更好的擴充性、可用性、可靠性、向後相容性和更高的資源使用率以及能支援除了MapReduce計算架構外的更多的計算架構。
必須牢記yarn隻是一個資源管理的架構，并不是一個計算架構，計算架構可以運作在yarn上。
摘要：本文介紹了Hadoop 自0.23.0版本後新的MapReduce架構（Yarn)原理、優勢、運作機制和配置方法等；着重介紹新的Yarn架構相對于原架構的差異及改進。
編者按：對于業界的大資料存儲及分布式處理系統來說，Hadoop 是耳熟能詳的卓越開源分布式檔案存儲及處理架構，對于 Hadoop 架構的介紹在此不再累述，随着需求的發展，Yarn 架構浮出水面，@依然光榮複興的 部落格給我們做了很詳細的介紹，讀者通過本文中新舊 Hadoop MapReduce 架構的對比，更能深刻了解新的 yarn 架構的技術原理和設計思想。
背景
Yarn是一個分布式的資源管理系統，用以提高分布式的叢集環境下的資源使用率，這些資源包括記憶體、IO、網絡、磁盤等。其産生的原因是為了解決原MapReduce架構的不足。最初MapReduce的committer們還可以周期性的在已有的代碼上進行修改，可是随着代碼的增加以及原MapReduce架構設計的不足，在原MapReduce架構上進行修改變得越來越困難，是以MapReduce的committer們決定從架構上重新設計MapReduce,使下一代的MapReduce(MRv2/Yarn)架構具有更好的擴充性、可用性、可靠性、向後相容性和更高的資源使用率以及能支援除了MapReduce計算架構外的更多的計算架構。
原MapReduce架構的不足
JobTracker是叢集事務的集中處理點，存在單點故障
JobTracker需要完成的任務太多，既要維護job的狀态又要維護job的task的狀态，造成過多的資源消耗
在taskTracker端，用map/reduce task作為資源的表示過于簡單，沒有考慮到CPU、記憶體等資源情況，當把兩個需要消耗大記憶體的task排程到一起，很容易出現OOM
把資源強制劃分為map/reduce slot,當隻有map task時，reduce slot不能用；當隻有reduce task時，map slot不能用，容易造成資源利用不足。
Yarn架構
Yarn/MRv2最基本的想法是将原JobTracker主要的資源管理和job排程/監視功能分開作為兩個單獨的守護程序。有一個全局的ResourceManager(RM)和每個Application有一個ApplicationMaster(AM)，Application相當于map-reduce job或者DAG jobs。ResourceManager和NodeManager(NM)組成了基本的資料計算架構。ResourceManager協調叢集的資源利用，任何client或者運作着的applicatitonMaster想要運作job或者task都得向RM申請一定的資源。ApplicatonMaster是一個架構特殊的庫，對于MapReduce架構而言有它自己的AM實作，使用者也可以實作自己的AM，在運作的時候，AM會與NM一起來啟動和監視tasks。
ResourceManager
ResourceManager作為資源的協調者有兩個主要的元件：Scheduler和ApplicationsManager(AsM)。
Scheduler負責配置設定最少但滿足application運作所需的資源量給Application。Scheduler隻是基于資源的使用情況進行排程，并不負責監視/跟蹤application的狀态，當然也不會處理失敗的task。RM使用resource container概念來管理叢集的資源，resource container是資源的抽象，每個container包括一定的記憶體、IO、網絡等資源，不過目前的實作隻包括記憶體一種資源。
ApplicationsManager負責處理client送出的job以及協商第一個container以供applicationMaster運作，并且在applicationMaster失敗的時候會重新啟動applicationMaster。下面闡述RM具體完成的一些功能。
資源排程：Scheduler從所有運作着的application收到資源請求後建構一個全局的資源配置設定計劃，然後根據application特殊的限制以及全局的一些限制條件配置設定資源。
資源監視：Scheduler會周期性的接收來自NM的資源使用率的監控資訊，另外applicationMaster可以從Scheduler得到屬于它的已完成的container的狀态資訊。
Application送出：
client向AsM獲得一個applicationIDclient将application定義以及需要的jar包
client将application定義以及需要的jar封包件等上傳到hdfs的指定目錄，由yarn-site.xml的yarn.app.mapreduce.am.staging-dir指定
client構造資源請求的對象以及application的送出上下文發送給AsM
AsM接收application的送出上下文
AsM根據application的資訊向Scheduler協商一個Container供applicationMaster運作，然後啟動applicationMaster
向該container所屬的NM發送launchContainer資訊啟動該container,也即啟動applicationMaster、AsM向client提供運作着的AM的狀态資訊。
AM的生命周期：AsM負責系統中所有AM的生命周期的管理。AsM負責AM的啟動，當AM啟動後，AM會周期性的向AsM發送heartbeat，預設是1s，AsM據此了解AM的存活情況，并且在AM失敗時負責重新開機AM，若是一定時間過後(預設10分鐘)沒有收到AM的heartbeat，AsM就認為該AM失敗了。
關于ResourceManager的可用性目前還沒有很好的實作，不過Cloudera公司的CDH4.4以後的版本實作了一個簡單的高可用性，使用了Hadoop-common項目中HA部分的代碼，采用了類似hdfs namenode高可用性的設計，給RM引入了active和standby狀态，不過沒有與journalnode相對應的角色，隻是由zookeeper來負責維護RM的狀态，這樣的設計隻是一個最簡單的方案，避免了手動重新開機RM，離真正的生産可用還有一段距離。
NodeManager
NM主要負責啟動RM配置設定給AM的container以及代表AM的container，并且會監視container的運作情況。在啟動container的時候，NM會設定一些必要的環境變量以及将container運作所需的jar包、檔案等從hdfs下載下傳到本地，也就是所謂的資源本地化；當所有準備工作做好後，才會啟動代表該container的腳本将程式啟動起來。啟動起來後，NM會周期性的監視該container運作占用的資源情況，若是超過了該container所聲明的資源量，則會kill掉該container所代表的程序。
另外，NM還提供了一個簡單的服務以管理它所在機器的本地目錄。Applications可以繼續通路本地目錄即使那台機器上已經沒有了屬于它的container在運作。例如，Map-Reduce應用程式使用這個服務存儲map output并且shuffle它們給相應的reduce task。
在NM上還可以擴充自己的服務，yarn提供了一個yarn.nodemanager.aux-services的配置項，通過該配置，使用者可以自定義一些服務，例如Map-Reduce的shuffle功能就是采用這種方式實作的。
NM在本地為每個運作着的application生成如下的目錄結構：
Container目錄下的目錄結構如下：
在啟動一個container的時候，NM就執行該container的default_container_executor.sh，該腳本内部會執行launch_container.sh。launch_container.sh會先設定一些環境變量，最後啟動執行程式的指令。對于MapReduce而言，啟動AM就執行org.apache.hadoop.mapreduce.v2.app.MRAppMaster；啟動map/reduce task就執行org.apache.hadoop.mapred.YarnChild。
ApplicationMaster
ApplicationMaster是一個架構特殊的庫，對于Map-Reduce計算模型而言有它自己的ApplicationMaster實作，對于其他的想要運作在yarn上的計算模型而言，必須得實作針對該計算模型的ApplicationMaster用以向RM申請資源運作task，比如運作在yarn上的spark架構也有對應的ApplicationMaster實作，歸根結底，yarn是一個資源管理的架構，并不是一個計算架構，要想在yarn上運作應用程式，還得有特定的計算架構的實作。由于yarn是伴随着MRv2一起出現的，是以下面簡要概述MRv2在yarn上的運作流程。
MRv2運作流程：
MR JobClient向resourceManager(AsM)送出一個job
AsM向Scheduler請求一個供MR AM運作的container，然後啟動它
MR AM啟動起來後向AsM注冊
MR JobClient向AsM擷取到MR AM相關的資訊，然後直接與MR AM進行通信
MR AM計算splits并為所有的map構造資源請求
MR AM做一些必要的MR OutputCommitter的準備工作
MR AM向RM(Scheduler)發起資源請求，得到一組供map/reduce task運作的container，然後與NM一起對每一個container執行一些必要的任務，包括資源本地化等
MR AM 監視運作着的task 直到完成，當task失敗時，申請新的container運作失敗的task
當每個map/reduce task完成後，MR AM運作MR OutputCommitter的cleanup 代碼，也就是進行一些收尾工作
當所有的map/reduce完成後，MR AM運作OutputCommitter的必要的job commit或者abort APIs
MR AM退出。
在Yarn上寫應用程式
在yarn上寫應用程式并不同于我們熟知的MapReduce應用程式，必須牢記yarn隻是一個資源管理的架構，并不是一個計算架構，計算架構可以運作在yarn上。我們所能做的就是向RM申請container,然後配合NM一起來啟動container。就像MRv2一樣，jobclient請求用于MR AM運作的container，設定環境變量和啟動指令，然後交由NM去啟動MR AM，随後map/reduce task就由MR AM全權負責，當然task的啟動也是由MR AM向RM申請container，然後配合NM一起來啟動的。是以要想在yarn上運作非特定計算架構的程式，我們就得實作自己的client和applicationMaster。另外我們自定義的AM需要放在各個NM的classpath下，因為AM可能運作在任何NM所在的機器上。
作者：葡萄喃喃呓語
連結：https://www.jianshu.com/p/69e1424ee0a1