《Hadoop大數(shù)據(jù)原理與應(yīng)用》課件4.課件-第5章統(tǒng)一資源管理和調(diào)度框架YARN(2020春)

第5章統(tǒng)一資源管理和調(diào)度框架YARN《Hadoop大數(shù)據(jù)原理與應(yīng)用》西安電子科技大學(xué)出版社【知識(shí)與能力要求】第5章統(tǒng)一資源管理和調(diào)度框架YARN5.1初識(shí)YARN5.2YARN體系架構(gòu)5.3YARN工作流程5.4實(shí)戰(zhàn)YARN5.5YARN新特性5.6其它統(tǒng)一資源管理調(diào)度框架5.1初識(shí)YARN針對(duì)MapReduce1.0在可用性、可擴(kuò)展性、資源利用率、框架支持等方面的不足，對(duì)MapReduce1.0的架構(gòu)進(jìn)行了重新設(shè)計(jì)，提出了全新的資源管理和調(diào)度框架YARN。YARN是Hadoop2.0的資源管理和調(diào)度框架，是一個(gè)通用的資源管理系統(tǒng)，在其上可以部署各種計(jì)算框架，它可為上層應(yīng)用提供統(tǒng)一的資源管理和調(diào)度，它的引入為集群高可用性、可擴(kuò)展性、資源利用率和數(shù)據(jù)共享等方面帶來了很大好處。5.1.1MapReduce1.0存在的問題在Hadoop1.0中，MapReduce采用Master/Slave架構(gòu)，有兩類守護(hù)進(jìn)程控制作業(yè)的執(zhí)行過程，即一個(gè)JobTracker和多個(gè)TaskTracker。JobTracker負(fù)責(zé)資源管理和作業(yè)調(diào)度；TaskTracker定期向JobTracker匯報(bào)本節(jié)點(diǎn)的健康狀況、資源使用情況、任務(wù)執(zhí)行情況以及接受來自JobTracker的命令并執(zhí)行。隨著集群規(guī)模負(fù)載的增加，MapReduceJobTracker在內(nèi)存消耗、擴(kuò)展性、可靠性、性能等方面暴露出各種缺點(diǎn)，具體包括以下幾個(gè)方面。（1）單點(diǎn)故障問題。JobTracker只有一個(gè)，它負(fù)責(zé)所有MapReduce作業(yè)的調(diào)度，若這個(gè)唯一的JobTracker出現(xiàn)故障就會(huì)導(dǎo)致整個(gè)集群不可用。（2）可擴(kuò)展性瓶頸。業(yè)內(nèi)普遍總結(jié)出當(dāng)節(jié)點(diǎn)數(shù)達(dá)到4000，任務(wù)數(shù)達(dá)到40000時(shí)，MapReduce1.0會(huì)遇到可擴(kuò)展性瓶頸，這是由于JobTracker“大包大攬”任務(wù)過重，既要負(fù)責(zé)作業(yè)的調(diào)度和失敗恢復(fù)，又要負(fù)責(zé)資源的管理分配。當(dāng)執(zhí)行過多的任務(wù)時(shí)，需要巨大的內(nèi)存開銷，這也潛在增加了JobTracker失敗的風(fēng)險(xiǎn)。（3）資源劃分不合理。資源（CPU、內(nèi)存）被強(qiáng)制等量劃分為多個(gè)Slot，每個(gè)TaskTracker都配置有若干固定長(zhǎng)度的Slot，這些Slot是靜態(tài)分配的，在配置的時(shí)候就被劃分為MapSlot和ReduceSlot，且MapSlot僅能用于運(yùn)行一個(gè)Map任務(wù)，ReduceSlot僅能用于運(yùn)行一個(gè)Reduce任務(wù)，彼此之間不能使用分配給對(duì)方的Slot。這意味著，當(dāng)集群中只存在單一Map任務(wù)或Reduce任務(wù)時(shí)，會(huì)造成資源的極大浪費(fèi)。（4）僅支持MapReduce一個(gè)計(jì)算框架。MapReduce是一個(gè)基于Map和Reduce、適合批處理、基于磁盤的計(jì)算框架，不能解決所有場(chǎng)景問題，而一個(gè)集群僅支持一個(gè)計(jì)算框架，不支持其他類型的計(jì)算框架如Spark、Storm等，造成集群多、管理復(fù)雜，且各個(gè)集群不能共享資源，造成集群間資源浪費(fèi)。5.1.2YARN簡(jiǎn)介為了解決MapReduce1.0存在的問題，Hadoop2.0以后版本對(duì)其核心子項(xiàng)目MapReduce的體系架構(gòu)進(jìn)行了重新設(shè)計(jì)，生成了MRv2和YARN。ApacheHadoopYARN（YetAnotherResourceNegotiator，另一種資源協(xié)調(diào)者）是Hadoop2.0的資源管理和調(diào)度框架，是一個(gè)通用資源管理系統(tǒng)，可為上層應(yīng)用提供統(tǒng)一的資源管理和調(diào)度，它的引入為集群在利用率、資源統(tǒng)一管理和數(shù)據(jù)共享等方面帶來了很大好處。5.1.2YARN簡(jiǎn)介YARN設(shè)計(jì)的基本思路就是“放權(quán)”，即不讓JobTracker承擔(dān)過多功能，把MapReduce1.0中JobTracker三大功能資源管理、任務(wù)調(diào)度和任務(wù)監(jiān)控進(jìn)行拆分，分別交給不同的新組件承擔(dān)。重新設(shè)計(jì)后得到的YARN包括ResourceManager、ApplicationMaster和NodeManager，其中，ResourceManager負(fù)責(zé)資源管理，ApplicationMaster負(fù)責(zé)任務(wù)調(diào)度和任務(wù)監(jiān)控，NodeManager負(fù)責(zé)承擔(dān)原TaskTracker功能，且原資源被劃分的Slot重新設(shè)計(jì)為容器Container，NodeManager能夠啟動(dòng)和監(jiān)控容器Container。另外，原JobTracker也負(fù)責(zé)存儲(chǔ)已完成作業(yè)的作業(yè)歷史，此功能也可以運(yùn)行一個(gè)作業(yè)歷史服務(wù)器作為一個(gè)獨(dú)立守護(hù)進(jìn)程來取代JobTracker，YARN中與之等價(jià)的角色是時(shí)間軸服務(wù)器TimelineServer。MapReduce1.0與YARN組成比較MapReduce1.0YARNJobTrackerResourceManager、ApplicationMaster、TimelineServerTaskTrackerNodeManagerSlotContainer5.1.2YARN簡(jiǎn)介總之，Hadoop1.0中，MapReduce既是一個(gè)計(jì)算框架，又是一個(gè)資源管理和調(diào)度框架，到了Hadoop2.0以后，MapReduce中資源管理和調(diào)度功能被單獨(dú)分割出來形成YARN，YARN是一個(gè)純粹的資源管理調(diào)度框架，而被剝離了資源管理調(diào)度功能的MapReduce變成了MRv2，MRv2是運(yùn)行在YARN上的一個(gè)純粹的計(jì)算框架。從MapReduce1.0發(fā)展到Y(jié)ARN，客戶端并沒有發(fā)生變化，其大部分API及接口都保持兼容，因此，原來針對(duì)Hadoop1.0開發(fā)的代碼不需做大的改動(dòng)，就可以直接放在Hadoop2.0平臺(tái)上運(yùn)行。5.1.3YARN與MapReduce1.0相比優(yōu)勢(shì)（1）可擴(kuò)展性（Scalability）與MapReduce1.0相比，YARN可以在更大規(guī)模的集群上運(yùn)行。當(dāng)節(jié)點(diǎn)數(shù)達(dá)到4000、任務(wù)數(shù)達(dá)到40000時(shí)，MapReduce1.0會(huì)遇到可擴(kuò)展性瓶頸，瓶頸來源于JobTracker負(fù)載過重，既要負(fù)責(zé)作業(yè)的調(diào)度和失敗恢復(fù)，又要負(fù)責(zé)資源的管理分配。YARN利用ResourceManager和ApplicationMaster分離的架構(gòu)優(yōu)點(diǎn)克服了這個(gè)局限性，可以擴(kuò)展到將近10000個(gè)節(jié)點(diǎn)和100000個(gè)任務(wù)。另外，YARNFederation聯(lián)邦機(jī)制進(jìn)一步增強(qiáng)了集群水平橫向擴(kuò)展性。（2）可用性（Availability）當(dāng)守護(hù)進(jìn)程失敗時(shí)，通常需要另一個(gè)守護(hù)進(jìn)程復(fù)制接管工作所需的狀態(tài)以便其繼續(xù)提供服務(wù)，從而可以獲得高可用性（HighAvailable）。但是，由于MapReduce1.0中JobTracker內(nèi)存中存在大量快速變化的復(fù)雜狀態(tài)，使得改進(jìn)JobTracker以使其獲得高可用性非常困難。YARN對(duì)MapReduce1.0的體系架構(gòu)進(jìn)行了重新設(shè)計(jì)，ResourceManager和ApplicationMaster分別承擔(dān)MapReduce1.0中JobTracker的功能，那么高可用的服務(wù)隨之稱為一個(gè)分而治之的問題：先為ResourceManager提供高可用性，再為YARN應(yīng)用提供高可用性。YARN的ResourceManagerHA特性通過Active/StandbyResourceManager保證了YARN高可用性，ResourceManagerRestart特性保證了若ResourceManager發(fā)生單點(diǎn)故障，ResourceManager能盡快自動(dòng)重啟。（3）利用率（Utilization）MapReduce1.0使用Slot表示各個(gè)節(jié)點(diǎn)上的計(jì)算資源，Slot分為MapSlot和ReduceSlot兩種，且不允許共享。對(duì)于一個(gè)作業(yè)，剛開始運(yùn)行時(shí)，MapSlot資源緊缺而ReduceSlot空閑，當(dāng)MapTask全部運(yùn)行完成后，Reduceslot緊缺而Mapslot空閑。很明顯，這種區(qū)分Slot類別的資源管理方案在一定程度上降低了Slot的利用率。同時(shí)，這種基于無類別Slot的資源劃分方法的劃分粒度過大，往往會(huì)造成節(jié)點(diǎn)資源利用率過高或者過低。YARN中，一個(gè)NodeManager管理一個(gè)資源池，而不是指定固定數(shù)目的Slot。YARN上運(yùn)行的MapReduce不會(huì)出現(xiàn)MapReduce1.0中由于集群中只有MapSlot可用而導(dǎo)致ReduceTask必須等待的情況。如果能夠獲取運(yùn)行任務(wù)的資源，那么應(yīng)用程序就會(huì)正常進(jìn)行。更進(jìn)一步，YARN中的資源是精細(xì)化管理的，這樣一個(gè)應(yīng)用程序能夠按需請(qǐng)求資源，而不是請(qǐng)求一個(gè)不可分割的、對(duì)于特定任務(wù)而言可能太大（浪費(fèi)資源）或太?。赡軐?dǎo)致失?。┑腟lot。（4）多租戶（Multitenancy）在某種程度上可以說，YARN最大的優(yōu)點(diǎn)是向MapReduce以外的其他分布式計(jì)算框架開放了Hadoop，MapReduce僅是許多YARN應(yīng)用中的一個(gè)，Spark、Tez、Storm等計(jì)算框架也都可以運(yùn)行在YARN上。另外，用戶甚至可以在同一個(gè)YARN集群上運(yùn)行不同版本的MapReduce，這使得升級(jí)MapReduce更好管理。5.1.4YARN發(fā)展目標(biāo)YARN的提出并非僅僅為了解決MapReduce1.0中存在的問題，實(shí)際上YARN有著更加偉大的目標(biāo)，即實(shí)現(xiàn)“一個(gè)集群多個(gè)框架”，也就是說在一個(gè)集群上部署一個(gè)統(tǒng)一的資源管理調(diào)度框架YARN，打造以YARN為核心的生態(tài)圈，在YARN之上可以部署其他各種計(jì)算框架，滿足一個(gè)公司各種不同的業(yè)務(wù)需求，如離線計(jì)算框架MapReduce、DAG計(jì)算框架Tez、流式計(jì)算框架Storm、內(nèi)存計(jì)算框架Spark等，由YARN為這些計(jì)算框架提供統(tǒng)一的資源管理調(diào)度服務(wù)，并且能夠根據(jù)各種計(jì)算框架的負(fù)載需求，調(diào)整各自占用的資源，實(shí)現(xiàn)集群資源共享和資源彈性收縮。HDFS2.0YARNBATCH(MapReduce)INTERACTIVE(Tez)ONLINE(HBase)STREAMING(Storm,S4…)GRAPH(Giraph)In-MEMORY(Spark)HPCMPI(OpenMPI)OTHER5.2YARN體系架構(gòu)YARN采用主從架構(gòu)（Master/Slave），其核心組件包括三個(gè)：ResourceManager、NodeManager和ApplicationMaster。其中，ResourceManager是主進(jìn)程，NodeManager是從進(jìn)程，一個(gè)ResourceManager對(duì)應(yīng)多個(gè)NodeManager，每個(gè)應(yīng)用程序擁有一個(gè)ApplicationMaster。此外，YARN中引入了一個(gè)邏輯概念——容器Container，它將各類資源（如CPU、內(nèi)存）抽象化，方便從節(jié)點(diǎn)NodeManager管理本機(jī)資源，主節(jié)點(diǎn)ResourceManager管理集群資源，如規(guī)定<1核，2G>為1個(gè)Container。5.2YARN體系架構(gòu)MapReduce狀態(tài)提交作業(yè)節(jié)點(diǎn)狀態(tài)請(qǐng)求資源

