1. Yarn調度隊列
在Yarn中，負責給應用分配資源的是Scheler，並提供了多種調度器和可配置的策略供選擇。
在Yarn中有是三種調度器可以選擇：FIFO Scheler，Capacity Scheler，Fair Scheler。
FIFO Scheler把應用按提交的順序排成一個隊列，這是一個先進先出隊列，在進行資源分配的時候，先給隊列中最頭上的應用分配資源，待最頭上的應用需求滿足後再給下一個分配，以此類推。
FIFO Scheler是最簡單也是最容易理解的調度器，不需要任何配置，但其不適用於共享集群。大的應用可能會佔用所有集群資源，這就導致其它應用被阻塞。在共享集群中，更適合採用Capacity Scheler或Fair Scheler，這兩種調度器都允許大任務和小任務在提交的同時獲得一定的資源。
下面 Yarn調度器對比圖 展示了這幾個調度器的區別，從圖中可以看出，在FIFO調度器中，小任務會被大任務阻塞。
而對於Capacity調度器，有一個專門的隊列用來運行小任務，但是為小任務專門設置一個隊列會佔用一定的集群資源，這就導致大任務的執行時間會落後於使用FIFO調度器時的時間。
在Fair調度器中，我們不需要預先佔用一定的系統資源，Fair調度器會為所有運行的job動態的調整系統資源。如下圖所示，當第一個大job提交時，只有這一個job在運行，此時它獲得了所有集群資源；當第二個小任務提交後，Fair調度器會分配一半資源給這個小任務，讓這兩個任務公平的共享集群資源。
需要注意的是，在下圖Fair調度器中，從第二個任務提交到獲得資源會有一定的延遲，因為它需要等待第一個任務釋放佔用的Container。小任務執行完成以後也會釋放自己佔用的資源，大任務又獲得了全部的系統資源。最終的效果就是Fair調度器既得到了高資源的利用率又能保證小任務的及時執行。
Capacity 調度器允許多個組織共享整個集群，每個組織可以獲得集群的一部分計算能力。通過為每個組織分配專門的隊列，然後再為每個隊列分配一定的集群資源，這樣整個集群就可以通過設置多個隊列的方式給多個組織提供服務了。除此之外，隊列內部又可以垂直劃分，這樣一個組織內部的多個成員就可以共享這個隊列資源了，在一個隊列內部，資源的調度是採用的是先進先出(FIFO)策略。
通過上面那幅圖，我們已經知道一個job可能使用不了整個隊列的資源。然而如果這個隊列中運行多個job，如果這個隊列的資源夠用，那麼就分配給這些job，如果這個隊列的資源不夠用了呢？其實Capacity調度器仍可能分配額外的資源給這個隊列，這就是「彈性隊列」(queue elasticity)的概念。
在正常的操作中，Capacity調度器不會強制釋放Container，當一個隊列資源不夠用時，這個隊列只能獲得其它隊列釋放後的Container資源。當然，我們可以為隊列設置一個最大資源使用量，以免這個隊列過多的佔用空閑資源，導致其它隊列無法使用這些空閑資源，這就是」彈性隊列」需要權衡的地方。
該調度器預定義了一個root隊列，所有隊里都是該隊列的子隊列。
在配置root下面的子隊列時使用逗號隔開，同時在定義層級隊列時使用叫做 queue path 來表明，如 yarn.scheler.capacity.root.a.queues 。各個子隊列都可以使用百分比來表示佔用父隊列資源的比例，如未配置，則表示可以佔用到父隊列資源的全部資源。同時還可以配置一個用戶可以分配的最大資源數、可以同時運行多少個應用等。
調度器中的配置修改後可以使用admin進行動態刷新。
Fair調度器的設計目標是為所有的應用分配公平的資源（對公平的定義可以通過參數來設置），用戶在各自隊列運行中逐漸資源變得平分。
Fair調度器的配置文件位於類路徑下的fair-scheler.xml文件中，這個路徑可以通過yarn.scheler.fair.allocation.file屬性進行修改。若沒有這個配置文件，Fair調度器採用的分配策略，調度器會在用戶提交第一個應用時為其自動創建一個隊列，隊列的名字就是用戶名，所有的應用都會被分配到相應的用戶隊列中。
我們可以在配置文件中配置每一個隊列，並且可以像Capacity 調度器一樣分層次配置隊列。比如，參考capacity-scheler.xml來配置fair-scheler：
隊列的層次是通過嵌套<queue>元素實現的。所有的隊列都是root隊列的孩子，即使我們沒有配到<root>元素里。在這個配置中，我們把dev隊列有分成了eng和science兩個隊列。
Fair調度器中的隊列有一個權重屬性（這個權重就是對公平的定義），並把這個屬性作為公平調度的依據。在這個例子中，當調度器分配集群40:60資源給prod和dev時便視作公平，eng和science隊列沒有定義權重，則會被平均分配。這里的權重並不是百分比，我們把上面的40和60分別替換成2和3，效果也是一樣的。注意，對於在沒有配置文件時按用戶自動創建的隊列，它們仍有權重並且權重值為1。
每個隊列內部仍可以有不同的調度策略。隊列的默認調度策略可以通過頂級元素<defaultQueueSchelingPolicy>進行配置，如果沒有配置，默認採用公平調度。
盡管是Fair調度器，其仍支持在隊列級別進行FIFO調度。每個隊列的調度策略可以被其內部的<schelingPolicy> 元素覆蓋，在上面這個例子中，prod隊列就被指定採用FIFO進行調度，所以，對於提交到prod隊列的任務就可以按照FIFO規則順序的執行了。需要注意，prod和dev之間的調度仍然是公平調度，同樣eng和science也是公平調度。
同時Fair調度器採用了一套基於規則的系統來確定應用應該放到哪個隊列。在上面的例子中，<queuePlacementPolicy> 元素定義了一個規則列表，其中的每個規則會被逐個嘗試直到匹配成功。例如，上例第一個規則specified，則會把應用放到它指定的隊列中，若這個應用沒有指定隊列名或隊列名不存在，則說明不匹配這個規則，然後嘗試下一個規則。primaryGroup規則會嘗試把應用放在以用戶所在的Unix組名命名的隊列中，如果沒有這個隊列，不創建隊列轉而嘗試下一個規則。當前面所有規則不滿足時，則觸發default規則，把應用放在dev.eng隊列中。
上面規則可以歸結成一句話，除非隊列被准確的定義，否則會以用戶名為隊列名創建隊列，還有一個簡單的配置策略可以使得所有的應用放入同一個隊列（default），這樣就可以讓所有應用之間平等共享集群而不是在用戶之間。直接設置yarn.scheler.fair.user-as-default-queue=false，這樣應用便會被放入default 隊列，而不是各個用戶名隊列。另外，我們還可以設置yarn.scheler.fair.allow-undeclared-pools=false，這樣用戶就無法創建隊列了。
盡管上面的配置中沒有展示，每個隊列仍可配置最大、最小資源佔用數和最大可運行的應用的數量。如下：
當一個job提交到一個繁忙集群中的空隊列時，job並不會馬上執行，而是阻塞直到正在運行的job釋放系統資源。為了使提交job的執行時間更具預測性（可以設置等待的超時時間），Fair調度器支持搶占。
搶占就是允許調度器殺掉佔用超過其應占份額資源隊列的containers，這些containers資源便可被分配到應該享有這些份額資源的隊列中。需要注意搶占會降低集群的執行效率，因為被終止的containers需要被重新執行。
可以通過設置一個全局的參數yarn.scheler.fair.preemption=true來啟用搶占功能。此外，還有兩個參數用來控制搶占的過期時間（這兩個參數默認沒有配置，需要至少配置一個來允許搶佔Container）：
如果隊列在minimum share preemption timeout指定的時間內未獲得最小的資源保障，調度器就會搶佔containers。我們可以通過配置文件中的頂級元素<>為所有隊列配置這個超時時間；我們還可以在<queue>元素內配置<minSharePreemptionTimeout>元素來為某個隊列指定超時時間。
與之類似，如果隊列在fair share preemption timeout指定時間內未獲得平等的資源的一半（這個比例可以配置），調度器則會進行搶佔containers。這個超時時間可以通過頂級元素 <> 和元素級元素 <fairSharePreemptionTimeout> 分別配置所有隊列和某個隊列的超時時間。上面提到的比例可以通過 <> (配置所有隊列)和 <fairSharePreemptionThreshold> (配置某個隊列)進行配置，默認是0.5。
2. Hadoop的資源管理系統 —— Yarn
Yarn 是 Hadoop 的資源管理系統，用於取代 MapRece1 的資源調度，改善 MapRece 的實現，並且有足夠的通用性，可以支持其他的分布式計算模式
一般情況下，應用不直接使用 Yarn 的API，而是通過一些分布式計算框架（MapRece、Spark等）來間接實現資源調度管理，使用這些框架的 Yarn 應用運行在集群計算層（Yarn）和集群存儲層（HDFS、HBase）上。
Yarn 主要由兩部分組成：resource manager、node manager。
資源管理器（resource manager）管理集群上資源的使用，節點管理器（node manager）運行在集群中所有節點上且能夠啟動和監控容器（container）。容器用於執行特定應用程序的進程，每個容器都有資源限制（內存、CPU）。
在 Yarn 上運行一個應用的步驟如圖所示：
在 MapRece1中，有兩類守護進程式控制製作業執行過程： jobtracker、tasktracker 。
jobtracker 通過調度 tasktracker 上運行的任務來協調所有運行在系統上的作業，記錄每項作業任務的整體進度情況，若有任務失敗，則在另一個 tasktracker 節點上重新調度該任務。
tasktracker 在運行任務的同時將運行進度報告發送給 job tracker。
MapRece1 的 jobtracker 既要負責資源管理（作業的調度分配），將任務分配給不同的 tasktracker；又要負責任務進度的監控。如果集群非常繁忙，每時每刻都有大量的作業，每個作業下又有很多任務，jobtracker 需要面面俱到了解每個任務的執行情況，負擔很重。
在 MapRece2 對 Yarn 的應用中，一般是會先讓 RM 啟動容器運行一個 Application Master 的進程，然後該進程負責創建和監控所有的 map task 和 rece task，了解每個 task 的執行進度，每個 task 都會運行在一個單獨的 container 中，這些 container 都是 Application Master 統一調度負責向 RM 申請的，這樣就把資源分配和作業運行調度監控解耦，讓 Yarn 專注於資源調度。
FIFO 調度器將應用放置在一個隊列中，然後按照提交的順序（先入先出）運行應用。
【優點】簡單易懂，不需要任何配置。
【缺點】不適合共享集群。大的應用會佔用集群的所有資源，每個應用必須等待直到輪到自己運行，作業平均等待時間較長。
為了避免小作業被大作業阻塞，容量調度器會創建幾個隊列，其中會有專門隊列給小作業執行，保證一提交就可以啟動。
每個隊列都被分配了一定比例容量的資源，保證大作業不會佔用整個集群的所有資源。一般每個隊列對應一個組織，這樣就允許了多個組織共享一個 Hadoop 集群，每個組織可以分配到集群資源的一部分。隊列可以進一步按層次劃分，這樣每個組織內的不同用戶能夠共享該組織隊列所分配的資源。
在一個隊列內，使用 FIFO 調度策略對應用進行調度，但是一個job可能使用不了整個隊列的資源。然而如果這個隊列中運行多個job，如果這個隊列的資源夠用，那麼就分配給這些job。
官方文檔： https://hadoop.apache.org/docs/r2.7.3/hadoop-yarn/hadoop-yarn-site/CapacityScheler.html 。
容量調度器是 Hadoop2.7 默認的調度器，在 yarn-site.xml 中通過以下參數配置：
"彈性隊列" ：如果隊列 queue 資源不夠用了，而其他隊列可能是有空閑可用的資源，那麼容量調度器可能會將空餘的資源分配給隊列 queue 中的隊列，這種特性稱為 "彈性隊列"。可以通過 yarn.scheler.capacity.<queue-path>.maximum-capacity 參數來控制隊列最大佔用集群資源容量的比例。
示例：
在 root 隊列下定義兩個隊列：prod、dev。分別佔用集群 40%、60% 的容量。
prod 沒有設置最大容量限制，所以當 dev 隊列空閑，prod 資源不足時，可能會佔用整個集群 100% 的資源。
dev 隊列設置了最大容量顯示為 75%，也就是及時另外 25% 的資源空閑，dev 最大也只能佔用整個集群 75% 的資源。dev 隊列下還有子隊列 eng、science，容量都是 dev 容量的 50%，沒有為子隊列設置最大容量，所以每個子隊列最大都可能佔用 dev 隊列 100% 的資源，所以佔用的整個集群的絕對資源大小為 30%~75%。
將上述示例的配置添加到 hadoop 配置文件目錄下的 capacity-scheler.xml 中，啟動 Yarn，上控制台（ http://192.168.190.111:8088/cluster/scheler ）可以看到配置的隊列容量限制。
查看配置的每個隊列的容量限制是否生效。
可以看到 prod 隊列容量限制是 40%，最大容量限制不設置則默認為 100%。
dev 的兩個子隊列，佔用 dev 隊列的相對容量大小為 50%~100%，佔用整個集群的絕對容量大小為 30%~100%。
默認的容量調度器配置
公平調度器就是在隊列內，所有的作業平等地分配資源，如果隊列中只有一個作業，可以佔用 100% 的資源；此時進來一個新的作業，則會調度到每個作業佔用 50% 的資源，以此類推。
公平調度器不僅實現了隊列內部的公平，還實現了隊列之間的公平。
現在有兩個隊列 A、B。當 A 執行第一個作業，而 B 沒有作業時，A可以佔用整個集群的資源；當 A 作業還沒完成，B 執行一個作業，則經過一段時間之後，兩個作業各佔用集群一半的資源；當 B 啟動第二個作業時，隊列內部的兩個隊列共享隊列 B 的資源，經過一段時間，各佔用集群 1/4 的資源，A 繼續佔用一半的集群資源。最終結果就是資源在用戶之間實現了公平共享。
官方文檔： https://hadoop.apache.org/docs/r2.7.3/hadoop-yarn/hadoop-yarn-site/FairScheler.html 。
啟用公平調度器，在 yarn-site.xml 中添加以下配置：
創建公平調度配置文件 fair-scheler.xml，內容如下：
公平調度器使用一個規則列表來確定應用應該放到哪個隊列，可配置的值和含義如下：
將上述的配置配置好，啟用 Yarn，web console 上看到的調度器如下：
3. YARN到底是怎麼一回事
YARN的編程模型
1：保證編程模型的向下兼容性，MRv2重用了MRv1的編程模型和數據處理引擎，但運行環境被重寫。
2：編程模型與數據處理引擎
maprece應用程序編程介面有兩套：新的API（mapred)和舊的API（maprece）
採用MRv1舊的API編寫的程序可直接運行在MRv2上
採用MRv1新的API編寫的程序需要使用MRv2編程庫重新編譯並修改不兼容的參數 和返回值
3：運行時環境
MRv1:Jobracker和Tasktracker
MRv2:YARN和ApplicationMaster
YARN的組成
yarn主要由ResourceManager，NodeManager，ApplicationMaster和Container等幾個組件組成。
ResourceManager（RM）
RM是全局資源管理器，負責整個系統的資源管理和分配。
主要由兩個組件組成：調度器和應用 程序管理器（ASM）
調度器
調度器根據容量，隊列等限制條件，將系統中的資源分配給各個正在運行的應用程序
不負責具體應用程序的相關工作，比如監控或跟蹤狀態
不負責重新啟動失敗任務
資源分配單位用「資源容器」resource Container表示
Container是一個動態資源分配單位，它將內存，CPU,磁碟，網路等資源封裝在一起，從而限定每個任務的資源量
調度器是一個可插拔的組件，用戶可以自行設計
YARN提供了多種直接可用的調度器，比如fair Scheler和Capacity Scheler等。
應用程序管理器
負責管理整個系統中所有應用程序
ApplicationMaster(AM)
用戶提交的每個應用程序均包含一個AM
AM的主要功能
與RM調度器協商以獲取資源（用Container表示）
將得到的任務進一步分配給內部的任務
與NM通信以自動/停止任務
監控所有任務運行狀態，並在任務運行失敗時重新為任務申請資源以重啟任務
當前YARN自帶了兩個AM實現
一個用於演示AM編寫方法的實常式序distributedshell
一個用於Maprece程序---MRAppMaster
其他的計算框架對應的AM正在開發中，比如spark等。
Nodemanager（NM）和Container
NM是每個節點上的資源和任務管理器
定時向RM匯報本節點上的資源使用情況和各個Container的運行狀態
接收並處理來自AM的Container啟動/停止等各種要求
Container是YARN中的資源抽象，它封裝了某個節點上的多維度資源
YARN會為每個任務分配一個Container，且改任務只能使用該Container中描述的資源
Container不同於MRv1的slot，它是一個動態資源劃分單位，是根據應用程序的需求動態產生的
YARN主要由以下幾個協議組成
ApplicationClientProtocol
Jobclient通過該RPC協議提交應用才程序，查詢應用程序狀態等
Admin通過該協議更新系統配置文件，比如節點黑名單，用戶隊列許可權等。
ApplicationMasterProtocol
AM通過該RPC協議想RM注冊和撤銷自己，並為各個任務申請資源
ContainerManagementProtocol
AM通過要求NM啟動或者停止Container，獲取各個Container的使用狀態等信息
ResourceTracker
NM通過該RPC協議向RM注冊，並定時發送心跳信息匯報當前節點的資源使用情況和Container運行狀況
YARN的工作流程
文字描述一下這個過程：
1：由客戶端提交一個應用，由RM的ASM接受應用請求
提交過來的應用程序包括哪些內容：
a:ApplicationMaster
b:啟動Applicationmaster的命令
c:本身應用程序的內容
2:提交了三部分內容給RM，然後RM找NodeManager,然後
Nodemanager就啟用Applicationmaster，並分配Container
接下來我們就要執行這個任務了，
3:但是執行任務需要資源，所以我們得向RM的ASM申請執行任務的資源（它會在RM這兒注冊一下，說我已經啟動了，注冊了以後就可以通過RM的來管理，我們用戶也可以通過RM的web客戶端來監控任務的狀態）ASM只是負責APplicationMaster的啟用
4::我們注冊好了後，得申請資源，申請資源是通過第四步，向ResourceScheler申請的
5:申請並領取資源後，它會找Nodemanager，告訴他我應經申請到了，然後Nodemanager判斷一下，
6:知道他申請到了以後就會啟動任務，當前啟動之前會准備好環境，
7:任務啟動以後會跟APplicationmaster進行通信，不斷的心跳進行任務的匯報。
8:完成以後會給RM進行匯報，讓RSM撤銷注冊。然後RSM就會回收資源。當然了，我們是分布式的，所以我們不會只跟自己的Nodemanager通信。也會跟其他的節點通信。
4. 怎樣獲得在yarn框架上運行jar包的執行結果
1、打開Spring Boot應用，通過Maven命令package命令將應用打成jar包。
5. [老實李] YARN通用資源管理系統
Apache Hadoop YARN （Yet Another Resource Negotiator，另一種資源協調者）是一種新的 Hadoop 資源管理器，它是一個通用資源管理系統，可為上層應用提供統一的資源管理和調度，它的引入為集群在利用率、資源統一管理和數據共享等方面帶來了巨大好處
maprece1.0回顧
1. client 負責把作業提交到集群
2. ResourceManager 負責集群資源的統一管理和調度，承擔了 JobTracker 的角色，整個集群只有「一個」，總的來說，RM有以下作用：
3. NodeManager 管理YARN集群中的每個節點。整個集群可以有多個。負責單個節點上資源的管理和使用（具體點說是負責計算節點上container的啟動、監控和管理，防止Application Master使用多於它申請到的計算資源）。NM有以下作用
4. ApplicationMaster 每個應用有一個，負責應用程序整個生命周期的管理 。
ApplicationMaster 負責協調來自 ResourceManager 的資源，並通過 NodeManager 監視容器的執行和資源使用（CPU、內存等的資源分配）。請注意，盡管目前的資源比較傳統（CPU 核心、內存），但未來會帶來支持的新資源類型（比如圖形處理單元或專用處理設備）。AM有以下作用：
5. Container 是 YARN 中的資源抽象，它封裝了某個節點上的多維度資源，如內存、CPU、磁碟、網路等，當AM向RM申請資源時，RM為AM返回的資源便是用Container表示的。YARN會為每個任務分配一個Container，且該任務只能使用該Container中描述的資源。Container有以下作用：
剖析MapRece作業運行機制
1、作業的提交
2、作業的初始化
3、任務的分配
4、任務的執行
5、進度和狀態的更新
6、作業的完成
簡單版工作流程
詳細版工作流程
步驟1：用戶向YARN中提交應用程序，其中包括ApplicationMaster程序、啟動ApplicationMaster、用戶程序等。
步驟2：ResourceManager為該應用程序分配第一個Container，並與對應的NodeManager通信，要求它在這個Container中啟動應用程序的ApplicationMaster。
步驟3：ApplicationMaster首先向ResourceManager注冊，這樣用戶可以直接通過ResourceManager查看應用程序的運行狀態，然後它將為各個任務申請資源，並監控他的運行狀態，直到運行結束，即要重復步驟4-7。
步驟4：ApplicationMaster採用輪詢的方式通過RPC協議找ResourceManager申請和領取資源。
步驟5：一旦Application申請到資源後，便與對應的NodeManager通信，要求啟動任務。
步驟6：NodeManager為任務設置好運行環境，包括環境變數、JAR包、二進製程序等，然後將任務啟動命令寫到另一個腳本中，並通過運行該腳本啟動任務。
步驟7：各個任務通過RPC協議向ApplicationMaster匯報自己的狀態和進度，ApplicationMaster隨時掌握各個任務的運行狀態，從而可以再任務失敗時重新啟動任務。在應用程序運行過程中，用戶可以隨時通過RPC協議ApplicationMaster查詢應用程序的當前運行狀態。
步驟8：應用程序運行完成後，ApplicationMaster向ResourceManager注銷並關閉自己。
1.YARN的HA
2.hdfs的HA
Namenode和resourcemanager的HA兩點最大的不同：
1.ZKFC是作為ResourceManager之中的一個進程，而Hadoop中則是一個外置的守護進程
hadoop1.0到hadoop2.0的變遷
MapRece對任務執行的更多控制（暫時不明白）
1.調度器基本作用
根據節點資源（slot、container）使用情況和作業的要求，將任務調度到各個節點上執行
2.作業調度器考慮的因素
1、作業優先順序。作業的優先順序越高，它能夠獲取的資源（slot數目)也越多。Hadoop 提供了5種作業優先順序，分別為 VERY_HIGH、HIGH、NORMAL、 LOW、VERY_LOW，通過maprece.job.priority屬性來設置，或者用JobClient的setJobPriority()方法來設置。
2、作業提交時間。顧名思義，作業提交的時間越早，就越先執行。
3、作業所在隊列的資源限制。調度器可以分為多個隊列，不同的產品線放到不同的隊列里運行。不同的隊列可以設置一個邊緣限制，這樣不同的隊列有自己獨立的資源，不會出現搶占和濫用資源的情況
3.Hadoop的自帶作業調度器
4.如何配置使用調度器？
將其JAR文件放到Hadoop的類路（classpath）
然後設置mapred.jobtracker.taskScheler屬性（yarn.resourcemanager.scheler.class）值為org.apache.hadoop.yarn.server.resourcemanager.scheler.capacity.CapacityScheler
Application Master決定如何運行構成MapRece作業的各個任務。如果作業很小，就選擇在與它同一個JVM上運行任務
什麼樣的作業稱為小作業（又叫Uber任務或小任務）？
默認情況下，小作業指小於10個mapper且只有一個recer且輸入大小小於HDFS塊的任務。
涉及屬性配置如下：
6. 如何查看yarn隊列的vcore使用量
第二代的maprece框架的TaskScheler就是yarn YARN的編程模型 1：保證編程模型的向下兼容性，MRv2重用了MRv1的編程模型和數據處理引擎，但運行環境被重寫。 2：編程模型與數據處理引擎 maprece應用程序編程介面有兩套：新的API
7. 如何編寫YARN應用程序
步驟1 獲取ApplicationId。客戶端通過RPC協議ClientRMProtocol向ResourceManager發送應用程序提交請求GetNewApplicationRequest，ResourceManager為其返回應答GetNewApplicationResponse，該數據結構中包含多種信息，包括ApplicationId、可資源使用上限和下限等。
步驟2 提交ApplicationMaster。將啟動ApplicationMaster所需的所有信息打包到數據結構ApplicationSubmissionContext中，主要包括以下幾種信息：
(1) application id
(2) application 名稱
(3) application優先順序
(4) application 所屬隊列
(5) application 啟動用戶名
(6) ApplicationMaster對應的Container信息，包括：啟動ApplicationMaster所需各種文件資源、jar包、環境變數、啟動命令、運行ApplicationMaster所需的資源（主要指內存）等。
客戶端調用ClientRMProtocol#submitApplication(ApplicationSubmissionContext)將ApplicationMaster提交到ResourceManager上。
（ResourceManager收到請求後，會為ApplicationMaster尋找合適的節點，並在該節點上啟動它）。
客戶端可通過多種方式查詢應用程序的運行狀態，其中一種是調用RPC函數ClientRMProtocol#getApplicationReport獲取一個應用程序當前運行狀況報告，該報告內容包括應用程序名稱、所屬用戶、所在隊列、ApplicationMaster所在節點、一些診斷信息、啟動時間等。
（2）編寫ApplicationMaster
ApplicationMaster需要與ResoureManager和NodeManager交互，以申請資源和啟動Container，期間涉及到多個數據結構和兩個RPC協議。具體步驟如下：
步驟1 注冊。ApplicationMaster首先需通過RPC協議AMRMProtocol向ResourceManager發送注冊請求，該數據結構中包含ApplicationMaster所在節點的host、RPC port和TrackingUrl等信息，而ResourceManager將返回，該數據結構中包含多種信息，包括該應用程序的ACL列表、可資源使用上限和下限等。
步驟2 申請資源。根據每個任務的資源需求，ApplicationMaster可向ResourceManager申請一系列用於運行任務的Container，ApplicationMaster使用ResourceRequest類描述每個Container（一個container只能運行一個任務）：
1） Hostname 期望Container所在的節點，如果是「*」，表示可以為任意節點。
2） Resource capability 運行該任務所需的資源量，當前僅支持內存資源。
3） Priority 任務優先順序。一個應用程序中的任務可能有多種優先順序，ResourceManager會優先為高優先順序的任務分配資源。
4） numContainers 符合以上條件的container數目。
一旦為任務構造了Container後，ApplicationMaster會使用RPC函數AMRMProtocol#allocate向ResourceManager發送一個AllocateRequest對象，以請求分配這些Container，AllocateRequest中包含以下信息：
1）Requested containers 所需的Container列表
2）Released containers 有些情況下，比如有些任務在某些節點上失敗過，則ApplicationMaster不想再在這些節點上運行任務，此時可要求釋放這些節點上的Container。
3）Progress update information 應用程序執行進度
4）ResponseId RPC響應ID，每次調用RPC，該值會加1。
ResourceManager會為ApplicationMaster返回一個AllocateResponse對象，該對象中主要信息包含在AMResponse中：
1）reboot ApplicationMaster是否需要重新初始化.當ResourceManager端出現不一致狀態時，會要求對應的ApplicationMaster重新初始化。
2）Allocated Containers 新分配的container列表。
3）Completed Containers 已運行完成的container列表，該列表中包含運行成功和未成功的Container，ApplicationMaster可能需要重新運行那些未運行成功的Container。
ApplicationMaster會不斷追蹤已經獲取的container，且只有當需求發生變化時，才允許重新為Container申請資源。
步驟3 啟動Container。當ApplicationMaster（從ResourceManager端）收到新分配的Container列表後，會使用RPC函數ContainerManager#startContainer向對應的NodeManager發送ContainerLaunchContext以啟動Container，ContainerLaunchContext包含以下內容：
1）ContainerId Container id
2）Resource 該Container可使用的資源量（當前僅支持內存）
3）User Container所屬用戶
4）Security tokens 安全令牌，只有持有該令牌才可啟動container
5）LocalResource 運行Container所需的本地資源，比如jar包、二進制文件、其他外部文件等。
6）ServiceData 應用程序可能使用其他外部服務，這些服務相關的數據通過該參數指定。
6）Environment 啟動container所需的環境變數
7）command 啟動container的命令
ApplicationMaster會不斷重復步驟2~3，直到所有任務運行成功，此時，它會調用AMRMProtocol#finishApplicationMaster，以告訴ResourceManage自己運行結束。
【注意】 整個運行過程中，ApplicationMaster需通過心跳與ResourceManager保持聯系，這是因為，如果一段時間內（默認是10min），ResourceManager未收到ApplicationMaster信息，則認為它死掉了，會重新調度或者讓其失敗。通常而言，ApplicationMaster周期性調用RPC函數AMRMProtocol#allocate向其發送空的AllocateRequest請求即可。
8. YARN知識點總結
如果把大數據Hadoop集群當作一台計算機, 那麼
HDFS = 磁碟
YARN = 任務調度器+資源管理器
所有任務都是運行在Yarn上
Yarn分為兩個大的模塊: ResourceManager NodeManager
運行在master機器上, 用於分配資源
兩個模塊
Scheler 負責資源分配
ApplicationsManager 負責應用管理.
RM不負責啟動container, 而是告訴AM哪些container可用, 由AM向NM發起請求來啟動container.
RM負責啟動AM, 並且在應用程序失敗時, 重啟AM.
運行在slave機器上, 用於執行任務
container是計算資源, 代表任務執行時所分配的cpu,內存等資源.
每個任務都是在container里執行的.
執行過程
client首先向RM提交應用, 請求一個AM實例.
RM找到一個可以啟動container的NM, 並啟動一個AM實例
AM向RM注冊之後, client就可以從RM查找到AM的詳細信息, 可以和AM建立聯系.
AM向RM的Scheler發送resource-request請求, Scheler返回資源描述, 包括資源名稱(NM的地址,rack等)、優先順序、資源需求和container集合
AM向對應的NM發起container-launch-specification來啟動container
應用程序在container中運行, 並把進度、狀態等信息通過application-specific協議發送給AM
應用程序執行完畢, AM向RM注銷, 並回收對應的container
scheler是個可插拔的組件, Yarn常用3種scheler
FIFO Scheler
完全先進先出, 按照提交的先後順序. 大任務會堵塞小任務. 不適合共享集群
Capacity Scheler
為每個團隊分配單獨的隊列, 每個隊列分配對應的資源. 每個隊列內部使用FIFO方式.
如果資源不夠, 可以使用其他隊列釋放出來的資源, 但是需要設置隊列能夠佔用的最大資源, 防止隊列資源佔用過高.
Fair Scheler
根據權重來分配各隊列可以使用的資源.
如果一個隊列沒有任務, 那麼這個隊列的資源可以被其他隊列使用.
否則按照設置好的權重來分配隊列的可用資源.
沒有設置權重的隊列則使用平均分配的方式分配資源
搶佔preemption
為了執行任務, 把超出自己份額的應用的container殺掉, 用來執行新提交的任務.
Node Status: Node Manager和Resource Manager之間保持心跳, 並發送資源使用情況給RM.
9. Yarn 隊列設置
設置：yarn.resourcemanager.scheler.class
Capacity Scheler，定義flink、default兩個隊列，各自50%
10. hadoop2.4版本中yarn的web管理界面不能查看作業狀態！！！求助
no router to host...ssh方面的錯誤，如果你的集群安裝的沒有錯誤的話
ssh免登陸都可以的話（你的肯定是不行的）
請關閉你的集群節點的防火牆，並且正確安裝ssh免登陸