Yarn架構介紹
Yarn/MRv2最基本的想法是將原JobTracker主要的資源管理和job調度/監視功能分開作為兩個單獨的守護進程。有一個全局的ResourceManager(RM)和每個Application有一個ApplicationMaster(AM),Application相當於map-reduce job或者DAG jobs。ResourceManager和NodeManager(NM)組成了基本的數據計算框架。ResourceManager協調集群的資源使用，任何client或者運行着的applicationMaster想要運行job或者task都得向RM申請一定的資源。ApplicationMaster是一個框架特殊的庫，對於MapReduce框架而言，它有自己的AM實現，用戶也可以自己實現AM，在運行的時候，AM會與NM一起來啟動和監視tasks。
ResourceManager
ResourceManager作為資源的協調者有兩個主要的組件：Scheduler和ApplicationManager(AsM)。
YARN基本服務組件
基本設計思想是將MRv1中的JobTracker拆分成了兩個獨立的服務：一個全局的資源管理器ResourceManager和每個應用程序特有的ApplicationMaster。其中ResourceManager負責整個系統的資源管理和分配，而ApplicationMaster負責單個應用程序的管理。
YARN總體上仍然是master/slave結構，在整個資源管理框架中，resourcemanager為master，nodemanager是slave。Resourcemanager負責對各個nodemanager上資源進行統一管理和調度。當用戶提交一個應用程序時，需要提供一個用以跟蹤和管理這個程序的ApplicationMaster,它負責向ResourceManager申請資源，並要求NodeManager啟動可以占用一定資源的任務。由於不同的ApplicationMaster被分布到不同的節點上，因此它們之間不會相互影響。
YARN基本組成結構，YARN主要由ResourceManager、NodeManager、ApplicationMaster和Container等幾個組件構成。
ResourceManager是Master上一個獨立運行的進程，負責集群統一的資源管理、調度、分配等;NodeManager是Slave上一個獨立運行的進程，負責上報節點的狀態；App Master和Container是運行在Slave上的組件，Container是yarn中分配資源的一個單位，包涵內存、CPU等資源，yarn以Container為單位分配資源。
Client向ResourceManager提交的每一個應用程序都必須有一個ApplicationMaster,它經過ResourceManager分配資源后，運行於某一個Slave節點的Container中，具體做事情的Task，同樣也運行於某一個Slave節點的Container中。RM,NM,AM乃至普通的Container之間的通信，都是用RPC機制。
YARN的架構設計實際類似一個操作系統。
1、ResourceManager
RM是一個全局的資源管理器，集群里只有一個，負責整個系統的資源管理和分配，包括處理客戶端請求、啟動/監控APP master、監控nodemanager、資源的分配與調度。它主要由兩個組件構成：調度器（Scheduler）和應用程序管理器（Applications Manager,AsM）。
（1）調度器
調度器根據容量、隊列等限制條件（如每個隊列分配一定的資源，最多執行一定數量的作業等），將系統中的資源分配給各個正在運行的應用程序。需要注意的是，該調度咄咄逼人是一個“純調度器”，它不再從事任何與具體應用程序相關的工作，比如不負責監控或者跟蹤應用的執行狀態等，也不負責重新啟動國應用執行失敗或者硬件故障而產生的失敗任務，這些均交由應用程序相關的ApplicationMaster完成。調度器僅根據各個應用程序的資源需求進行資源分配，而資源分配單位用一個抽象概念“資源容器”（Resource Container,簡稱Contrainer）表示，Container是一個動態資源分配單位，它將內存、cpu、磁盤、網絡等資源封裝在一起，從而限定每個任務使用的資源量。此外，該調度器是一個可插拔的組件，用戶可根據自己的需要設計新的調度器，YARN提供了多種直接可用的調度器，比如Fair Scheduler和Capacity Schduler等。
（2）應用程序管理
應用程序管理器負責管理整個系統中所有應用程序，包括應用程序提交，與調度器協商資源以啟動ApplicationMaster、監控ApplicationMaster運行狀態並在失敗時重新啟動它等。
2、ApplicationMaster(AM)
管理YARN內運行的應用程序的每個實例。
功能：
數據切分
為應用程序申請資源並進一步分配給內部任務。
任務監控與容錯
負責協調來自resourcemanager的資源，並通過nodemanager監視任務的執行和資源使用情況。
3、NodeManager(NM)
Nodemanager整個集群有多個，負責每個節點上的資源和使用。
功能：
單個節點上的資源管理和任務。
處理來自於resourcemanager的命令。
處理來自域app master的命令。？？？
NodeManager管理着抽象容器，這些抽象容器代表着一些特定程序使用針對每個節點的資源。
NodeManager定時地向RM匯報本節點上的資源使用情況和各個Container的運行狀態（cpu和內存等資源）
4、Container
Container是YARN中的資源抽象，它封裝了某個節點上的多維度資源，如內存、CPU、磁盤、網絡等，當AM向RM申請資源時，RM為AM返回的資源便是用Container表示的。YARN會為每個任務分配一個Container，且該任務只能使用該Container中描述的資源。需要注意的是，Container不同於MRv1中的slot，它是一個動態的資源划分單位，是根據應用程序的需求動態生成的。目前為止，YARN僅支持CPU和內存兩種資源，且使用了輕量級資源隔離機制Cgroups進行資源隔離。
功能：
對task環境的抽象
描述一系列信息
任務運行資源的集合（cpu、內存、io等）
任務運行環境
二、YARN的資源管理
1、資源調度和隔離是yarn作為一個資源管理系統，最重要且最基礎的兩個功能。資源調度由resourcemanager完成，而資源隔離由各個nodemanager實現。
2、ResourceManager將某個nodemanager上資源分配給任務（這就是所謂的“資源調度”）后，nodemanager需按照要求為任務提供相應的資源，甚至保證這些資源應具有獨占性，為任務運行提供基礎和保證，這就是所謂的資源隔離。
3、當談及到資源時，我們通常指內存、cpu、io有一種資源。Hadoop yarn目前為止僅支持cpu和內存兩種資源管理和調度。
4、內存資源多少決定任務的生死，如果內存不夠，任務可能運行失敗；相比之下，cpu資源則不同，它只會決定任務的快慢，不會對任務的生死產生影響。
Yarn的內存管理：
yarn允許用戶配置每個節點上可用的物理內存資源，注意，這里是“可用的”，因為一個節點上的內存會被若干個服務共享，比如一部分給了yarn，一部分給了hdfs,一總價給了hbase等，yarn配置的啥時自己可用的，配置參數如下：
yarn.nodemanager.resource.memory-mb
表示該節點上yarn可以使用的物理內存總量，默認是8192m，注意，如果你的節點內存資源不夠8G，則需要減小這個值，yarn不會智能地探測節點物理內存總量。
yarn.nodemanager.vmem-pmem-ratio
任務使用1m物理內存最多 可用使用虛擬內存量，默認是2.1
yarn.nodemanager.pmem-check-enabled
是否啟用一個線程檢查每個任務正使用的物理內存量，如果任務超出了分配值，則直接將其kill，默認是true。
yarn.nodemanager.vmem-check-enabled
是否啟用一個線程檢查每個任務正使用的虛擬內存量，如果任務超出了分配值，則直接將其kill，默認是true。
yarn.scheduler.minimum-allocation-mb
單個任務可以使用最小物理內存量，默認1024m，如果一個任務申請物理內存量少於該值，則該對應值改為這個數。
yarn.scheduler.maximum-allocation-mb
單個任務可以申請的最多的內存量，默認8192m
Yarn cpu管理：
目前cpu被划分為虛擬cpu，這里的虛擬cpu是yarn自己引入的概念，初衷是考慮到不同節點cpu性能可能不同，每個cpu具有計算能力也是不一樣的，比如，某個物理cpu計算能力可能是另外一個物理cpu的2倍，這時候，你可以通過為第一個物理cpu多配置幾個虛擬cpu彌補這種差異。用戶提交作業時，可以指定每個任務需要的虛擬cpu個數。在yarn中，cpu相關配置參數如下：
yarn.nodemanager.resource.cpu-vcores
表示該節點上yarn可使用的虛擬cpu個數，默認是8個，注意，目前推薦將該值設置為與物理cpu核數相同。如果你的節點cpu核數不夠8個，則需要減小這個值，而yarn不會智能的探測節點物理cpu總數。
yarn.scheduler.minimum-allocation-vcores
單個任務可申請最小cpu個數，默認1，如果一個任務申請的cpu個數少於該數，則該對應值被修改為這個數
yarn.scheduler.maximum-allocation-vcores
單個任務可以申請最多虛擬cpu個數，默認是32