ClientClient

ResourceManagerNodeManagerContainerApplicationMaster

ApplicationMasterContainer

NodeManagerContainerContainerNodeManager5.2YARN體系架構(gòu)1.ClientClient向ResourceManager提交任務(wù)、終止任務(wù)等。2.ResourceManager整個(gè)集群只有一個(gè)ResourceManager，負(fù)責(zé)集群資源的統(tǒng)一管理和調(diào)度。具體承擔(dān)功能包括：（1）處理來自客戶端請(qǐng)求，包括啟動(dòng)/終止應(yīng)用程序。（2）啟動(dòng)/監(jiān)控ApplicationMaster，一旦某個(gè)ApplicationMaster出現(xiàn)故障，ResourceManager將會(huì)在另一個(gè)節(jié)點(diǎn)上啟動(dòng)該ApplicationMaster。（3）監(jiān)控NodeManager，接收NodeManager匯報(bào)的心跳信息并分配任務(wù)給NodeManager去執(zhí)行，一旦某個(gè)NodeManager出現(xiàn)故障，標(biāo)記該NodeManager的任務(wù)，來告訴對(duì)應(yīng)的ApplicationMaster如何處理。5.2YARN體系架構(gòu)3.NodeManager整個(gè)集群有多個(gè)NodeManager，負(fù)責(zé)單節(jié)點(diǎn)資源的管理和使用。具體承擔(dān)功能包括：（1）周期性向ResourceManager匯報(bào)本節(jié)點(diǎn)上的資源使用情況和各個(gè)Container的運(yùn)行狀態(tài)。（2）接收并處理來自ResourceManager的Container啟動(dòng)/停止的各種命令。（3）處理來自ApplicationMaster的命令。4.ApplicationMaster每個(gè)應(yīng)用程序擁有一個(gè)ApplicationMaster，負(fù)責(zé)管理應(yīng)用程序。具體承擔(dān)功能包括：（1）數(shù)據(jù)切分。（2）為應(yīng)用程序/作業(yè)向ResourceManager申請(qǐng)資源（Container），并分配給內(nèi)部任務(wù)。（3）與NodeManager通信，以啟動(dòng)/停止任務(wù)。（4）任務(wù)監(jiān)控和容錯(cuò)，在任務(wù)執(zhí)行失敗時(shí)重新為該任務(wù)申請(qǐng)資源并重啟任務(wù)。（5）接收并處理ResourceManager發(fā)出的命令，如終止Container、重啟NodeManager等。5.2YARN體系架構(gòu)5.ContainerContainer是YARN中新引入的一個(gè)邏輯概念，是YARN對(duì)資源的抽象，是YARN中最重要的概念之一。Container封裝了某個(gè)節(jié)點(diǎn)上一定量的資源（CPU和內(nèi)存兩類資源），它與LinuxContainer沒有任何關(guān)系，僅僅是YARN提出的一個(gè)概念。Container由ApplicationMaster向ResourceManager申請(qǐng)，由ResouceManager中的資源調(diào)度器異步分配給ApplicationMaster；Container的運(yùn)行是由ApplicationMaster向資源所在的NodeManager發(fā)起的，Container運(yùn)行時(shí)需提供內(nèi)部執(zhí)行的任務(wù)命令（可以是任何命令，比如Java、Python、C++進(jìn)程啟動(dòng)命令等）以及該命令執(zhí)行所需的環(huán)境變量和外部資源（比如詞典文件、可執(zhí)行文件、jar包等）。另外，一個(gè)應(yīng)用程序所需的Container分為以下兩大類：（1）運(yùn)行ApplicationMaster的Container：這是由ResourceManager和其內(nèi)部的資源調(diào)度器申請(qǐng)和啟動(dòng)的，用戶提交應(yīng)用程序時(shí)，可指定唯一的ApplicationMaster所需的資源。（2）運(yùn)行各類任務(wù)的Container：這是由ApplicationMaster向ResourceManager申請(qǐng)的，并由ApplicationMaster與NodeManager通信以啟動(dòng)之。該類Container上運(yùn)行的任務(wù)類型可以是MapTask、ReduceTask或SparkTask等。以上兩類Container可能在任意節(jié)點(diǎn)上，它們的位置通常而言是隨機(jī)的，即ApplicationMaster可能與它管理的任務(wù)運(yùn)行在一個(gè)節(jié)點(diǎn)上。5.3YARN工作流程⑧⑤④③②①Client

