???YARN的架構(gòu)還是經(jīng)典的主從（master/slave）結(jié)構(gòu)，如下圖所示。大體上看，YARN服務(wù)由一個ResourceManager（RM）和多個NodeManager（NM）構(gòu)成，ResourceManager為主節(jié)點(diǎn)（master），NodeManager為從節(jié)點(diǎn)（slave）
核心組件：
| 組件名 | 作用 |
|---|---|
| ResourceManager | 相當(dāng)于這個Application的監(jiān)護(hù)人和管理者，負(fù)責(zé)監(jiān)控、管理這個Application的所有Attempt在cluster中各個節(jié)點(diǎn)上的具體運(yùn)行，同時負(fù)責(zé)向YarnResourceManager申請資源、返還資源等； |
| ApplicationMaster | 相當(dāng)于這個Application的監(jiān)護(hù)人和管理者，負(fù)責(zé)監(jiān)控、管理這個Application的所有Attempt在cluster中各個節(jié)點(diǎn)上的具體運(yùn)行，同時負(fù)責(zé)向YarnResourceManager申請資源、返還資源等； |
| NodeManager | 是Slave上一個獨(dú)立運(yùn)行的進(jìn)程，負(fù)責(zé)上報節(jié)點(diǎn)的狀態(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ùn)行的應(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)用程序的資源需求進(jìn)行資源分配，而資源分配單位用一個抽象概念“資源容器”（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 來運(yùn)行 ApplicationMaster，包括應(yīng)用程序提交、與調(diào)度器協(xié)商資源以啟動 ApplicationMaster、監(jiān)控ApplicationMaster 運(yùn)行狀態(tài)并在失敗時重新啟動它等。
???管理 YARN 內(nèi)運(yùn)行的一個應(yīng)用程序的每個實(shí)例。關(guān)于 job 或應(yīng)用的管理都是由 ApplicationMaster 進(jìn)程負(fù)責(zé)的，Yarn 允許我們以為自己的應(yīng)用開發(fā) ApplicationMaster。
???功能：
???(1)數(shù)據(jù)切分；
???(2)為應(yīng)用程序申請資源并進(jìn)一步分配給內(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 進(jìn)行溝通，不斷地申請、釋放、再申請、再釋放資源的過程。
???NodeManager 整個集群有多個，負(fù)責(zé)每個節(jié)點(diǎn)上的資源和使用。
???NodeManager 是一個 slave 服務(wù)：它負(fù)責(zé)接收 ResourceManager 的資源分配請求，分配具體的 Container 給應(yīng)用。同時，它還負(fù)責(zé)監(jiān)控并報告 Container 使用信息給 ResourceManager。通過和ResourceManager 配合，NodeManager 負(fù)責(zé)整個 Hadoop 集群中的資源分配工作。
???功能:本節(jié)點(diǎn)上的資源使用情況和各個 Container 的運(yùn)行狀態(tài)（cpu和內(nèi)存等資源）
???(1)接收及處理來自 ResourceManager 的命令請求，分配 Container 給應(yīng)用的某個任務(wù)；
???(2)定時地向RM匯報以確保整個集群平穩(wěn)運(yùn)行，RM 通過收集每個 NodeManager 的報告信息來追蹤整個集群健康狀態(tài)的，而 NodeManager 負(fù)責(zé)監(jiān)控自身的健康狀態(tài)；
???(3)處理來自 ApplicationMaster 的請求；
???(4)管理著所在節(jié)點(diǎn)每個 Container 的生命周期；
???(5)管理每個節(jié)點(diǎn)上的日志；
???(6)執(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
???Container 是 YARN 中的資源抽象，它封裝了某個節(jié)點(diǎn)上的多維度資源，如內(nèi)存、CPU、磁盤、網(wǎng)絡(luò)等，當(dāng) AM 向RM 申請資源時，RM 為 AM 返回的資源便是用 Container 表示的。YARN 會為每個任務(wù)分配一個 Container，且任務(wù)只能使用該 Container 中描述的資源。
???Container 和集群節(jié)點(diǎn)的關(guān)系是：一個節(jié)點(diǎn)會運(yùn)行多個 Container，但一個 Container 不會跨節(jié)點(diǎn)。任何一個 job或 application 必須運(yùn)行在一個或多個 Container 中，在 Yarn 框架中，ResourceManager 只負(fù)責(zé)告訴ApplicationMaster 哪些 Containers 可以用，ApplicationMaster 還需要去找 NodeManager 請求分配具體的Container。
???需要注意的是，Container 是一個動態(tài)資源劃分單位，是根據(jù)應(yīng)用程序的需求動態(tài)生成的。目前為止，YARN 僅支持 CPU 和內(nèi)存兩種資源，且使用了輕量級資源隔離機(jī)制 Cgroups 進(jìn)行資源隔離。
???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的集合
-->
<resource-name, priority, resource-requirement, number-of-containers>
???作業(yè)歷史服務(wù),記錄在yarn中調(diào)度的作業(yè)歷史運(yùn)行情況情況 , 通過mr-jobhistory-daemon.sh start historyserver命令在集群中的數(shù)據(jù)節(jié)點(diǎn)機(jī)器上不需要做任何配置,單獨(dú)使用命令啟動直接啟動即可, 啟動成功后會出現(xiàn)JobHistoryServer進(jìn)程(使用jps命令查看，下面會有介紹) , 并且可以從19888端口進(jìn)行查看日志詳細(xì)信息
???用來寫日志服務(wù)數(shù)據(jù) , 一般來寫與第三方結(jié)合的日志服務(wù)數(shù)據(jù)(比如spark等),從官網(wǎng)的介紹看，它是對jobhistoryserver功能的有效補(bǔ)充，jobhistoryserver只能對mapreduce類型的作業(yè)信息進(jìn)行記錄，除了jobhistoryserver能夠進(jìn)行對作業(yè)運(yùn)行過程中信息進(jìn)行記錄之外還有更細(xì)粒度的信息記錄，比如任務(wù)在哪個隊列中運(yùn)行，運(yùn)行任務(wù)時設(shè)置的用戶是哪個用戶。根據(jù)官網(wǎng)的解釋jobhistoryserver只能記錄mapreduce應(yīng)用程序的記錄，timelineserver功能更強(qiáng)大,但不是替代jobhistory兩者是功能間的互補(bǔ)關(guān)系。
???YARN 是如何工作的？ YARN的基本理念是將JobTracker/TaskTracker 兩大職能分割為以下幾個實(shí)體：
1.一個全局的資源管理ResourceManager
2. 每個應(yīng)用程序一個ApplicationMaster
3. 每個從節(jié)點(diǎn)一個NodeManager
4. 每個應(yīng)用程序一個運(yùn)行在NodeManager上的Container
???ResouceManager 和 NodeManager 組成了一個新的、通用的、用分布式管理應(yīng)用程序的系統(tǒng)。ResourceManager 對系統(tǒng)中的應(yīng)用程序資源有終極仲裁的權(quán)限。ApplicationMaster 是一個特定于框架的實(shí)體，它的責(zé)任是同ResourceManager 談判資源 ，同時為NodeManager(s)執(zhí)行和監(jiān)控組件任務(wù)。RessourceManager有一個調(diào)度器，根據(jù)不同的約束條件，例如隊列容量、用戶限制等，將資源進(jìn)行分配給各類運(yùn)行著的應(yīng)用程序。調(diào)度器執(zhí)行調(diào)度功能是基于應(yīng)用程序的資源申請。NodeManager 負(fù)責(zé)發(fā)布應(yīng)用程序容器，監(jiān)控資源的使用并向ResourceManager進(jìn)行匯報。每個ApplicationMaster都有職責(zé)從調(diào)度器那談判得到適當(dāng)?shù)馁Y源容器，追蹤它們的狀態(tài)，并監(jiān)控他們的進(jìn)程。從系統(tǒng)的視圖看，ApplicationMaster 作為一個普通的容器運(yùn)行著。
???Application在Yarn中的執(zhí)行過程，整個執(zhí)行過程可以總結(jié)為三步：
???(1)應(yīng)用程序提交
???(2)啟動應(yīng)用的ApplicationMaster實(shí)例
???(3)ApplicationMaster 實(shí)例管理應(yīng)用程序的執(zhí)行
具體過程：
???(1)客戶端程序向 ResourceManager 提交應(yīng)用并請求一個 ApplicationMaster 實(shí)例；
(2)ResourceManager 找到一個可以運(yùn)行一個 Container 的 NodeManager，并在這個 Container 中啟動ApplicationMaster 實(shí)例；
???(3)ApplicationMaster 向 ResourceManager 進(jìn)行注冊，注冊之后客戶端就可以查詢 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 中運(yùn)行，并把運(yùn)行的進(jìn)度、狀態(tài)等信息通過 application-specific協(xié)議 發(fā)送給ApplicationMaster；
???(7)在應(yīng)用程序運(yùn)行期間，提交應(yīng)用的客戶端主動和 ApplicationMaster 交流獲得應(yīng)用的運(yùn)行狀態(tài)、進(jìn)度更新等信息，交流協(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對象，運(yùn)行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é)點(diǎn)開啟container容器(本質(zhì)上是一個JVM虛擬機(jī))
???(6)在container中啟動一個applicationMaster,初始化Job，生成一個薄記對象(就是一個記事本)，記錄map、reduce的狀態(tài)。把job所有資源上傳到hdfs中，包括jar包，配置文件，split信息
???(7)applicationMaster向ResourceManager申請資源，返回資源信息(包括node節(jié)點(diǎn)地址，cpu信息，內(nèi)存占比，IO信息)
???(8)applicationMaster收到信息之后，和NodeManager通信，傳遞資源信息
???(9)開啟YarnChild進(jìn)程,從hdfs中獲得Job詳細(xì)信息(包括Jar包,配置文件信息)
<!-- $HADOOP_HOME/etc/hadoop/mapred-site.xml -->
<configuration>
<property>
<name>mapreduce.framework.name</name>
<value>yarn</value>
</property>
</configuration>
<!-- $HADOOP_HOME/etc/hadoop/yarn-site.xml -->
<configuration>
<property>
<name>yarn.nodemanager.aux-services</name>
<value>mapreduce_shuffle</value>
</property>
</configuration>
啟動 ResourceManager 和 NodeManager （以下分別簡稱RM、NM）
#主節(jié)點(diǎn)運(yùn)行命令
$HADOOP_HOME/sbin/start-yarn.sh
#主節(jié)點(diǎn)運(yùn)行命令
$HADOOP_HOME/sbin/stop-yarn.sh
若RM沒有啟動起來，可以單獨(dú)啟動
若RM沒有啟動起來，可以單獨(dú)啟動
#若RM沒有啟動，在主節(jié)點(diǎn)運(yùn)行命令
$HADOOP_HOME/sbin/yarn-daemon.sh start resouremanager
#相反，可單獨(dú)關(guān)閉
$HADOOP_HOME/sbin/yarn-daemon.sh stop resouremanager
若NM沒有啟動起來，可以單獨(dú)啟動
#若NM沒有啟動，在相應(yīng)節(jié)點(diǎn)運(yùn)行命令
$HADOOP_HOME/sbin/yarn-daemon.sh start nodemanager
#相反，可單獨(dú)關(guān)閉
$HADOOP_HOME/sbin/yarn-daemon.sh stop nodemanager
#1.查看正在運(yùn)行的任務(wù)
yarn application -list
#2.殺掉正在運(yùn)行任務(wù)
yarn application -kill 任務(wù)id
#3.查看節(jié)點(diǎn)列表
yarn node -list
#4.查看節(jié)點(diǎn)狀況 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)用按提交的順序排成一個隊列，這是一個先進(jìn)先出隊列，在進(jìn)行資源分配的時候，先給隊列中最頭上的應(yīng)用進(jìn)行分配資源，待最頭上的應(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)度器，有一個專門的隊列用來運(yùn)行小任務(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)容如下：
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<property>
<name>yarn.scheduler.capacity.root.queues</name>
<value>prod,dev</value>
</property>
<property>
<name>yarn.scheduler.capacity.root.dev.queues</name>
<value>hdp,spark</value>
</property>
<property>
<name>yarn.scheduler.capacity.root.prod.capacity</name>
<value>40</value>
</property>
<property>
<name>yarn.scheduler.capacity.root.dev.capacity</name>
<value>60</value>
</property>
<property>
<name>yarn.scheduler.capacity.root.dev.maximum-capacity</name>
<value>75</value>
</property>
<property>
<name>yarn.scheduler.capacity.root.dev.hdp.capacity</name>
<value>50</value>
</property>
<property>
<name>yarn.scheduler.capacity.root.dev.spark.capacity</name>
<value>50</value>
</property>
</configuration>
將應(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)度器會為所有運(yùn)行的job動態(tài)的調(diào)整系統(tǒng)資源。當(dāng)?shù)谝粋€大job提交時，只有這一個job在運(yùn)行，此時它獲得了所有集群資源；當(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ù)及時完成.
