@[TOC]
Apache Hadoop YARN 是 apache Software Foundation Hadoop的子項目，為分離Hadoop2.0資源管理和計算組件而引入。YARN的誕生緣于存儲于HDFS的數(shù)據(jù)需要更多的交互模式，不單單是MapReduce模式。Hadoop2.0 的YARN 架構(gòu)提供了更多的處理框架，比如spark框架，不再強迫使用MapReduce框架。
從hadoop2.0 的架構(gòu)圖可以看出，YARN承擔(dān)著原本由MapReduce承擔(dān)的資源管理的功能，同時將這部分的功能打包使得他們可以被新的數(shù)據(jù)處理引擎使用。這也同時簡化了MapReduce的流程，使得MapReduce專注的將數(shù)據(jù)處理做到最好。使用YARN,可以用共同的資源管理，在Hadoop上跑很多應(yīng)用程序。目前，很多機構(gòu)已經(jīng)開發(fā)基于YARN的應(yīng)用程序。
YARN的架構(gòu)還是經(jīng)典的主從（master/slave）結(jié)構(gòu)，如下圖所示。大體上看，YARN服務(wù)由一個ResourceManager（RM）和多個NodeManager（NM）構(gòu)成，ResourceManager為主節(jié)點（master），NodeManager為從節(jié)點（slave）
在YARN體系結(jié)構(gòu)中，全局ResourceManager作為主守護程序運行，該仲裁程序在各種競爭應(yīng)用程序之間仲裁可用的群集資源。ResourceManager跟蹤群集上可用的活動節(jié)點和資源的數(shù)量，并協(xié)調(diào)用戶提交的應(yīng)用程序應(yīng)獲取這些資源的時間和時間。ResourceManager是具有此信息的單個進程，因此它可以以共享，安全和多租戶的方式進行分配（或者更確切地說，調(diào)度）決策（例如，根據(jù)應(yīng)用程序優(yōu)先級，隊列容量，ACL，數(shù)據(jù)位置等）。
當(dāng)用戶提交應(yīng)用程序時，將啟動名為ApplicationMaster的輕量級進程實例，以協(xié)調(diào)應(yīng)用程序中所有任務(wù)的執(zhí)行。這包括監(jiān)視任務(wù)，重新啟動失敗的任務(wù)，推測性地運行慢速任務(wù)以及計算應(yīng)用程序計數(shù)器的總值。這些職責(zé)先前已分配給所有工作的單個JobTracker。ApplicationMaster和屬于其應(yīng)用程序的任務(wù)在NodeManagers控制的資源容器中運行。
ApplicationMaster可以在容器內(nèi)運行任何類型的任務(wù)。例如，MapReduce ApplicationMaster請求容器啟動map或reduce任務(wù)，而Giraph ApplicationMaster請求容器運行Giraph任務(wù)。您還可以實現(xiàn)運行特定任務(wù)的自定義ApplicationMaster，并以此方式創(chuàng)建一個閃亮的新分布式應(yīng)用程序框架，該框架可以更改大數(shù)據(jù)世界。我鼓勵您閱讀Apache Twill，它旨在簡化編寫位于YARN之上的分布式應(yīng)用程序。
一個可以運行任何分布式應(yīng)用程序的集群 ResourceManager，NodeManager和容器不關(guān)心應(yīng)用程序或任務(wù)的類型。所有特定于應(yīng)用程序框架的代碼都被簡單地移動到其ApplicationMaster，以便YARN可以支持任何分布式框架，只要有人為它實現(xiàn)適當(dāng)?shù)腁pplicationMaster。由于這種通用方法，運行許多不同工作負(fù)載的Hadoop YARN集群的夢想成真。想象一下：數(shù)據(jù)中心內(nèi)的單個Hadoop集群可以運行MapReduce，Giraph，Storm，Spark，Tez / Impala，MPI等。
| 核心組件： |
組件名 | 作用 |
|---|---|---|
| ResourceManager | 相當(dāng)于這個Application的監(jiān)護人和管理者，負(fù)責(zé)監(jiān)控、管理這個Application的所有Attempt在cluster中各個節(jié)點上的具體運行，同時負(fù)責(zé)向YarnResourceManager申請資源、返還資源等； | |
| ApplicationMaster | 相當(dāng)于這個Application的監(jiān)護人和管理者，負(fù)責(zé)監(jiān)控、管理這個Application的所有Attempt在cluster中各個節(jié)點上的具體運行，同時負(fù)責(zé)向YarnResourceManager申請資源、返還資源等； | |
| NodeManager | 是Slave上一個獨立運行的進程，負(fù)責(zé)上報節(jié)點的狀態(tài)(磁盤，內(nèi)存，cpu等使用信息)； | |
| Container | 是yarn中分配資源的一個單位，包涵內(nèi)存、CPU等等資源，YARN以Container為單位分配資源； |
RM是一個全局的資源管理器，集群只有一個，負(fù)責(zé)整個系統(tǒng)的資源管理和分配，包括處理客戶端請求、啟動/監(jiān)控ApplicationMaster、監(jiān)控 NodeManager、資源的分配與調(diào)度。它主要由兩個組件構(gòu)成：調(diào)度器（Scheduler）和應(yīng)用程序管理器（Applications Manager，ASM）。
(1)調(diào)度器
調(diào)度器根據(jù)容量、隊列等限制條件（如每個隊列分配一定的資源，最多執(zhí)行一定數(shù)量的作業(yè)等），將系統(tǒng)中的資源分配給各個正在運行的應(yīng)用程序。需要注意的是，該調(diào)度器是一個“純調(diào)度器”，它從事任何與具體應(yīng)用程序相關(guān)的工作，比如不負(fù)責(zé)監(jiān)控或者跟蹤應(yīng)用的執(zhí)行狀態(tài)等，也不負(fù)責(zé)重新啟動因應(yīng)用執(zhí)行失敗或者硬件故障而產(chǎn)生的失敗任務(wù)，這些均交由應(yīng)用程序相關(guān)的ApplicationMaster完成。
調(diào)度器僅根據(jù)各個應(yīng)用程序的資源需求進行資源分配，而資源分配單位用一個抽象概念“資源容器”（ResourceContainer，簡稱Container）表示，Container是一個動態(tài)資源分配單位，它將內(nèi)存、CPU、磁盤、網(wǎng)絡(luò)等資源封裝在一起，從而限定每個任務(wù)使用的資源量。
(2)應(yīng)用程序管理器
應(yīng)用程序管理器主要負(fù)責(zé)管理整個系統(tǒng)中所有應(yīng)用程序，接收job的提交請求，為應(yīng)用分配第一個 Container 來運
行 ApplicationMaster，包括應(yīng)用程序提交、與調(diào)度器協(xié)商資源以啟動 ApplicationMaster、監(jiān)控
ApplicationMaster 運行狀態(tài)并在失敗時重新啟動它等。
管理 YARN 內(nèi)運行的一個應(yīng)用程序的每個實例。關(guān)于 job 或應(yīng)用的管理都是由 ApplicationMaster 進程負(fù)責(zé)的，Yarn 允許我們以為自己的應(yīng)用開發(fā) ApplicationMaster。
功能：
(1)數(shù)據(jù)切分；
(2)為應(yīng)用程序申請資源并進一步分配給內(nèi)部任務(wù)（TASK）；
(3)任務(wù)監(jiān)控與容錯；
負(fù)責(zé)協(xié)調(diào)來自ResourceManager的資源，并通過NodeManager監(jiān)視容易的執(zhí)行和資源使用情況。Yarn 的動態(tài)性，就是來源于多個Application 的ApplicationMaster 動態(tài)地和 ResourceManager 進行溝通，不斷地申請、釋放、再申請、再釋放資源的過程。
NodeManager 整個集群有多個，負(fù)責(zé)每個節(jié)點上的資源和使用。
NodeManager 是一個 slave 服務(wù)：它負(fù)責(zé)接收 ResourceManager 的資源分配請求，分配具體的 Container 給應(yīng)用。同時，它還負(fù)責(zé)監(jiān)控并報告 Container 使用信息給 ResourceManager。通過和ResourceManager 配合，NodeManager 負(fù)責(zé)整個 Hadoop 集群中的資源分配工作。
功能:本節(jié)點上的資源使用情況和各個 Container 的運行狀態(tài)（cpu和內(nèi)存等資源）
(1)接收及處理來自 ResourceManager 的命令請求，分配 Container 給應(yīng)用的某個任務(wù)；
(2)定時地向RM匯報以確保整個集群平穩(wěn)運行，RM 通過收集每個 NodeManager 的報告信息來追蹤整個集群健康狀態(tài)的，而 NodeManager 負(fù)責(zé)監(jiān)控自身的健康狀態(tài)；
(3)處理來自 ApplicationMaster 的請求；
(4)管理著所在節(jié)點每個 Container 的生命周期；
(5)管理每個節(jié)點上的日志；
(6)執(zhí)行 Yarn 上面應(yīng)用的一些額外的服務(wù)，比如 MapReduce 的 shuffle 過程；
當(dāng)一個節(jié)點啟動時，它會向 ResourceManager 進行注冊并告知 ResourceManager 自己有多少資源可用。在運行期，通過 NodeManager 和 ResourceManager 協(xié)同工作，這些信息會不斷被更新并保障整個集群發(fā)揮出最佳狀態(tài)。NodeManager 只負(fù)責(zé)管理自身的 Container，它并不知道運行在它上面應(yīng)用的信息。負(fù)責(zé)管理應(yīng)用信息的組件是ApplicationMaster
Container 是 YARN 中的資源抽象，它封裝了某個節(jié)點上的多維度資源，如內(nèi)存、CPU、磁盤、網(wǎng)絡(luò)等，當(dāng) AM 向RM 申請資源時，RM 為 AM 返回的資源便是用 Container 表示的。YARN 會為每個任務(wù)分配一個 Container，且任務(wù)只能使用該 Container 中描述的資源。
Container 和集群節(jié)點的關(guān)系是：一個節(jié)點會運行多個 Container，但一個 Container 不會跨節(jié)點。任何一個 job或 application 必須運行在一個或多個 Container 中，在 Yarn 框架中，ResourceManager 只負(fù)責(zé)告訴ApplicationMaster 哪些 Containers 可以用，ApplicationMaster 還需要去找 NodeManager 請求分配具體的Container。
需要注意的是，Container 是一個動態(tài)資源劃分單位，是根據(jù)應(yīng)用程序的需求動態(tài)生成的。目前為止，YARN 僅支持 CPU 和內(nèi)存兩種資源，且使用了輕量級資源隔離機制 Cgroups 進行資源隔離。
Yarn的設(shè)計目標(biāo)就是允許我們的各種應(yīng)用以共享、安全、多租戶的形式使用整個集群。并且，為了保證集群資源調(diào)度和數(shù)據(jù)訪問的高效性，Yarn還必須能夠感知整個集群拓?fù)浣Y(jié)構(gòu)。
為了實現(xiàn)這些目標(biāo)，ResourceManager的調(diào)度器Scheduler為應(yīng)用程序的資源請求定義了一些靈活的協(xié)議，通過它就可以對運行在集群中的各個應(yīng)用做更好的調(diào)度，因此，這就誕生了Resource Request和Container。一個應(yīng)用先向ApplicationMaster發(fā)送一個滿足自己需求的資源請求，然后ApplicationMaster把這個資源請求以
resource-request的形式發(fā)送給ResourceManager的Scheduler，Scheduler再在這個原始的resource-request中返回分配到的資源描述Container。每個ResourceRequest可看做一個可序列化Java對象，包含的字段信息如下：
重慶分公司
重慶分公司
作業(yè)歷史服務(wù),記錄在yarn中調(diào)度的作業(yè)歷史運行情況情況 , 通過mr-jobhistory-daemon.sh start historyserver命令在集群中的數(shù)據(jù)節(jié)點機器上不需要做任何配置,單獨使用命令啟動直接啟動即可, 啟動成功后會出現(xiàn)JobHistoryServer進程(使用jps命令查看，下面會有介紹) , 并且可以從19888端口進行查看日志詳細(xì)信息
打開如下圖界面，在下圖中點擊History，頁面會進行一次跳轉(zhuǎn)
點擊History之后 跳轉(zhuǎn)后的頁面如下圖,是空白的，這時因為我們沒有啟動jobhistoryserver所導(dǎo)致的。 在三臺機器上執(zhí)行mr-jobhistory-daemon.sh start historyserver命令依次啟動jobhistoryserver。在node1節(jié)點啟動
此時我們在三個節(jié)點把jobhistoryserver啟動后，在此運行wordcount程序(記得啟動前把輸出目錄刪除掉)
點擊History連接會跳轉(zhuǎn)一個贊新的頁面，在頁面下方會看到TaskType中列舉的map和reduce，Total表示此次運行的mapreduce程序執(zhí)行所需要的map和reduce的任務(wù)數(shù)據(jù).
用來寫日志服務(wù)數(shù)據(jù) , 一般來寫與第三方結(jié)合的日志服務(wù)數(shù)據(jù)(比如spark等),從官網(wǎng)的介紹看，它是對jobhistoryserver功能的有效補充，jobhistoryserver只能對mapreduce類型的作業(yè)信息進行記錄，除了jobhistoryserver能夠進行對作業(yè)運行過程中信息進行記錄之外還有更細(xì)粒度的信息記錄，比如任務(wù)在哪個隊列中運行，運行任務(wù)時設(shè)置的用戶是哪個用戶。根據(jù)官網(wǎng)的解釋jobhistoryserver只能記錄mapreduce應(yīng)用程序的記錄，timelineserver功能更強大,但不是替代jobhistory兩者是功能間的互補關(guān)系。
YARN 是如何工作的？ YARN的基本理念是將JobTracker/TaskTracker 兩大職能分割為以下幾個實體：
1.一個全局的資源管理ResourceManager
Application在Yarn中的執(zhí)行過程，整個執(zhí)行過程可以總結(jié)為三步：
(1)應(yīng)用程序提交
(2)啟動應(yīng)用的ApplicationMaster實例
(3)ApplicationMaster 實例管理應(yīng)用程序的執(zhí)行
具體過程：
(1)客戶端程序向 ResourceManager 提交應(yīng)用并請求一個 ApplicationMaster 實例；
(2)ResourceManager 找到一個可以運行一個 Container 的 NodeManager，并在這個 Container 中啟動ApplicationMaster 實例；
(3)ApplicationMaster 向 ResourceManager 進行注冊，注冊之后客戶端就可以查詢 ResourceManager 獲得自己 ApplicationMaster 的詳細(xì)信息，以后就可以和自己的 ApplicationMaster 直接交互了（這個時候，客戶端主動和 ApplicationMaster 交流，應(yīng)用先向 ApplicationMaster 發(fā)送一個滿足自己需求的資源請求）；
(4)在平常的操作過程中，ApplicationMaster 根據(jù) resource-request協(xié)議 向 ResourceManager 發(fā)送 resource-request請求；
(5)當(dāng) Container 被成功分配后，ApplicationMaster 通過向 NodeManager 發(fā)送 container-launch-specification信息 來啟動Container，container-launch-specification信息包含了能夠讓Container 和ApplicationMaster 交流所需要的資料；
(6)應(yīng)用程序的代碼以 task 形式在啟動的 Container 中運行，并把運行的進度、狀態(tài)等信息通過 application-specific協(xié)議 發(fā)送給ApplicationMaster；
(7)在應(yīng)用程序運行期間，提交應(yīng)用的客戶端主動和 ApplicationMaster 交流獲得應(yīng)用的運行狀態(tài)、進度更新等信息，交流協(xié)議也是 application-specific協(xié)議；
(8)一旦應(yīng)用程序執(zhí)行完成并且所有相關(guān)工作也已經(jīng)完成，ApplicationMaster 向 ResourceManager 取消注冊然后關(guān)閉，用到所有的 Container 也歸還給系統(tǒng)。
(1)客戶端提交hadoop jar
(2)找到main()方法中的job.waitForCompletition生成job對象，運行job對象的runjob()方法，與ResourceManager通信，
返回ResourceManager分配一個ID號（applicationid），需不需要輸出，如果需要輸出，判斷輸出是否存在，如果不存在問題，在看輸入，根據(jù)hdfs得到輸入得到分片信息,根據(jù)分片信息得到map個數(shù)，將這些信息回傳給客戶端Job
(3)把Job所需要的資源，例如Jar包，配置文件，split分片信息，上傳到hdfs中去
(4)Job對象告知與ResourceManager提交應(yīng)用
(5)ResourceManager尋找合適的節(jié)點開啟container容器(本質(zhì)上是一個JVM虛擬機)
(6)在container中啟動一個applicationMaster,初始化Job，生成一個薄記對象(就是一個記事本)，記錄map、reduce的狀態(tài)。把job所有資源上傳到hdfs中，包括jar包，配置文件，split信息
(7)applicationMaster向ResourceManager申請資源，返回資源信息(包括node節(jié)點地址，cpu信息，內(nèi)存占比，IO信息)
(8)applicationMaster收到信息之后，和NodeManager通信，傳遞資源信息
(9)開啟YarnChild進程,從hdfs中獲得Job詳細(xì)信息(包括Jar包,配置文件信息)
(一)Job初始化：1、當(dāng)resourceManager收到了submitApplication()方法的調(diào)用通知后，scheduler開始分配container,隨之ResouceManager發(fā)送applicationMaster進程，告知每個nodeManager管理器。 2、由applicationMaster決定如何運行tasks,如果job數(shù)據(jù)量比較小，applicationMaster便選擇將tasks運行在一個JVM中。那么如何判別這個job是大是小呢？當(dāng)一個job的mappers數(shù)量小于10個，只有一個reducer或者讀取的文件大小要小于一個HDFS block時，（可通過修改配置項mapreduce.job.ubertask.maxmaps,mapreduce.job.ubertask.maxreduces以及mapreduce.job.ubertask.maxbytes 進行調(diào)整) 3、在運行tasks之前，applicationMaster將會調(diào)用setupJob()方法，隨之創(chuàng)建output的輸出路徑(這就能夠解釋，不管你的mapreduce一開始是否報錯，輸出路徑都會創(chuàng)建)。
(二)Task 任務(wù)分配：1、接下來applicationMaster向ResourceManager請求containers用于執(zhí)行map與reduce的tasks（step 8),這里map task的優(yōu)先級要高于reduce task，當(dāng)所有的map tasks結(jié)束后，隨之進行sort(這里是shuffle過程后面再說）,最后進行reduce task的開始。(這里有一點，當(dāng)map tasks執(zhí)行了百分之5%的時候，將會請求reduce，具體下面再總結(jié)) 2、運行tasks的是需要消耗內(nèi)存與CPU資源的，默認(rèn)情況下，map和reduce的task資源分配為1024MB與一個核，（可修改運行的最小與大參數(shù)配置,mapreduce.map.memory.mb,mapreduce.reduce.memory.mb,mapreduce.map.cpu.vcores,mapreduce.reduce.reduce.cpu.vcores.)
(三)運行進度與狀態(tài)更新 1、MapReduce是一個較長運行時間的批處理過程，可以是一小時、
幾小時甚至幾天，那么Job的運行狀態(tài)監(jiān)控就非常重要。每個job以及每個task都有一個包含
job（running,successfully completed,failed）的狀態(tài)，以及value的計數(shù)器，狀態(tài)信息及描述信息（描述信息一般都是在代碼中加的打印信息），那么，這些信息是如何與客戶端進行通信的呢？ 2、當(dāng)一個task開始執(zhí)行，它將會保持運行記錄，記錄task完成的比例，對于map的任務(wù)，將會記錄其運行的百分比，對于reduce來說可能復(fù)雜點，但系統(tǒng)依舊會估計reduce的完成比例。當(dāng)一個map或reduce任務(wù)執(zhí)行時，子進程會持續(xù)每三秒鐘與applicationMaster進行交互。
mapreduce.framework.name
yarn
yarn.nodemanager.aux-services
mapreduce_shuffle
啟動 ResourceManager 和 NodeManager （以下分別簡稱RM、NM）
#主節(jié)點運行命令
$HADOOP_HOME/sbin/start-yarn.sh
#主節(jié)點運行命令
$HADOOP_HOME/sbin/stop-yarn.sh
若RM沒有啟動起來，可以單獨啟動若RM沒有啟動起來，可以單獨啟動
#若RM沒有啟動，在主節(jié)點運行命令
$HADOOP_HOME/sbin/yarn-daemon.sh start resouremanager
#相反，可單獨關(guān)閉
$HADOOP_HOME/sbin/yarn-daemon.sh stop resouremanager若NM沒有啟動起來，可以單獨啟動
#若NM沒有啟動，在相應(yīng)節(jié)點運行命令
$HADOOP_HOME/sbin/yarn-daemon.sh start nodemanager
#相反，可單獨關(guān)閉
$HADOOP_HOME/sbin/yarn-daemon.sh stop nodemanager#1.查看正在運行的任務(wù)
yarn application -list
#2.殺掉正在運行任務(wù)
yarn application -kill 任務(wù)id
#3.查看節(jié)點列表
yarn node -list
#4.查看節(jié)點狀況 TODO
yarn node -status node3:40652
#5.查看yarn依賴jar的環(huán)境變量
yarn classpath在Yarn中有三種調(diào)度器可以選擇：FIFO Scheduler ，Capacity Scheduler，F(xiàn)airS cheduler
FIFO Scheduler把應(yīng)用按提交的順序排成一個隊列，這是一個先進先出隊列，在進行資源分配的時候，先給隊列中最頭上的應(yīng)用進行分配資源，待最頭上的應(yīng)用需求滿足后再給下一個分配，以此類推。FIFO Scheduler是最簡單也是最容易理解的調(diào)度器，也不需要任何配置，但它并不適用于共享集群。大的應(yīng)用可能會占用所有集群資源，這就導(dǎo)致其它應(yīng)用被阻塞。在共享集群中，更適合采用Capacity Scheduler或FairScheduler，這兩個調(diào)度器都允許大任務(wù)和小任務(wù)在提交的同時獲得一定的系統(tǒng)資源。下面“Yarn調(diào)度器對比圖”展示了這幾個調(diào)度器的區(qū)別，從圖中可以看出，在FIFO 調(diào)度器中
而對于Capacity調(diào)度器，有一個專門的隊列用來運行小任務(wù)，但是為小任務(wù)專門設(shè)置一個隊列會預(yù)先占用一定的集
群資源，這就導(dǎo)致大任務(wù)的執(zhí)行時間會落后于使用FIFO調(diào)度器時的時間。
如何配置容量調(diào)度器
隊列層級結(jié)構(gòu)如下：
root
├── prod
└── dev
├── spark
└── hdp
HADOOP_HOME/etc/hadoop/中建立一個新的capacity-scheduler.xml；內(nèi)容如下：
yarn.scheduler.capacity.root.queues
prod,dev
yarn.scheduler.capacity.root.dev.queues
hdp,spark
yarn.scheduler.capacity.root.prod.capacity
40
yarn.scheduler.capacity.root.dev.capacity
60
yarn.scheduler.capacity.root.dev.maximum-capacity
75
yarn.scheduler.capacity.root.dev.hdp.capacity
50
yarn.scheduler.capacity.root.dev.spark.capacity
50
將應(yīng)用放置在哪個隊列中，取決于應(yīng)用本身。
例如MR，可以通過設(shè)置屬性mapreduce.job.queuename指定相應(yīng)隊列。以WordCount為例，如下，如果指定的隊列不存在，則發(fā)生錯誤。如果不指定，默認(rèn)使用"default"隊列，如下圖
在Fair調(diào)度器中，我們不需要預(yù)先占用一定的系統(tǒng)資源，F(xiàn)air調(diào)度器會為所有運行的job動態(tài)的調(diào)整系統(tǒng)資源。當(dāng)?shù)谝粋€大job提交時，只有這一個job在運行，此時它獲得了所有集群資源；當(dāng)?shù)诙€小任務(wù)提交后，F(xiàn)air調(diào)度器會分配一半資源給這個小任務(wù)，讓這兩個任務(wù)公平的共享集群資源。需要注意的是，在下圖Fair調(diào)度器中，從第二個任務(wù)提交到獲得資源會有一定的延遲，因為它需要等待第一個任務(wù)釋放占用的Container。小任務(wù)執(zhí)行完成之后也會釋放自己占用的資源，大任務(wù)又獲得了全部的系統(tǒng)資源。最終的效果就是Fair調(diào)度器即得到了高的資源利用率又能保證小任務(wù)及時完成.