ResourceManager

ApplicationManagerResourceScheduler

ReduceTask②NodeManagerMRAppMaster⑤⑥MapTask⑥⑥NodeManagerMapTask⑦⑦⑦NodeManager5.3YARN工作流程①Client向YARN提交MapReduce應(yīng)用程序，提交的內(nèi)容包括ApplicationMaster程序、啟動(dòng)ApplicationMaster的命令、用戶程序等。②ResourceManager接收到Client應(yīng)用程序請(qǐng)求后，為應(yīng)用程序分配第一個(gè)Container，并與對(duì)應(yīng)的NodeManager通信，要求它在這個(gè)Container中啟動(dòng)該應(yīng)用程序的ApplicationMaster（即圖中的“MRAppMaster”）。③ApplicationMaster被創(chuàng)建后會(huì)首先向ResourceManager注冊(cè)，從而使得用戶可以直接通過ResourceManager查詢應(yīng)用程序的運(yùn)行狀態(tài)。接下來的步驟④-⑦是具體應(yīng)用程序的執(zhí)行步驟。④ApplicationMaster采用輪詢的方式通過RPC請(qǐng)求向ResourceManager申請(qǐng)資源。⑤ResourceManager以“容器Container”的形式向提出申請(qǐng)的ApplicationMaster分配資源，一旦ApplicationMaster申請(qǐng)到資源，便與對(duì)應(yīng)的NodeManager通信，要求它啟動(dòng)任務(wù)。⑥當(dāng)ApplicationMaster要求容器啟動(dòng)任務(wù)時(shí)，它會(huì)為任務(wù)設(shè)置好運(yùn)行環(huán)境，包括環(huán)境變量、JAR包、二進(jìn)制程序等，然后將任務(wù)啟動(dòng)命令寫到一個(gè)腳本中，最后NodeManager在容器中運(yùn)行該腳本以啟動(dòng)任務(wù)。⑦各個(gè)任務(wù)通過RPC協(xié)議向ApplicationMaster匯報(bào)自己的狀態(tài)和進(jìn)度，以便ApplicationMaster隨時(shí)掌握各個(gè)任務(wù)的運(yùn)行狀態(tài)，從而可以在任務(wù)失敗時(shí)重啟任務(wù)；在應(yīng)用程序運(yùn)行過程中，用戶可以隨時(shí)通過RPC向ApplicationMaster查詢應(yīng)用程序當(dāng)前運(yùn)行狀態(tài)。⑧應(yīng)用程序運(yùn)行完成后，ApplicationMaster向ResourceManager的應(yīng)用程序管理器ApplicationManager注銷并關(guān)閉自己。若ApplicationMaster因故失敗，ResourceManager中的應(yīng)用程序管理器ApplicationManager會(huì)監(jiān)測(cè)到失敗的情形，然后將其重新啟動(dòng)，直到所有的任務(wù)都執(zhí)行完畢為止。5.4實(shí)戰(zhàn)YARNYARNWebUIYARNShellYARNJavaAPI編程5.4.1YARNWebUIYARNWebUI接口面向管理員。從頁面上，管理員能看到“集群統(tǒng)計(jì)信息”、“應(yīng)用程序列表”、“調(diào)度器”等功能模塊，此頁面支持讀，不支持寫。YARNWebUI的默認(rèn)地址為http://ResourceManagerIP:8088。YARNWeb主界面——應(yīng)用程序列表效果圖YARN-App運(yùn)行中的調(diào)度器效果圖集群資源統(tǒng)計(jì)信息效果圖5.4.2YARNShellYARNShell接口面向YARN管理員。通過Shell接口，管理員能夠查看YARN系統(tǒng)級(jí)別統(tǒng)計(jì)信息，提交YARN-App等。YARNShell命令統(tǒng)一入口為：yarn，語法格式如下：yarn[--configconfdir][COMMAND|CLASSNAME]注意：若$HADOOP_HOME/bin未加入到系統(tǒng)環(huán)境變量PATH中，則需要切換到Hadoop安裝目錄下，輸入“bin/yarn”。5.4.2YARNShellUsage:yarn[--configconfdir][COMMAND|CLASSNAME]CLASSNAMEruntheclassnamedCLASSNAMEorwhereCOMMANDisoneof:resourcemanagerruntheResourceManagerUse-format-state-storefordeletingtheRMStateStore.Use-remove-application-from-state-store<appId>forremovingapplicationfromRMStateStore.nodemanagerrunanodemanageroneachslavetimelinereaderrunthetimelinereaderservertimelineserverrunthetimelineserverrmadminadmintoolsrouterruntheRouterdaemonsharedcachemanagerruntheSharedCacheManagerdaemonscmadminSharedCacheManageradmintoolsversionprinttheversionjar<jar>runajarfileapplicationprintsapplication(s)report/killapplicationapplicationattemptprintsapplicationattempt(s)reportcontainerprintscontainer(s)reportnodeprintsnodereport(s)queueprintsqueueinformationlogsdumpcontainerlogsschedulerconfupdatesschedulerconfigurationclasspathprintstheclasspathneededtogettheHadoopjarandtherequiredlibrariesclusterprintsclusterinformationdaemonlogget/settheloglevelforeachdaemontoprunclusterusagetool5.4.2YARNShellYARNShell命令分為系統(tǒng)級(jí)命令、程序級(jí)命令和其他輔助命令。本章僅介紹部分命令，關(guān)于YARNShell命令的完整說明，讀者請(qǐng)參考官方網(wǎng)站/docs/r2.9.2/hadoop-yarn/hadoop-yarn-site/YarnCommands.html。1）系統(tǒng)級(jí)命令命令選項(xiàng)功能描述rmadmin管理集群node查看集群當(dāng)前節(jié)點(diǎn)信息queue查看集群當(dāng)前隊(duì)列運(yùn)行狀況cluster查看集群信息【實(shí)例5-1】【實(shí)例5-1】查看YARN集群中當(dāng)前所有節(jié)點(diǎn)信息。首先，可以使用命令“yarnnode-help”來查看“yarnnode”的幫助信息?！緦?shí)例5-1】【實(shí)例5-1】查看YARN集群中當(dāng)前所有節(jié)點(diǎn)信息。其次，通過使用命令“yarnnode-all-list”來顯示出集群當(dāng)前所有節(jié)點(diǎn)信息。從圖中可以看出，該集群共有2個(gè)NodeManager，分別為slave1:33893和slave2:45580，都處于運(yùn)行狀態(tài)。2）程序級(jí)命令命令選項(xiàng)功能描述jar向YARN集群提交YARN-Appapplication查看YARN集群中正在運(yùn)行的YARN-Appcontainer當(dāng)YARN集群上正在運(yùn)行YARN-App時(shí)，可以使用“container”查看該YARN-App所有Container以及各Container執(zhí)行狀態(tài)【實(shí)例5-2】【實(shí)例5-2】查看某YARN-App運(yùn)行時(shí)分配的所有Container信息。首先，可以使用命令“yarncontainer-help”來查看“yarncontainer”的幫助信息?！緦?shí)例5-2】【實(shí)例5-2】查看某YARN-App運(yùn)行時(shí)分配的所有Container信息。其次，通過使用命令“yarncontainer-list<ApplicationAttemptID>”來查看某YARN-App運(yùn)行時(shí)分配的所有Container信息，運(yùn)行效果如圖5-11所示。從圖5-11中可以看出，應(yīng)用程序application_1564996260078_0002的appattempt_1564996260078_0002_000001共計(jì)分配了4個(gè)容器Container，分別為container_1564996260078_0002_01_000001~container_1564996260078_0002_01_000004，且這4個(gè)容器均在節(jié)點(diǎn)slave2:45580上。3）其他輔助命令命令選項(xiàng)功能描述version查看YARN版本classpath顯示YARN環(huán)境變量logs顯示某特定進(jìn)程日志【實(shí)例5-3】【實(shí)例5-3】查看YARN版本信息。使用命令“yarnversion”來查看YARN版本信息。5.4.3YARNJavaAPI編程YARNJavaAPI接口面向Java開發(fā)工程師。程序員可以通過該接口編寫YARN-App。YARN三大范式及其示例實(shí)現(xiàn)并行范式示例實(shí)現(xiàn)M范式DistributedShell框架M-S-R范式MapReduce框架、Spark框架BSP范式Giraph框架5.4.3YARNJavaAPI編程YARN-App三大模塊包括：（1）ApplicationBusinessLogic：應(yīng)用程序的業(yè)務(wù)邏輯模塊。（2）ApplicationClient：應(yīng)用程序客戶端，負(fù)責(zé)提交和監(jiān)管應(yīng)用程序。（3）ApplicationMaster：負(fù)責(zé)整個(gè)應(yīng)用程序的運(yùn)行，是應(yīng)用程序并行化指揮地，需要指揮所有container并行執(zhí)行ApplicationBusinessLogic。YARN-App三大模塊對(duì)應(yīng)不同范式的類YARN應(yīng)用程序標(biāo)準(zhǔn)模塊DistributedShell框架對(duì)應(yīng)類MapReduce框架對(duì)應(yīng)類Giraph框架對(duì)應(yīng)類ApplicationBussinessLogic用戶編寫的Shell命令用戶自定義Mapper類、Partition類、和Reduce類用戶自定義BasicComputation類ApplicationClientClient.javaYARNRunner.javaGiraphYarnClient.javaApplicationMasterApplicationMaster.javaMRAPPMaster.javaGiraphApplicationMaster.java5.4.3YARNJavaAPI編程YARNJavaAPI并不是本章重點(diǎn)，關(guān)于YARNAPI的詳細(xì)內(nèi)容，讀者請(qǐng)參考官方網(wǎng)站/docs/r2.9.2/api/index.html。5.5YARN新特性ResourceManagerRestart自動(dòng)重啟機(jī)制ResourceManagerHA高可用機(jī)制YARNFederation聯(lián)邦機(jī)制5.5.1ResourceManagerRestart自動(dòng)重啟機(jī)制1.ResourceManagerRestart概述在YARN體系架構(gòu)中，ResourceManager地位極其重要，它負(fù)責(zé)集群資源的統(tǒng)一管理和調(diào)度。若ResourceManager發(fā)生單點(diǎn)故障，為了減少生產(chǎn)集群中作業(yè)執(zhí)行失敗的可能性，YARN提供了新特性——ResourceManager自動(dòng)重啟，該特性保證ResourceManager能盡快自動(dòng)重啟，且重啟的過程用戶感知不到。5.5.1ResourceManagerRestart自動(dòng)重啟機(jī)制2.ResourceManagerRestart實(shí)現(xiàn)原理ResourceManager自動(dòng)重啟機(jī)制在不同版本的Hadoop中有兩種不同的實(shí)現(xiàn)，兩種實(shí)現(xiàn)的原理不同，配置相同。1）Non-work-preservingRMrestart（Hadoop2.4.0實(shí)現(xiàn)）Non-work-preservingRMrestart，即在重啟過程中任務(wù)不保留。其原理是當(dāng)Client提交一個(gè)Application給ResourceManager時(shí)，ResourceManager會(huì)將該Application的相關(guān)信息存儲(chǔ)起來，具體存儲(chǔ)位置是可以在配置文件中指定的，可以存儲(chǔ)到本地文件系統(tǒng)、HDFS或是ZooKeeper上，此外ResourceManager也會(huì)保存Application的最終狀態(tài)信息（failed，killed，finished），如果是在安全環(huán)境下運(yùn)行，ResourceManager還會(huì)保存相關(guān)證書文件。當(dāng)ResourceManager被關(guān)閉后，NodeManager和Client由于發(fā)現(xiàn)連接不上ResourceManager，會(huì)不斷向ResourceManager發(fā)送消息，以便能及時(shí)確認(rèn)ResourceManager是否已經(jīng)恢復(fù)正常，當(dāng)ResourceManager重新啟動(dòng)后，它會(huì)發(fā)送一條re-sync（重新同步）的命令給所有的NodeManager和ApplicationMaster，NodeManager收到重新同步的命令后會(huì)殺死所有的正在運(yùn)行的Containers并重新向ResourceManager注冊(cè)，從ResourceManager的角度來看，每臺(tái)重新注冊(cè)的NodeManager跟一臺(tái)新加入到集群中NodeManager是一樣的。ApplicationMaster收到重新同步的命令后會(huì)自行將自己殺掉。接下來，ResourceManager會(huì)將存儲(chǔ)的關(guān)于Application的相關(guān)信息讀取出來，并重新提交運(yùn)行在ResourceManager關(guān)閉之前最終狀態(tài)為正在運(yùn)行中的Application。5.5.1ResourceManagerRestart自動(dòng)重啟機(jī)制2.ResourceManagerRestart實(shí)現(xiàn)原理2）Work-preservingRMrestart（Hadoop2.6.0實(shí)現(xiàn)）Work-preservingRMrestart，即在重啟過程中任務(wù)是保留的。它與第一種實(shí)現(xiàn)的區(qū)別在于，ResourceManager會(huì)記錄下Container整個(gè)生命周期的數(shù)據(jù)，包括Application運(yùn)行的相關(guān)數(shù)據(jù)、資源申請(qǐng)狀況、隊(duì)列資源使用狀況等數(shù)據(jù)。如此一來，當(dāng)ResourceManager重啟之后，會(huì)讀取之前存儲(chǔ)的關(guān)于Application的運(yùn)行狀態(tài)數(shù)據(jù)，同時(shí)發(fā)送re-sync命令，與第一種方式不同的是，NodeManager在接受到重新同步的命令后并不會(huì)殺死正在運(yùn)行的Containers，而是繼續(xù)運(yùn)行Containers中的任務(wù)，同時(shí)將Containers的運(yùn)行狀態(tài)發(fā)送給ResourceManager，之后，ResourceManager根據(jù)自己所掌握的數(shù)據(jù)重構(gòu)Container實(shí)例和相關(guān)的Application運(yùn)行狀態(tài)，如此一來，就實(shí)現(xiàn)了在ResourceManager重啟之后，會(huì)緊接著ResourceManager關(guān)閉時(shí)任務(wù)的執(zhí)行狀態(tài)繼續(xù)執(zhí)行。對(duì)比以上兩種實(shí)現(xiàn)方式，第一種只保存了Application提交的信息和最終執(zhí)行狀態(tài)，并不保存運(yùn)行過程中的相關(guān)數(shù)據(jù)，所以ResourceManager重啟后，會(huì)先殺死正在執(zhí)行的任務(wù)，再重新提交，從零開始執(zhí)行任務(wù)。第二種方式則保存了Application運(yùn)行中的狀態(tài)數(shù)據(jù)，所以在ResourceManager重啟之后，不需要?dú)⑺乐暗娜蝿?wù)，而是接著原來執(zhí)行到的進(jìn)度繼續(xù)執(zhí)行。ResourceManager將應(yīng)用程序的狀態(tài)及其他驗(yàn)證信息保存到一個(gè)可插拔的狀態(tài)存儲(chǔ)中，ResourceManager重啟時(shí)從狀態(tài)存儲(chǔ)中重新加載這些信息，然后重新開始之前正在運(yùn)行的應(yīng)用程序，用戶不需要重新提交應(yīng)用程序。5.5.1ResourceManagerRestart自動(dòng)重啟機(jī)制2.ResourceManagerRestart實(shí)現(xiàn)原理2）Work-preservingRMrestart（Hadoop2.6.0實(shí)現(xiàn)）Work-preservingRMrestart，即在重啟過程中任務(wù)是保留的。它與第一種實(shí)現(xiàn)的區(qū)別在于，ResourceManager會(huì)記錄下Container整個(gè)生命周期的數(shù)據(jù)，包括Application運(yùn)行的相關(guān)數(shù)據(jù)、資源申請(qǐng)狀況、隊(duì)列資源使用狀況等數(shù)據(jù)。如此一來，當(dāng)ResourceManager重啟之后，會(huì)讀取之前存儲(chǔ)的關(guān)于Application的運(yùn)行狀態(tài)數(shù)據(jù)，同時(shí)發(fā)送re-sync命令，與第一種方式不同的是，NodeManager在接受到重新同步的命令后并不會(huì)殺死正在運(yùn)行的Containers，而是繼續(xù)運(yùn)行Containers中的任務(wù)，同時(shí)將Containers的運(yùn)行狀態(tài)發(fā)送給ResourceManager，之后，ResourceManager根據(jù)自己所掌握的數(shù)據(jù)重構(gòu)Container實(shí)例和相關(guān)的Application運(yùn)行狀態(tài)，如此一來，就實(shí)現(xiàn)了在ResourceManager重啟之后，會(huì)緊接著ResourceManager關(guān)閉時(shí)任務(wù)的執(zhí)行狀態(tài)繼續(xù)執(zhí)行。對(duì)比以上兩種實(shí)現(xiàn)方式，第一種只保存了Application提交的信息和最終執(zhí)行狀態(tài)，并不保存運(yùn)行過程中的相關(guān)數(shù)據(jù)，所以ResourceManager重啟后，會(huì)先殺死正在執(zhí)行的任務(wù)，再重新提交，從零開始執(zhí)行任務(wù)。第二種方式則保存了Application運(yùn)行中的狀態(tài)數(shù)據(jù)，所以在ResourceManager重啟之后，不需要?dú)⑺乐暗娜蝿?wù)，而是接著原來執(zhí)行到的進(jìn)度繼續(xù)執(zhí)行。ResourceManager將應(yīng)用程序的狀態(tài)及其他驗(yàn)證信息保存到一個(gè)可插拔的狀態(tài)存儲(chǔ)中，ResourceManager重啟時(shí)從狀態(tài)存儲(chǔ)中重新加載這些信息，然后重新開始之前正在運(yùn)行的應(yīng)用程序，用戶不需要重新提交應(yīng)用程序。5.5.1ResourceManagerRestart自動(dòng)重啟機(jī)制3.ResourceManagerRestart配置1）啟用ResourceManager重啟功能配置項(xiàng)“yarn.resourcemanager.recovery.enabled”的默認(rèn)值為“false”，在配置文件yarn-site.xml中添加以下內(nèi)容：<property><description>EnableRMtorecoverstateafterstarting.Iftrue,thenyarn.resourcemanager.store.classmustbespecified</description><name>yarn.resourcemanager.recovery.enabled</name><value>true</value></property>5.5.1ResourceManagerRestart自動(dòng)重啟機(jī)制3.ResourceManagerRestart配置2）配置狀態(tài)存儲(chǔ)配置項(xiàng)“yarn.resourcemanager.store.class”定義了用于狀態(tài)存儲(chǔ)的類，有三種取值：org.apache.hadoop.yarn.server.resourcemanager.recovery.ZKRMStateStore：基于ZooKeeper的狀態(tài)存儲(chǔ)實(shí)現(xiàn)。org.apache.hadoop.yarn.server.resourcemanager.recovery.FileSystemRMStateStore：基于Hadoop文件系統(tǒng)的狀態(tài)存儲(chǔ)實(shí)現(xiàn)。org.apache.hadoop.yarn.server.resourcemanager.recovery.LeveldbRMStateStore：基于LevelDB的狀態(tài)存儲(chǔ)實(shí)現(xiàn)。5.5.1ResourceManagerRestart自動(dòng)重啟機(jī)制3.ResourceManagerRestart配置2）配置狀態(tài)存儲(chǔ)默認(rèn)是“org.apache.hadoop.yarn.server.resourcemanager.recovery.FileSystemRMStateStore”，基于Hadoop文件系統(tǒng)的狀態(tài)存儲(chǔ)實(shí)現(xiàn)。例如，選用基于ZooKeeper的狀態(tài)存儲(chǔ)實(shí)現(xiàn)，在配置文件yarn-site.xml中添加以下內(nèi)容：<property><description>Theclasstouseasthepersistentstore.</description><name>yarn.resourcemanager.store.class</name><value>org.apache.hadoop.yarn.server.resourcemanager.recovery.ZKRMStateStore</value></property>5.5.1ResourceManagerRestart自動(dòng)重啟機(jī)制3.ResourceManagerRestart配置2）配置狀態(tài)存儲(chǔ)然后需要配置被ResourceManager用于狀態(tài)存儲(chǔ)的ZooKeeper服務(wù)器列表，依照在第6章部署的ZooKeeper集群，在配置文件yarn-site.xml中添加以下內(nèi)容：<property><name>yarn.resourcemanager.zk-address</name><value>30:2181,31:2181,32:2181</value></property>5.5.2ResourceManagerHA高可用機(jī)制1.ResourceManagerHA概述在YARN中，ResourceManager負(fù)責(zé)整個(gè)集群資源的管理和應(yīng)用程序的調(diào)度，Hadoop2.4之前，ResourceManager存在單點(diǎn)故障問題，一旦出現(xiàn)故障，就會(huì)影響到整個(gè)集群的正常運(yùn)行。在Hadoop2.4中，增加了Active/StandbyResourceManager，以解決ResourceManager單點(diǎn)故障問題，這就是ResourceManagerHighAvailability（ResourceManager高可用機(jī)制，簡(jiǎn)稱ResourceManagerHA）。5.5.2ResourceManagerHA高可用機(jī)制2.ResourceManagerHA體系架構(gòu)②

