一油航、Yarn簡介
Yarn是Hadoop集群的資源管理系統(tǒng)备闲。Hadoop2.0對MapReduce框架做了徹底的設(shè)計重構(gòu)晤柄，我們稱Hadoop2.0中的MapReduce為MRv2或者Yarn傍念。 它的目標(biāo)是將這兩部分功能分開围辙，也就是分別用兩個進(jìn)程來管理這兩個任務(wù)：
1. ResourceManger
2. ApplicationMaster
需要注意的是，在Yarn中我們把job的概念換成了application夺鲜，因?yàn)樵谛碌腍adoop2.x中皆尔，運(yùn)行的應(yīng)用不只是MapReduce了，還有可能是其它應(yīng)用如一個DAG（有向無環(huán)圖Directed Acyclic Graph币励，例如storm應(yīng)用）慷蠕。Yarn的另一個目標(biāo)就是拓展Hadoop，使得它不僅僅可以支持MapReduce計算食呻，還能很方便的管理諸如Hive流炕、Hbase、Pig仅胞、Spark/Shark等應(yīng)用每辟。這種新的架構(gòu)設(shè)計能夠使得各種類型的應(yīng)用運(yùn)行在Hadoop上面，并通過Yarn從系統(tǒng)層面進(jìn)行統(tǒng)一的管理干旧，也就是說渠欺，有了Yarn，各種應(yīng)用就可以互不干擾的運(yùn)行在同一個Hadoop系統(tǒng)中椎眯，共享整個集群資源挠将，如下圖所示：?
Yarn主要由以下幾個組件組成：
1. ResourceManager：Global（全局）的進(jìn)程
2. NodeManager：運(yùn)行在每個節(jié)點(diǎn)上的進(jìn)程
3. ApplicationMaster：Application-specific（應(yīng)用級別）的進(jìn)程
- *Scheduler：是ResourceManager的一個組件*
- *Container：節(jié)點(diǎn)上一組CPU和內(nèi)存資源*
Container是Yarn對計算機(jī)計算資源的抽象编整，它其實(shí)就是一組CPU和內(nèi)存資源舔稀，所有的應(yīng)用都會運(yùn)行在Container中。ApplicationMaster是對運(yùn)行在Yarn中某個應(yīng)用的抽象掌测，它其實(shí)就是某個類型應(yīng)用的實(shí)例镶蹋，ApplicationMaster是應(yīng)用級別的，它的主要功能就是向ResourceManager（全局的）申請計算資源（Containers）并且和NodeManager交互來執(zhí)行和監(jiān)控具體的task赏半。Scheduler是ResourceManager專門進(jìn)行資源管理的一個組件昼弟，負(fù)責(zé)分配NodeManager上的Container資源汇四，NodeManager也會不斷發(fā)送自己Container使用情況給ResourceManager。
ResourceManager和NodeManager兩個進(jìn)程主要負(fù)責(zé)系統(tǒng)管理方面的任務(wù)澳淑。ResourceManager有一個Scheduler秋冰，負(fù)責(zé)各個集群中應(yīng)用的資源分配仲义。對于每種類型的每個應(yīng)用，都會對應(yīng)一個ApplicationMaster實(shí)例，ApplicationMaster通過和ResourceManager溝通獲得Container資源來運(yùn)行具體的job埃撵，并跟蹤這個job的運(yùn)行狀態(tài)赵颅、監(jiān)控運(yùn)行進(jìn)度。
下面我們看一下整個Yarn的架構(gòu)圖：?
Container是Yarn框架的計算單元饺谬，是具體執(zhí)行應(yīng)用task（如map task、reduce task）的基本單位谣拣。Container和集群節(jié)點(diǎn)的關(guān)系是：一個節(jié)點(diǎn)會運(yùn)行多個Container募寨，但一個Container不會跨節(jié)點(diǎn)。
一個Container就是一組分配的系統(tǒng)資源森缠，現(xiàn)階段只包含兩種系統(tǒng)資源（之后可能會增加磁盤拔鹰、網(wǎng)絡(luò)等資源）：
1. CPU core
2. Memory in MB
既然一個Container指的是具體節(jié)點(diǎn)上的計算資源，這就意味著Container中必定含有計算資源的位置信息：計算資源位于哪個機(jī)架的哪臺機(jī)器上贵涵。所以我們在請求某個Container時列肢，其實(shí)是向某臺機(jī)器發(fā)起的請求，請求的是這臺機(jī)器上的CPU和內(nèi)存資源宾茂。
任何一個job或application必須運(yùn)行在一個或多個Container中瓷马，在Yarn框架中，ResourceManager只負(fù)責(zé)告訴ApplicationMaster哪些Containers可以用刻炒，ApplicationMaster還需要去找NodeManager請求分配具體的Container决采。
NodeManager進(jìn)程運(yùn)行在集群中的節(jié)點(diǎn)上，每個節(jié)點(diǎn)都會有自己的NodeManager坟奥。NodeManager是一個slave服務(wù)：它負(fù)責(zé)接收ResourceManager的資源分配請求树瞭，分配具體的Container給應(yīng)用。同時爱谁，它還負(fù)責(zé)監(jiān)控并報告Container使用信息給ResourceManager晒喷。通過和ResourceManager配合，NodeManager負(fù)責(zé)整個Hadoop集群中的資源分配工作访敌。ResourceManager是一個全局的進(jìn)程凉敲，而NodeManager只是每個節(jié)點(diǎn)上的進(jìn)程，管理這個節(jié)點(diǎn)上的資源分配和監(jiān)控運(yùn)行節(jié)點(diǎn)的健康狀態(tài)寺旺。下面是NodeManager的具體任務(wù)列表：
- 接收ResourceManager的請求爷抓，分配Container給應(yīng)用的某個任務(wù)
- 和ResourceManager交換信息以確保整個集群平穩(wěn)運(yùn)行。ResourceManager就是通過收集每個NodeManager的報告信息來追蹤整個集群健康狀態(tài)的阻塑，而NodeManager負(fù)責(zé)監(jiān)控自身的健康狀態(tài)蓝撇。
- 管理每個Container的生命周期
- 管理每個節(jié)點(diǎn)上的日志
- 執(zhí)行Yarn上面應(yīng)用的一些額外的服務(wù)，比如MapReduce的shuffle過程
當(dāng)一個節(jié)點(diǎn)啟動時陈莽，它會向ResourceManager進(jìn)行注冊并告知ResourceManager自己有多少資源可用渤昌。在運(yùn)行期虽抄，通過NodeManager和ResourceManager協(xié)同工作，這些信息會不斷被更新并保障整個集群發(fā)揮出最佳狀態(tài)独柑。
NodeManager只負(fù)責(zé)管理自身的Container迈窟，它并不知道運(yùn)行在它上面應(yīng)用的信息。負(fù)責(zé)管理應(yīng)用信息的組件是ApplicationMaster忌栅，在后面會講到车酣。
ResourceManager主要有兩個組件：Scheduler和ApplicationManager。
Scheduler是一個資源調(diào)度器狂秘，它主要負(fù)責(zé)協(xié)調(diào)集群中各個應(yīng)用的資源分配骇径，保障整個集群的運(yùn)行效率。Scheduler的角色是一個純調(diào)度器者春，它只負(fù)責(zé)調(diào)度Containers破衔，不會關(guān)心應(yīng)用程序監(jiān)控及其運(yùn)行狀態(tài)等信息。同樣钱烟，它也不能重啟因應(yīng)用失敗或者硬件錯誤而運(yùn)行失敗的任務(wù)
Scheduler是一個可插拔的插件晰筛，它可以調(diào)度集群中的各種隊列、應(yīng)用等拴袭。在Hadoop的MapReduce框架中主要有兩種Scheduler：Capacity Scheduler和Fair Scheduler读第，關(guān)于這兩個調(diào)度器后面會詳細(xì)介紹。
另一個組件ApplicationManager主要負(fù)責(zé)接收job的提交請求拥刻，為應(yīng)用分配第一個Container來運(yùn)行ApplicationMaster怜瞒，還有就是負(fù)責(zé)監(jiān)控ApplicationMaster，在遇到失敗時重啟ApplicationMaster運(yùn)行的Container般哼。
ApplicationMaster的主要作用是向ResourceManager申請資源并和NodeManager協(xié)同工作來運(yùn)行應(yīng)用的各個任務(wù)然后跟蹤它們狀態(tài)及監(jiān)控各個任務(wù)的執(zhí)行吴汪，遇到失敗的任務(wù)還負(fù)責(zé)重啟它。
在MR1中蒸眠，JobTracker即負(fù)責(zé)job的監(jiān)控漾橙，又負(fù)責(zé)系統(tǒng)資源的分配。而在MR2中楞卡，資源的調(diào)度分配由ResourceManager專門進(jìn)行管理霜运，而每個job或應(yīng)用的管理、監(jiān)控交由相應(yīng)的分布在集群中的ApplicationMaster蒋腮，如果某個ApplicationMaster失敗淘捡，ResourceManager還可以重啟它，這大大提高了集群的拓展性池摧。
在MR1中案淋，Hadoop架構(gòu)只支持MapReduce類型的job，所以它不是一個通用的框架险绘，因?yàn)镠adoop的JobTracker和TaskTracker組件都是專門針對MapReduce開發(fā)的踢京，它們之間是深度耦合的。Yarn的出現(xiàn)解決了這個問題宦棺，關(guān)于Job或應(yīng)用的管理都是由ApplicationMaster進(jìn)程負(fù)責(zé)的瓣距，Yarn允許我們自己開發(fā)ApplicationMaster，我們可以為自己的應(yīng)用開發(fā)自己的ApplicationMaster代咸。這樣每一個類型的應(yīng)用都會對應(yīng)一個ApplicationMaster蹈丸，一個ApplicationMaster其實(shí)就是一個類庫。這里要區(qū)分ApplicationMaster*類庫和ApplicationMaster實(shí)例*呐芥，一個ApplicationMaster類庫何以對應(yīng)多個實(shí)例逻杖，就行java語言中的類和類的實(shí)例關(guān)系一樣∷嘉粒總結(jié)來說就是荸百，每種類型的應(yīng)用都會對應(yīng)著一個ApplicationMaster，每個類型的應(yīng)用都可以啟動多個ApplicationMaster實(shí)例滨攻。所以够话，在yarn中，是每個job都會對應(yīng)一個ApplicationMaster而不是每類光绕。
Yarn 框架相對于老的 MapReduce 框架什么優(yōu)勢呢女嘲？
- 這個設(shè)計大大減小了 ResourceManager 的資源消耗，并且讓監(jiān)測每一個 Job 子任務(wù) (tasks) 狀態(tài)的程序分布式化了诞帐，更安全欣尼、更優(yōu)美。
- 在新的 Yarn 中停蕉，ApplicationMaster 是一個可變更的部分愕鼓，用戶可以對不同的編程模型寫自己的 AppMst，讓更多類型的編程模型能夠跑在 Hadoop 集群中谷徙，可以參考 hadoop Yarn 官方配置模板中的 ``mapred-site.xml`` 配置拒啰。
- 對于資源的表示以內(nèi)存為單位 ( 在目前版本的 Yarn 中，沒有考慮 cpu 的占用 )完慧，比之前以剩余 slot 數(shù)目更合理谋旦。
- 老的框架中，JobTracker 一個很大的負(fù)擔(dān)就是監(jiān)控 job 下的 tasks 的運(yùn)行狀況屈尼，現(xiàn)在册着，這個部分就扔給 ApplicationMaster 做了，而 ResourceManager 中有一個模塊叫做 ApplicationsManager脾歧，它是監(jiān)測 ApplicationMaster 的運(yùn)行狀況甲捏，如果出問題，會將其在其他機(jī)器上重啟鞭执。
- Container 是 Yarn 為了將來作資源隔離而提出的一個框架司顿。這一點(diǎn)應(yīng)該借鑒了 Mesos 的工作芒粹，目前是一個框架，僅僅提供 java 虛擬機(jī)內(nèi)存的隔離 ,hadoop 團(tuán)隊的設(shè)計思路應(yīng)該后續(xù)能支持更多的資源調(diào)度和控制 , 既然資源表示成內(nèi)存量大溜，那就沒有了之前的 map slot/reduce slot 分開造成集群資源閑置的尷尬情況化漆。
了解了上面介紹的這些概念钦奋，我們有必要看一下Application在Yarn中的執(zhí)行過程座云，整個執(zhí)行過程可以總結(jié)為三步：
1. 應(yīng)用程序提交
2. 啟動應(yīng)用的ApplicationMaster實(shí)例
3. ApplicationMaster實(shí)例管理應(yīng)用程序的執(zhí)行
下面這幅圖展示了應(yīng)用程序的整個執(zhí)行過程：
客戶端程序向ResourceManager提交應(yīng)用并請求一個ApplicationMaster實(shí)例
ResourceManager找到可以運(yùn)行一個Container的NodeManager，并在這個Container中啟動ApplicationMaster實(shí)例
ApplicationMaster向ResourceManager進(jìn)行注冊付材，注冊之后客戶端就可以查詢ResourceManager獲得自己ApplicationMaster的詳細(xì)信息朦拖，以后就可以和自己的ApplicationMaster直接交互了
在平常的操作過程中，ApplicationMaster根據(jù)resource-request協(xié)議向ResourceManager發(fā)送resource-request請求
當(dāng)Container被成功分配之后厌衔，ApplicationMaster通過向NodeManager發(fā)送container-launch-specification信息來啟動Container璧帝， container-launch-specification信息包含了能夠讓Container和ApplicationMaster交流所需要的資料
應(yīng)用程序的代碼在啟動的Container中運(yùn)行，并把運(yùn)行的進(jìn)度葵诈、狀態(tài)等信息通過application-specific協(xié)議發(fā)送給ApplicationMaster
在應(yīng)用程序運(yùn)行期間裸弦，提交應(yīng)用的客戶端主動和ApplicationMaster交流獲得應(yīng)用的運(yùn)行狀態(tài)、進(jìn)度更新等信息作喘，交流的協(xié)議也是application-specific協(xié)議
一但應(yīng)用程序執(zhí)行完成并且所有相關(guān)工作也已經(jīng)完成理疙，ApplicationMaster向ResourceManager取消注冊然后關(guān)閉，用到所有的Container也歸還給系統(tǒng)
4.2 Resource Request和Container
Yarn的設(shè)計目標(biāo)就是允許我們的各種應(yīng)用以共享泞坦、安全窖贤、多租戶的形式使用整個集群。并且贰锁，為了保證集群資源調(diào)度和數(shù)據(jù)訪問的高效性赃梧，Yarn還必須能夠感知整個集群拓?fù)浣Y(jié)構(gòu)。為了實(shí)現(xiàn)這些目標(biāo)豌熄，ResourceManager的調(diào)度器Scheduler為應(yīng)用程序的資源請求定義了一些靈活的協(xié)議授嘀，通過它就可以對運(yùn)行在集群中的各個應(yīng)用做更好的調(diào)度，因此锣险，這就誕生了Resource Request和Container蹄皱。
具體來講，一個應(yīng)用先向ApplicationMaster發(fā)送一個滿足自己需求的資源請求芯肤，然后ApplicationMaster把這個資源請求以resource-request的形式發(fā)送給ResourceManager的Scheduler巷折，Scheduler再在這個原始的resource-request中返回分配到的資源描述Container。每個ResourceRequest可看做一個可序列化Java對象崖咨，包含的字段信息如下：
resource-name：資源名稱锻拘，現(xiàn)階段指的是資源所在的host和rack，后期可能還會支持虛擬機(jī)或者更復(fù)雜的網(wǎng)絡(luò)結(jié)構(gòu)
priority：資源的優(yōu)先級
resource-requirement：資源的具體需求击蹲，現(xiàn)階段指內(nèi)存和cpu需求的數(shù)量
number-of-containers：滿足需求的Container的集合
number-of-containers中的Containers就是ResourceManager給ApplicationMaster分配資源的結(jié)果署拟。Container就是授權(quán)給應(yīng)用程序可以使用某個節(jié)點(diǎn)機(jī)器上CPU和內(nèi)存的數(shù)量婉宰。
ApplicationMaster在得到這些Containers后，還需要與分配Container所在機(jī)器上的NodeManager交互來啟動Container并運(yùn)行相關(guān)任務(wù)芯丧。當(dāng)然Container的分配是需要認(rèn)證的芍阎，以防止ApplicationMaster自己去請求集群資源。