如果ActiveRM失效則進(jìn)行故障切換（故障切換可手工或自動(dòng)完成）①ActiveRM將其狀態(tài)寫入ZooKeeperActiveResourceManagerStandbyResourceManager

ZooKeeper集群ZooKeeperZooKeeperZooKeeper5.5.2ResourceManagerHA高可用機(jī)制3.ResourceManagerHA切換配置1）手工切換當(dāng)ActiveResourceManager發(fā)生故障時(shí)，管理員可通過命令手工切換，首先查看當(dāng)前RM狀態(tài)，然后手工切換RM，依次使用命令如下所示：yarnrmadmin-getServiceStaterm1yarnrmadmin-transitionToStandbyrm12）自動(dòng)切換通過內(nèi)嵌的基于ZooKeeper的ActiveStandbyElector來決定哪個(gè)ResourceManager處于Active狀態(tài)。當(dāng)ActiveResourceManager出現(xiàn)故障時(shí)，其他的ResourceManager將會(huì)被自動(dòng)選舉并切換成Active狀態(tài)?！緦?shí)例5-4】【實(shí)例5-4】假設(shè)某一集群共有8臺(tái)機(jī)器，每個(gè)節(jié)點(diǎn)進(jìn)程分布如下表所示。試對(duì)該集群配置ResourceManagerHA自動(dòng)切換。

master1master2master3slave1slave2slave3slave4slave5NameNode√√

DataNode

√√√√√ResourceManager√√

NodeManager

√√√√√JournalNode√√√

ZooKeeper√√√

DFSZKFailover-Controller√√

【實(shí)例5-4】首先，需要在配置文件yarn-site.xml中添加如下內(nèi)容：<!--開啟RM高可用--><property><name>yarn.resourcemanager.ha.enabled</name><value>true</value></property><!--指定RM的clusterid--><property><name>yarn.resourcemanager.cluster-id</name><value>yarn-cluster</value></property><!--指定RM的名字--><property><name>yarn.resourcemanager.ha.rm-ids</name><value>rm1,rm2</value></property>【實(shí)例5-4】<!--指定RM的地址--><property><name>yarn.resourcemanager.hostname.rm1</name><value>master1</value></property><property><name>yarn.resourcemanager.hostname.rm2</name><value>master2</value></property><property><name>yarn.resourcemanager.webapp.address.rm1</name><value>master1:8088</value></property><property><name>yarn.resourcemanager.webapp.address.rm2</name><value>master2:8088</value></property><!--指定ZooKeeper集群地址--><property><name>yarn.resourcemanager.zk-address</name><value>master1:2181,master2:2181,master3:2181</value></property><property><name>yarn.nodemanager.aux-services</name><value>mapreduce_shuffle</value></property>【實(shí)例5-4】其次需要在配置文件mapred-site.xml中添加如下內(nèi)容：<!—指定MapReduce框架為YARN方式--><property><name></name><value>yarn</value></property>5.5.3YARNFederation聯(lián)邦機(jī)制1.YARNFederation概述眾所周知，YARN可以擴(kuò)展到數(shù)千個(gè)節(jié)點(diǎn)。YARN的可伸縮性由ResourceManager確定，并且與節(jié)點(diǎn)數(shù)、活躍的應(yīng)用程序、活躍的容器和心跳頻率成比例。降低心跳可以提高可擴(kuò)展性，但對(duì)利用率有害。基于聯(lián)邦（Federation）的方法，通過聯(lián)合多個(gè)YARN子集，可以將單個(gè)YARN集群擴(kuò)展到數(shù)萬個(gè)節(jié)點(diǎn)。YARNFederation是將大的（10-100k節(jié)點(diǎn)）集群劃分成稱為子集群的較小單元，每個(gè)集群具有其自己的ResourceManager和NodeManager。聯(lián)合系統(tǒng)（FederationSystem）將這些子集群拼接在一起，使它們成為應(yīng)用程序的一個(gè)大型YARN集群。在此聯(lián)合環(huán)境中運(yùn)行的應(yīng)用程序?qū)⒖吹絾蝹€(gè)大型YARN集群，并且能夠在聯(lián)合集群的任何節(jié)點(diǎn)上計(jì)劃任務(wù)。聯(lián)合系統(tǒng)將與子集群的ResourceManager協(xié)商并為應(yīng)用程序提供資源，目標(biāo)是允許單個(gè)作業(yè)無縫地“跨越”子集群。這種設(shè)計(jì)在結(jié)構(gòu)上是可擴(kuò)展的，因?yàn)橥ㄟ^限制每個(gè)ResourceManager負(fù)責(zé)的節(jié)點(diǎn)數(shù)量，并且采用適當(dāng)?shù)牟呗詫?huì)保證大多數(shù)應(yīng)用程序駐留在單個(gè)子集群中，因此每個(gè)ResourceManager看到的應(yīng)用程序數(shù)量也是有限的。這意味著幾乎可以通過簡(jiǎn)單地添加子集來線性擴(kuò)展（因?yàn)樗鼈冎g需要很少的協(xié)調(diào)）。

RMStateStoreNMNMAMRMProxyAMRMProxyTaskAMrm1node1node2分配分配YARN子集群1

RMNMNMAMRMProxyAMRMProxyTaskrm2node3node4分配YARN子集群2路由器路由器路由器加載策略加載策略成員提交應(yīng)用程序提交應(yīng)用程序5.5.3YARNFederation聯(lián)邦機(jī)制2.YARNFederation體系架構(gòu)5.5.3YARNFederation聯(lián)邦機(jī)制2.YARNFederation體系架構(gòu)（1）YARNSub-cluster子集群。子集群是一個(gè)YARN集群，具有多達(dá)數(shù)千個(gè)節(jié)點(diǎn)。子集群的YARNResourceManager將在保持高可用性的情況下運(yùn)行，即，應(yīng)該能夠容忍YARNResourceManager、NodeManager故障。如果整個(gè)子集群遭到破壞，外部機(jī)制將確保在單獨(dú)的子集群中重新提交作業(yè)。子集群也是聯(lián)合環(huán)境中的可伸縮性單元。可以通過添加一個(gè)或多個(gè)子集群來擴(kuò)展聯(lián)合環(huán)境。（2）Router路由組件。一個(gè)Federation集群可以配置一組，但最少配置一個(gè)。用戶提交應(yīng)用時(shí)首先會(huì)訪問其中一個(gè)Router，然后Router會(huì)先從StateStore中獲得所有“SubCluster”信息（ActiveResourceManager和其他一些使用率信息），之后根據(jù)配置的路由策略（從策略存儲(chǔ)中獲?。?yīng)用程序提交請(qǐng)求轉(zhuǎn)發(fā)到對(duì)應(yīng)的ResourceManager上。（3）AMRMProxyAMRMProxy是應(yīng)用程序和多個(gè)ResourceManager通訊的橋梁。它允許一個(gè)Application可以跨子集群運(yùn)行。例如，一個(gè)Application有2000個(gè)task，這些task會(huì)分散到所有子集群上運(yùn)行，每個(gè)子集群運(yùn)行一部分。AMRMProxy運(yùn)行在所有的NodeManager機(jī)器上，它實(shí)現(xiàn)的ApplicationMasterProtocol接口作為ApplicationMaster的YARNResourceManager的代理。應(yīng)用程序不能直接與子集群的ResourceManager通信。YARN框架強(qiáng)制應(yīng)用程序只能連接到AMRMProxy，從而提供對(duì)多個(gè)YARNResourceManager（通過動(dòng)態(tài)路由/拆分/合并通信）的透明訪問。在任何時(shí)候，作業(yè)都可以跨主子集群和多個(gè)輔助子集群運(yùn)行，其中AMRMProxy的運(yùn)行策略會(huì)試圖限制每個(gè)作業(yè)的占用空間以降低調(diào)度上的開銷。（4）GlobalPolicyGenerator（GPG）全局策略生成器忽略整個(gè)聯(lián)合，并確保系統(tǒng)始終被正確的配置和調(diào)整。關(guān)鍵設(shè)計(jì)點(diǎn)是集群的可用性不依賴于永遠(yuǎn)在線的GPG。（5）FederationState-Store聯(lián)合狀態(tài)定義了需要維護(hù)的附加狀態(tài)，以便將多個(gè)單獨(dú)的子集群松散地耦合到單個(gè)大型聯(lián)合集群中。（6）FederationPolicyStore聯(lián)合策略存儲(chǔ)是一個(gè)邏輯上獨(dú)立的存儲(chǔ)，其中包含有關(guān)如何將應(yīng)用程序和資源請(qǐng)求路由到不同子集群的信息。當(dāng)前的實(shí)現(xiàn)提供了幾種策略，從隨機(jī)/散列/循環(huán)/優(yōu)先級(jí)（random/hashing/roundrobin/priority）到更復(fù)雜的策略，這些策略考慮了子集群的負(fù)載。5.5.3YARNFederation聯(lián)邦機(jī)制3.YARNFederation配置關(guān)于YARNFederation如何配置，本章不再講述，有興趣的讀者可以參考官網(wǎng)/docs/r2.9.2/hadoop-yarn/hadoop-yarn-site/Federation.html。5.6其它統(tǒng)一資源管理調(diào)度框架統(tǒng)一資源管理和調(diào)度平臺(tái)一般都具有以下特點(diǎn)：（1）支持多種計(jì)算框架統(tǒng)一資源管理和調(diào)度平臺(tái)應(yīng)該提供一個(gè)全局的資源管理器。所有接入的框架要先向該全局資源管理器申請(qǐng)資源，申請(qǐng)成功之后，再由框架自身的調(diào)度器決定資源交由哪個(gè)任務(wù)使用，也就是說，整個(gè)大的系統(tǒng)是一個(gè)雙層調(diào)度器，第一層是統(tǒng)一管理和調(diào)度平臺(tái)的調(diào)度器，另外一層是框架自身的調(diào)度器。統(tǒng)一資源管理和調(diào)度平臺(tái)應(yīng)該提供資源隔離。不同的框架中的不同任務(wù)往往需要的資源（內(nèi)存，CPU，網(wǎng)絡(luò)IO等）不同，它們運(yùn)行在同一個(gè)集群中，會(huì)相互干擾，為此，應(yīng)該提供一種資源隔離機(jī)制避免任務(wù)之間由于資源爭(zhēng)用而導(dǎo)致效率的下降。（2）擴(kuò)展性現(xiàn)有的分布式計(jì)算框架都會(huì)將系統(tǒng)擴(kuò)展性作為一個(gè)非常重要的設(shè)計(jì)目標(biāo)，比如Hadoop，好的擴(kuò)展性意味著系統(tǒng)能夠隨著業(yè)務(wù)的擴(kuò)展而線性擴(kuò)展。統(tǒng)一資源管理和調(diào)度平臺(tái)融入多種計(jì)算框架后，不應(yīng)該破壞這種特性，也就是說，統(tǒng)一管理和調(diào)度平臺(tái)不應(yīng)該制約框架進(jìn)行水平擴(kuò)展。（3）容錯(cuò)性同擴(kuò)展性類似，容錯(cuò)性也是當(dāng)前分布式計(jì)算框架的一個(gè)重要設(shè)計(jì)目標(biāo)，統(tǒng)一管理和調(diào)度平臺(tái)在保持原有框架的容錯(cuò)特性基礎(chǔ)上，自己本身也應(yīng)具有良好的容錯(cuò)性。（4）高資源利用率如果采用靜態(tài)資源分配，也就是每個(gè)計(jì)算框架分配一個(gè)集群，往往由于作業(yè)自身特點(diǎn)或者作業(yè)提交頻率等原因，造成集群利用率很低。當(dāng)將各種框架部署到同一個(gè)大的集群中，進(jìn)行統(tǒng)一管理和調(diào)度后，由于各種作業(yè)交叉且作業(yè)提交頻率大幅度升高，則為資源利用率的提升增加了機(jī)會(huì)。（5）細(xì)粒度資源分配細(xì)粒度的資源分配是指資源分配對(duì)象是任務(wù)（Task），不是作業(yè)（Job）、框架（Framework）或者應(yīng)用程序（Application）。這至少會(huì)帶來以下幾個(gè)好處：高資源利用率、高響應(yīng)時(shí)間和較好的局部性。5.6其它統(tǒng)一資源管理調(diào)度框架ApacheMesosHadoopCoronaGoogleBorg/Omega/KubernetesDockerSwarm5.6.1ApacheMesosApacheMesos誕生于UCBerkeley的一個(gè)研究項(xiàng)目，是仿Google內(nèi)部的資源管理系統(tǒng)Borg實(shí)現(xiàn)的，現(xiàn)已成為Apache的一個(gè)開源項(xiàng)目，當(dāng)前有一些公司使用Mesos管理集群資源，如國(guó)外的Twitter、Apple，國(guó)內(nèi)的豆瓣等。5.6.1ApacheMesosApacheMesos采用Master/Slave架構(gòu)，一個(gè)MesosMaster管理多個(gè)MesosAgent。其中，MesosMaster是非常輕量級(jí)的，僅保存了各種計(jì)算框架和MesosAgent的一些狀態(tài)，而這些狀態(tài)很容易通過計(jì)算框架和MesosAgent重新注冊(cè)而重構(gòu)，Mesos使用ZooKeeper解決了MesosMaster的單點(diǎn)故障問題。MesosMaster實(shí)際上是一個(gè)全局資源調(diào)度器，采用某種策略將某個(gè)MesosAgent上的空閑資源分配給某一個(gè)計(jì)算框架，各種計(jì)算框架通過自己的調(diào)度器向MesosMaster注冊(cè)，以接入到Mesos中；而MesosAgent主要功能是匯報(bào)任務(wù)的狀態(tài)和啟動(dòng)各個(gè)計(jì)算框架的執(zhí)行器（Executor）。HadoopSchedulerMPISchedulerMesosMasterStandbyMasterStandbyMaster

ZooKeeper集群ZooKeeperZooKeeperZooKeeperMesosAgent

Hadoopexecutor

taskMesosAgent

MPIexecutor

taskMesosAgent

Hadoopexecutor

MPIexecutor

tasktask5.6.2HadoopCoronaHadoopCorona是Facebook開源的下一代MapReduce框架，其基本設(shè)計(jì)動(dòng)機(jī)和Apache的YARN一致。5.6.2HadoopCoronaHadoopCorona采用Master/Slave架構(gòu)ClusterManager

CoronaTaskTrackerMapTaskMapTaskMapTaskReduceTask

CoronaTaskTrackerCoronaJobTrackerMapTaskReduceTask

CoronaTaskTrackerMapTaskReduceTaskMapTaskReduceTaskResourceRequestLauchTaskHeartbeat5.6.2HadoopCorona（1）ClusterManagerClusterManager類似于ApacheYARN中的ResourceManager，負(fù)責(zé)資源分配和調(diào)度。ClusterManager掌握著各個(gè)節(jié)點(diǎn)的資源使用情況，并將資源分配給各個(gè)作業(yè)（默認(rèn)調(diào)度器為FairScheduler）。同YARN中的ResourceManager一樣，ClusterManager是一個(gè)高度抽象的資源統(tǒng)一分配與調(diào)度框架，它不僅可以為MapReduce分配資源，也可以為其他計(jì)算框架分配資源。（2）CoronaJobTrackerCoronaJobTracker類似于YARN中的ApplicationMaster，用于作業(yè)的監(jiān)控和容錯(cuò)，它可以運(yùn)行在兩個(gè)模式下：作為JobClient，用于提交作業(yè)和方便用戶跟蹤作業(yè)運(yùn)行狀態(tài)。作為一個(gè)Task，運(yùn)行在某個(gè)TaskTracker上。與MRv1中的JobTracker不同，每個(gè)CoronaJobTracker只負(fù)責(zé)監(jiān)控一個(gè)作業(yè)。（3）CoronaTaskTrackerCoronaTaskTracker類似于YARN中的NodeManager，它的實(shí)現(xiàn)重用了MRv1中TaskTracker的很多代碼，它通過心跳將節(jié)點(diǎn)資源使用情況匯報(bào)給ClusterManager，同時(shí)會(huì)與CoronaJobTracker通信，以獲取新任務(wù)和匯報(bào)任務(wù)運(yùn)行狀態(tài)。（4）ProxyJobTrackerProxyJobTracker用于頁面展示一個(gè)作業(yè)的實(shí)際運(yùn)行信息。5.6.3GoogleBorg/Omega/Kubernetes1.BorgBorg是Google的第一代/第二代容器管理系統(tǒng)，在Google已使用和發(fā)展十多年。Borg上可以運(yùn)行成千上萬個(gè)Job，這些Job來自許多不同的應(yīng)用，并且跨多個(gè)集群，而每個(gè)集群有上萬個(gè)機(jī)器。Borg通過組合準(zhǔn)入控制、高效的任務(wù)打包、超額負(fù)載以及基于進(jìn)程級(jí)別性能隔離的機(jī)器共享，從而實(shí)現(xiàn)了高利用率。它支持高可用的應(yīng)用，其運(yùn)行時(shí)特性能夠最小化錯(cuò)誤恢復(fù)時(shí)間，其調(diào)度策略降低了相關(guān)錯(cuò)誤發(fā)生的可能性。Borg的主要用戶是Google的開發(fā)者以及運(yùn)行Google應(yīng)用和服務(wù)的系統(tǒng)管理員。Borg體系架構(gòu)

BorgMaster

read/UIShardlinkShard

Borglet

Borglet

Borglet

Borglet

調(diào)度器瀏覽器borgcfg配置文件持久存儲(chǔ)（Paxos）

命令行工具Cell5.6.3GoogleBorg/Omega/Kubernetes2.OmegaOmega是Borg的延伸。Google在2013年發(fā)表的論文中公布了它的下一代集群管理系統(tǒng)Omega的設(shè)計(jì)細(xì)節(jié)，但論文并未公布Omega的設(shè)計(jì)架構(gòu)。Google經(jīng)歷了三代資源調(diào)度器架構(gòu)，分別是中央式調(diào)度器架構(gòu)（類似于HadoopJobTracker，但是支持多種類型作業(yè)調(diào)度）、雙層調(diào)度器架構(gòu)（類似于ApacheMesos和HadoopYARN）和共享狀態(tài)架構(gòu)（Omega）。為了解決雙層調(diào)度器在全局資源視圖和并發(fā)控制方面的問題，Google提出了共享狀態(tài)調(diào)度，其典型代表就是Google下一代調(diào)度系統(tǒng)Omega。運(yùn)行在Omega之上的計(jì)算框架調(diào)度器具有全局資源視圖，具有整個(gè)集群的完全訪問權(quán)限。Omega元調(diào)度器維護(hù)著一個(gè)全局共有的集群狀態(tài)，每個(gè)調(diào)度器具有一個(gè)私有集群狀態(tài)副本。為增加系統(tǒng)的并發(fā)性，Omega采用樂觀并發(fā)控制機(jī)制。5.6.3GoogleBorg/Omega/Kubernetes3.KubernetesGoogle研發(fā)的第三個(gè)容器管理系統(tǒng)是Kubernetes（K8s），其Logo如圖5-19所示。Kubernetes是一個(gè)開源的容器集群管理系統(tǒng)，可以實(shí)現(xiàn)容器集群的自動(dòng)化部署、自動(dòng)擴(kuò)縮容、維護(hù)等功能。Kubernetes是Google于2014年創(chuàng)建管理的，是Google十多年大規(guī)模容器管理技術(shù)Borg的開源版本。Kubernetes在開發(fā)的時(shí)候非常強(qiáng)調(diào)開發(fā)者在開發(fā)集群中應(yīng)用的體驗(yàn)，它的主要目標(biāo)就是簡(jiǎn)化管理和部署復(fù)雜的分布式系統(tǒng)，同時(shí)還能受益于容器的高利用率。通過Kubernetes可以快速部署應(yīng)用、快速擴(kuò)展應(yīng)用、無縫對(duì)接新的應(yīng)用功能、節(jié)省資源及優(yōu)化硬件資源的使用。MasterNodeWorkerNode

KubeletKube-proxyDocker

Pod

ContainerContainerContainerPod

ContainerContainerContainerAPIServerControllerManager（復(fù)制，命名空間，……)Scheduler命令行工具Kubectl網(wǎng)絡(luò)WorkerNodeDocker

Pod

ContainerContainerContainerPod

ContainerContainerContainer

ETCDKubeletKube-proxyKubernetes體系架構(gòu)Kubernetes體系架構(gòu)（1）ETCDETCD是Kubernetes提供的默認(rèn)存儲(chǔ)