下面是Yarn的知識體系圖，這篇文章會介紹所有涉及的知識點扶歪。
一、MRv1的架構(gòu)和缺陷
Apache Hadoop 是一個開源軟件框架乃摹，可安裝在一個商用機(jī)器集群中，使機(jī)器可彼此通信并協(xié)同工作跟衅，以高度分布式的方式共同存儲和處理大量數(shù)據(jù)孵睬。
在 MapReduce 框架中，作業(yè)執(zhí)行受兩種類型的進(jìn)程控制：
一個稱為 JobTracker 的主要進(jìn)程伶跷，它協(xié)調(diào)在集群上運行的所有作業(yè)掰读，分配要在 TaskTracker 上運行的 map 和 reduce 任務(wù)。
許多稱為 TaskTracker 的下級進(jìn)程叭莫，它們運行分配的任務(wù)并定期向 JobTracker 報告進(jìn)度蹈集。
Apache Hadoop 的經(jīng)典版本 (MRv1)
MapReduce1.x時存在的問題：
- 單點故障
- 節(jié)點壓力大
- 不易擴(kuò)展
- 只支持MapReduce作業(yè)
大型 Apache Hadoop 集群 (MRv1) 上繁忙的 JobTracker
為了解決可伸縮性問題，一個簡單而又絕妙的想法應(yīng)運而生：我們減少了單個 JobTracker 的職責(zé)雇初，將部分職責(zé)委派給 TaskTracker拢肆，因為集群中有許多 TaskTracker。在新設(shè)計中靖诗，這個概念通過將 JobTracker 的雙重職責(zé)（集群資源管理和任務(wù)協(xié)調(diào)）分開為兩種不同類型的進(jìn)程來反映郭怪。
不再擁有單個 JobTracker，一種新方法引入了一個集群管理器刊橘，它惟一的職責(zé)就是跟蹤集群中的活動節(jié)點和可用資源鄙才，并將它們分配給任務(wù)。對于提交給集群的每個作業(yè)促绵，會啟動一個專用的攒庵、短暫的 JobTracker 來控制該作業(yè)中的任務(wù)的執(zhí)行。有趣的是败晴，短暫的 JobTracker 由在從屬節(jié)點上運行的 TaskTracker 啟動叙甸。因此，作業(yè)的生命周期的協(xié)調(diào)工作分散在集群中所有可用的機(jī)器上位衩。得益于這種行為，更多工作可并行運行熔萧，可伸縮性得到了顯著提高糖驴。
演進(jìn)成為Yarn
- ResourceManager 代替集群管理器
- ApplicationMaster 代替一個專用且短暫的 JobTracker
- NodeManager 代替 TaskTracker
- 一個分布式應(yīng)用程序代替一個 MapReduce 作業(yè)
二、Yarn概述
Apache Hadoop YARN （Yet Another Resource Negotiator佛致，另一種資源協(xié)調(diào)者）是一種新的 Hadoop 資源管理器贮缕，它是一個通用資源管理系統(tǒng)，可為上層應(yīng)用提供統(tǒng)一的資源管理和調(diào)度俺榆。它將資源管理和處理組件分開感昼，它的引入為集群在利用率、資源統(tǒng)一管理和數(shù)據(jù)共享等方面帶來了巨大好處罐脊。
- YARN是資源調(diào)度框架
- 通用的資源管理系統(tǒng)
- 為上層應(yīng)用提供統(tǒng)一的資源管理和調(diào)度
三定嗓、Yarn的基礎(chǔ)服務(wù)組件
YARN是Hadoop 2.0中的資源管理系統(tǒng)蜕琴，它的基本設(shè)計思想是將MRv1中的JobTracker拆分成了兩個獨立的服務(wù)：一個全局的資源管理器ResourceManager和每個應(yīng)用程序特有的ApplicationMaster。其中ResourceManager負(fù)責(zé)整個系統(tǒng)的資源管理和分配宵溅，而ApplicationMaster負(fù)責(zé)單個應(yīng)用程序的管理凌简。
? 下面是Yarn的架構(gòu)圖：
從上圖可以看出Yarn的核心組件有：
1、Resourcemanager
? RM是一個全局的資源管理器恃逻，集群只有一個雏搂，負(fù)責(zé)整個系統(tǒng)的資源管理和分配，包括處理客戶端請求寇损、啟動/監(jiān)控APP master凸郑、監(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)用程序的資源需求進(jìn)行資源分配植袍，而資源分配單位用一個抽象概念“資源容器”（Resource Container，簡稱Container）表示籽懦，Container是一個動態(tài)資源分配單位于个，它將內(nèi)存、CPU暮顺、磁盤厅篓、網(wǎng)絡(luò)等資源封裝在一起，從而限定每個任務(wù)使用的資源量捶码。
? 此外羽氮，該調(diào)度器是一個可插拔的組件，用戶可根據(jù)自己的需要設(shè)計新的調(diào)度器惫恼，Yarn提供了多種直接可用的調(diào)度器档押，比如FIFO Scheduler、Fair Scheduler和Capacity Scheduler等。
（2） 應(yīng)用程序管理器
? 應(yīng)用程序管理器負(fù)責(zé)管理整個系統(tǒng)中所有應(yīng)用程序令宿，包括應(yīng)用程序提交叼耙、與調(diào)度器協(xié)商資源以啟動ApplicationMaster、監(jiān)控ApplicationMaster運行狀態(tài)并在失敗時重新啟動它等掀淘。
2旬蟋、ApplicationMaster（AM）
? 在用戶提交一個應(yīng)用程序時，一個稱為 ApplicationMaster 的輕量型進(jìn)程實例會啟動來協(xié)調(diào)應(yīng)用程序內(nèi)的所有任務(wù)的執(zhí)行革娄。這包括監(jiān)視任務(wù)倾贰，重新啟動失敗的任務(wù)，推測性地運行緩慢的任務(wù)拦惋，以及計算應(yīng)用程序計數(shù)器值的總和匆浙。這些職責(zé)以前分配給所有作業(yè)的單個 JobTracker。ApplicationMaster 和屬于它的應(yīng)用程序的任務(wù)均在受 NodeManager 控制的資源容器（Container）中運行厕妖。
功能：
數(shù)據(jù)切分
為應(yīng)用程序申請資源并進(jìn)一步分配給內(nèi)部任務(wù)首尼。
任務(wù)監(jiān)控與容錯
負(fù)責(zé)協(xié)調(diào)來自resourcemanager的資源，并通過nodemanager監(jiān)視任務(wù)的執(zhí)行和資源使用情況言秸。
? 有趣的是软能，ApplicationMaster 可在容器內(nèi)運行任何類型的任務(wù)。例如举畸，MapReduce ApplicationMaster 請求一個容器來啟動 map 或 reduce 任務(wù)查排，而 Giraph ApplicationMaster 請求一個容器來運行 Giraph 任務(wù)。還可以實現(xiàn)一個自定義的 ApplicationMaster 來運行特定的任務(wù)抄沮，進(jìn)而發(fā)明出一種全新的分布式應(yīng)用程序框架跋核，改變大數(shù)據(jù)世界的格局∨崖颍可以查閱 Apache Twill砂代，它旨在簡化 YARN 之上的分布式應(yīng)用程序的編寫。
? 在 YARN 中率挣，MapReduce 降級為一個分布式應(yīng)用程序的一個角色（但仍是一個非常流行且有用的角色）刻伊，現(xiàn)在稱為 MRv2。MRv2 是經(jīng)典 MapReduce 引擎（現(xiàn)在稱為 MRv1）的重現(xiàn)椒功，運行在 YARN 之上捶箱。
3、NodeManager（NM）
? NodeManager 是 TaskTracker 的一種更加普通和高效的版本蛾茉。沒有固定數(shù)量的 map 和 reduce slots，NodeManager 擁有許多動態(tài)創(chuàng)建的資源容器（Container）撩鹿。容器的大小取決于它所包含的資源量谦炬，比如內(nèi)存、CPU、磁盤和網(wǎng)絡(luò) IO键思。一個節(jié)點上的容器數(shù)量础爬，由配置參數(shù)與專用于從屬后臺進(jìn)程和操作系統(tǒng)的資源以外的節(jié)點資源總量（比如總 CPU 數(shù)和總內(nèi)存）共同決定。
功能：
- 單個節(jié)點上的資源管理和任務(wù)吼鳞。
- 處理來自于resourcemanager的命令看蚜。
- 處理來自域ApplicationMaster的命令歉糜。
- 管理著抽象容器奈辰，這些抽象容器代表著一些特定程序使用針對每個節(jié)點的資源志衍。
- 定時地向RM匯報本節(jié)點上的資源使用情況和各個Container的運行狀態(tài)（cpu和內(nèi)存等資源）
4酝惧、Container
? Container是YARN中的資源抽象竿滨，它封裝了某個節(jié)點上的多維度資源温峭，如內(nèi)存攻泼、CPU揖赴、磁盤雪位、網(wǎng)絡(luò)等竭钝，當(dāng)AM向RM申請資源時，RM為AM返回的資源便是用Container表示的雹洗。YARN會為每個任務(wù)分配一個Container香罐，且該任務(wù)只能使用該Container中描述的資源。需要注意的是时肿，Container不同于MRv1中的slot庇茫，它是一個動態(tài)資源劃分單位，是根據(jù)應(yīng)用程序的需求動態(tài)生成的嗜侮。目前為止港令，YARN僅支持CPU和內(nèi)存兩種資源，且使用了輕量級資源隔離機(jī)制Cgroups進(jìn)行資源隔離锈颗。
功能：
- 對task環(huán)境的抽象
- 描述一系列信息
- 任務(wù)運行資源的集合（cpu顷霹、內(nèi)存、io等）
小結(jié)：
? Client向ResourceManager提交的每一個應(yīng)用程序都必須有一個Application Master击吱，它經(jīng)過ResourceManager分配資源后淋淀，運行于某一個Slave節(jié)點的Container中，具體做事情的Task同樣也運行與某一個Slave節(jié)點的Container中覆醇。RM朵纷，NM，AM乃至普通的Container之間的通信永脓，都是用RPC機(jī)制袍辞。
? ResourceManager是Master上一個獨立運行的進(jìn)程，負(fù)責(zé)集群統(tǒng)一的資源管理常摧、調(diào)度搅吁、分配等等威创；NodeManager是Slave上一個獨立運行的進(jìn)程，負(fù)責(zé)上報節(jié)點的狀態(tài)谎懦；App Master和Container是運行在Slave上的組件肚豺，Container是yarn中分配資源的一個單位，包涵內(nèi)存界拦、CPU等等資源吸申，yarn以Container為單位分配資源。
? ResourceManager享甸、NodeManager 和容器都不關(guān)心應(yīng)用程序或任務(wù)的類型截碴。所有特定于應(yīng)用程序框架的代碼都轉(zhuǎn)移到它的 ApplicationMaster，以便任何分布式框架都可以受 YARN 支持 — 只要有人為它實現(xiàn)了相應(yīng)的 ApplicationMaster枪萄。
四隐岛、Yarn的作業(yè)執(zhí)行流程
? 當(dāng)用戶向YARN中提交一個應(yīng)用程序后，YARN將分兩個階段運行該應(yīng)用程序：第一個階段是啟動ApplicationMaster瓷翻；第二個階段是由ApplicationMaster創(chuàng)建應(yīng)用程序聚凹，為它申請資源，并監(jiān)控它的整個運行過程齐帚，直到運行完成妒牙，如下圖所示。
根據(jù)上圖对妄，可將YARN的工作流程分為如下幾個步驟：
- 用戶向YARN中提交應(yīng)用程序湘今，其中包括ApplicationMaster程序、啟動ApplicationMaster的命令剪菱、用戶程序等摩瞎；
- ResourceManager為該應(yīng)用程序分配第一個Container，并與對應(yīng)的NodeManager通信孝常，要求它在這個Container中啟動應(yīng)用程序的ApplicationMaster旗们；
- ApplicationMaster首先向ResourceManager注冊，用戶可以直接通過ResourceManager查看應(yīng)用程序的運行狀態(tài)构灸，然后它將為各個任務(wù)申請資源上渴，并監(jiān)控它的運行狀態(tài)，直到運行結(jié)束喜颁，即重復(fù)圖中的步驟4～7稠氮；
- ApplicationMaster采用輪詢的方式通過RPC協(xié)議向ResourceMaster申請和領(lǐng)取資源；
- 一旦ApplicationMaster申請到資源后半开，便與對應(yīng)的NodeManager通信隔披，要求它啟動任務(wù)；
- NodeManager為任務(wù)設(shè)置好運行環(huán)境（包括環(huán)境變量寂拆、JAR包奢米、二進(jìn)制程序等）后芥炭，將任務(wù)啟動命令寫到一個腳本中，并通過運行該腳本啟動任務(wù)恃慧；
- 各個任務(wù)通過某個RPC協(xié)議向ApplicationMaster匯報自己的狀態(tài)和進(jìn)度，以讓ApplicationMaster隨時掌握各個任務(wù)的運行狀態(tài)渺蒿，從而可以在任務(wù)失敗時重新啟動任務(wù)痢士。在應(yīng)用程序運行過程中，用戶可以隨時通過RPC向ApplicationMaster查詢應(yīng)用程序的當(dāng)前運行狀態(tài)茂装；
- 應(yīng)用程序運行完成后怠蹂，ApplicationMaster向ResourceManager注銷并關(guān)閉自己。
上述Yarn作業(yè)執(zhí)行流程可以抽象少态、直觀的表示為下面的流程圖：
? 分配一個容器后城侧，ApplicationMaster 會要求 NodeManager（管理分配容器的主機(jī)）使用這些資源來啟動一個特定于應(yīng)用程序的任務(wù)。此任務(wù)可以是在任何框架中編寫的任何進(jìn)程（比如一個 MapReduce 任務(wù)或一個 Giraph 任務(wù)）彼妻。NodeManager 不會監(jiān)視任務(wù)嫌佑；它僅監(jiān)視容器中的資源使用情況，舉例而言侨歉，如果一個容器消耗的內(nèi)存比最初分配的更多屋摇，它會結(jié)束該容器。
? ApplicationMaster 會竭盡全力協(xié)調(diào)容器幽邓，啟動所有需要的任務(wù)來完成它的應(yīng)用程序炮温。它還監(jiān)視應(yīng)用程序及其任務(wù)的進(jìn)度，在新請求的容器中重新啟動失敗的任務(wù)牵舵，以及向提交應(yīng)用程序的客戶端報告進(jìn)度柒啤。應(yīng)用程序完成后，ApplicationMaster 會關(guān)閉自己并釋放自己的容器畸颅。
? 盡管 ResourceManager 不會對應(yīng)用程序內(nèi)的任務(wù)執(zhí)行任何監(jiān)視担巩，但它會檢查 ApplicationMaster 的健康狀況。如果 ApplicationMaster 失敗重斑，ResourceManager 可在一個新容器中重新啟動它兵睛。您可以認(rèn)為 ResourceManager 負(fù)責(zé)管理 ApplicationMaster，而 ApplicationMasters 負(fù)責(zé)管理任務(wù)窥浪。
五祖很、Yarn的資源調(diào)度模型
? YARN提供了一個資源管理平臺能夠?qū)⒓褐械馁Y源統(tǒng)一進(jìn)行管理。所有節(jié)點上的多維度資源都會根據(jù)申請抽象為一個個Container漾脂。
? YARN采用了雙層資源調(diào)度模型：
? RM中的資源調(diào)度器將資源分配給各個AM：資源分配過程是異步的假颇。資源調(diào)度器將資源分配給一個應(yīng)用程序后，它不會立刻push給對應(yīng)的AM骨稿，而是暫時放到一個緩沖區(qū)中笨鸡，等待AM通過周期性的心跳主動來冉；
? AM領(lǐng)取到資源后再進(jìn)一步分配給它內(nèi)部的各個任務(wù)：不屬于YARN平臺的范疇形耗，由用戶自行實現(xiàn)哥桥。
? 也就是說，ResourceManager分配集群資源的時候激涤，以抽象的Container形式分配給各應(yīng)用程序拟糕，至于應(yīng)用程序的子任務(wù)如何使用這些資源，由應(yīng)用程序自行決定倦踢。
? YARN目前采用的資源分配算法有三種送滞。但真實的調(diào)度器實現(xiàn)中還對算法做了一定程度的優(yōu)化。
（1）FIFO Scheduler
? FIFO Scheduler把應(yīng)用按照提交的順序排成一個隊列辱挥，并且是一個先進(jìn)先出的隊列犁嗅，在進(jìn)行資源分配的時候，先給隊列中排在最前面的應(yīng)用分配資源晤碘，待其滿足資源需求后再給下一個應(yīng)用分配資源褂微，以此類推。
? FIFO Scheduler是最簡單也最容易的資源調(diào)度器园爷，但它并不適用于共享集群蕊梧。大的應(yīng)用可能會占用較多的集群資源，這就將導(dǎo)致其他應(yīng)用被阻塞腮介，而且它也沒有考慮應(yīng)用的優(yōu)先級肥矢，因而應(yīng)用場景非常受限。
（2）Capacity Scheduler
? Capacity Scheduler是Yahoo開發(fā)的多用戶調(diào)度器叠洗，它以隊列為單位劃分資源甘改，每個隊列可設(shè)定一定比例的資源最低保證和使用上限，同時灭抑，每個用戶也可設(shè)定一定的資源使用上限以防止資源濫用十艾。而當(dāng)一個隊列的資源有剩余時，可暫時將剩余資源共享給其他隊列腾节⊥担總的來說，Capacity Scheduler主要有以下幾個特定：
? 容量保證案腺。管理員可為每個隊列設(shè)置資源最低保證和資源使用上限庆冕，而所有提交到該隊列的應(yīng)用程序共享這些資源；
? 靈活性劈榨。如果一個隊列中的資源有剩余访递，可以暫時共享給那些需要資源的隊列，而一旦該隊列有新的應(yīng)用程序提交同辣，則其他隊列釋放的資源會歸還給該隊列拷姿；
? 多重租賃惭载。支持多用戶共享集群和多應(yīng)用程序同時運行，為防止單個應(yīng)用程序响巢、用戶或者隊列獨占集群中的資源描滔，管理員可為之增加多重約束（比如單個應(yīng)用程序同時運行的任務(wù)數(shù)等）；
? 安全保證踪古。每個隊列有嚴(yán)格的ACL列表規(guī)定它的訪問用戶伴挚，每個用戶可指定哪些用戶允許查看自己應(yīng)用程序的運行狀態(tài)或者控制應(yīng)用程序（比如殺死應(yīng)用程序）。此外灾炭，管理員可指定隊列管理員和集群系統(tǒng)管理員；
? 動態(tài)更新配置文件颅眶。管理員可根據(jù)需要動態(tài)修改各種配置參數(shù)蜈出，以實現(xiàn)在線集群管理。
? 關(guān)于Capacity Scheduler更加詳細(xì)的信息涛酗，請參閱官方文檔铡原。
（3）Fair Scheduler
? Fair Scheduler是Facebook開發(fā)的多用戶調(diào)度器，同Capacity Scheduler類似商叹。它以隊列為單位劃分資源燕刻，每個隊列可設(shè)定一定比例的資源最低保證和使用上限，同時剖笙，每個用戶也可設(shè)定一定的資源使用上限以防止資源濫用卵洗；當(dāng)一個隊列的資源有剩余時，可暫時將剩余資源共享給其他隊列弥咪。當(dāng)然过蹂，F(xiàn)air Scheduler也存在很多與Capacity Scheduler不同之處，主要體現(xiàn)在以下幾個方面：
? 資源公平共享聚至。在每個隊列中酷勺，F(xiàn)air Scheduler可選擇按照FIFO、Fair或DRF（即Dominant Resource Fairness算法）策略為應(yīng)用程序分配資源扳躬。其中脆诉，F(xiàn)air策略是一種基于最大最小公平算法實現(xiàn)的資源多路復(fù)用方式，默認(rèn)情況下贷币，每個隊列內(nèi)部采用該方式分配資源击胜。這意味著，如果一個隊列中有兩個應(yīng)用程序同時運行役纹，則每個應(yīng)用程序得到1/2的資源潜的；如果有三個應(yīng)用程序同時運行，則每個應(yīng)用程序可得到1/3的資源字管；
? 支持資源搶占啰挪。當(dāng)某個隊列中有剩余資源時信不，調(diào)度器會將這些資源共享給其他隊列，而當(dāng)該隊列中有新的應(yīng)用程序提交時亡呵，調(diào)度器要為它回收資源抽活。為了盡可能降低不必要的計算浪費，調(diào)度器采用了先等待再強制回收的策略锰什，即如果等待一段時間后尚有未歸還的資源下硕，則會進(jìn)行資源搶戰(zhàn)；從那些超額使用資源的隊列中殺死一部分任務(wù)汁胆，進(jìn)而釋放資源梭姓；
? 負(fù)載均衡。Fair Scheduler提供了一個機(jī)遇任務(wù)數(shù)目的負(fù)載均衡機(jī)制嫩码，該機(jī)制盡可能將系統(tǒng)中的任務(wù)均勻分配到各個節(jié)點上誉尖。此外，用戶也可以根據(jù)自己的需要設(shè)計負(fù)載均衡機(jī)制铸题；
? 調(diào)度策略配置靈活铡恕。Fair Scheduler允許管理員為每個隊列單獨設(shè)置調(diào)度策略（當(dāng)前支持FIFO、Fair或DRF三種）丢间；
? 提供小應(yīng)用程序響應(yīng)時間探熔。由于采用哦了最大最小公平算法，小作業(yè)可以快速獲取資源并運行完成烘挫。
關(guān)于Fair Scheduler更加詳細(xì)的信息诀艰，請參閱官方文檔。
? 想要詳細(xì)了解調(diào)度器饮六，可以參見資料：Yarn 調(diào)度器Scheduler詳解
六涡驮、Yarn的資源管理與配置參數(shù)
Yarn的內(nèi)存管理：
? yarn允許用戶配置每個節(jié)點上可用的物理內(nèi)存資源，注意喜滨，這里是“可用的”捉捅，因為一個節(jié)點上內(nèi)存會被若干個服務(wù)貢享，比如一部分給了yarn虽风，一部分給了hdfs棒口，一部分給了hbase等，yarn配置的只是自己可用的辜膝，配置參數(shù)如下：
? yarn.nodemanager.resource.memory-mb
? 表示該節(jié)點上yarn可以使用的物理內(nèi)存總量无牵，默認(rèn)是8192m，注意厂抖，如果你的節(jié)點內(nèi)存資源不夠8g茎毁，則需要調(diào)減這個值，yarn不會智能的探測節(jié)點物理內(nèi)存總量。
? yarn.nodemanager.vmem-pmem-ratio
? 任務(wù)使用1m物理內(nèi)存最多可以使用虛擬內(nèi)存量七蜘，默認(rèn)是2.1
? yarn.nodemanager.pmem-check-enabled
? 是否啟用一個線程檢查每個任務(wù)證使用的物理內(nèi)存量谭溉，如果任務(wù)超出了分配值，則直接將其kill橡卤，默認(rèn)是true扮念。
? yarn.nodemanager.vmem-check-enabled
? 是否啟用一個線程檢查每個任務(wù)證使用的虛擬內(nèi)存量，如果任務(wù)超出了分配值碧库，則直接將其kill柜与，默認(rèn)是true。
? yarn.scheduler.minimum-allocation-mb
? 單個任務(wù)可以使用最小物理內(nèi)存量嵌灰，默認(rèn)1024m弄匕，如果一個任務(wù)申請物理內(nèi)存量少于該值，則該對應(yīng)值改為這個數(shù)沽瞭。
? yarn.scheduler.maximum-allocation-mb
? 單個任務(wù)可以申請的最多的內(nèi)存量迁匠，默認(rèn)8192m
Yarn cpu管理：
? 目前cpu被劃分為虛擬cpu，這里的虛擬cpu是yarn自己引入的概念秕脓，初衷是考慮到不同節(jié)點cpu性能可能不同，每個cpu具有計算能力也是不一樣的儒搭，比如吠架，某個物理cpu計算能力可能是另外一個物理cpu的2倍，這時候搂鲫，你可以通過為第一個物理cpu多配置幾個虛擬cpu彌補這種差異傍药。用戶提交作業(yè)時，可以指定每個任務(wù)需要的虛擬cpu個數(shù)魂仍。在yarn中拐辽，cpu相關(guān)配置參數(shù)如下：
? yarn.nodemanager.resource.cpu-vcores
? 表示該節(jié)點上yarn可使用的虛擬cpu個數(shù)，默認(rèn)是8個擦酌，注意俱诸，目前推薦將該值為與物理cpu核數(shù)相同。如果你的節(jié)點cpu合數(shù)不夠8個赊舶，則需要調(diào)減小這個值睁搭，而yarn不會智能的探測節(jié)點物理cpu總數(shù)。
? yarn.scheduler.minimum-allocation-vcores
? 單個任務(wù)可申請最小cpu個數(shù)笼平，默認(rèn)1园骆，如果一個任務(wù)申請的cpu個數(shù)少于該數(shù)，則該對應(yīng)值被修改為這個數(shù)
? yarn.scheduler.maximum-allocation-vcores
? 單個任務(wù)可以申請最多虛擬cpu個數(shù)寓调，默認(rèn)是32.
? Yarn的內(nèi)存相關(guān)配置參考：Yarn 內(nèi)存分配管理機(jī)制及相關(guān)參數(shù)配置
七锌唾、構(gòu)建Yarn應(yīng)用程序
? 我們自己動手從頭到尾構(gòu)建一個Yarn應(yīng)用程序是比較復(fù)雜的，很多時候也是不必要的夺英，可以根據(jù)需要的不同選擇一個優(yōu)秀的分布式計算框架幫助我們構(gòu)建應(yīng)用程序晌涕，如需要DAG計算滋捶，則選擇Spark、Tez渐排；需要流式處理炬太，則選擇Spark、Samza或Storm驯耻。
? 也有一些開源項目幫助我們簡化Yarn應(yīng)用程序的構(gòu)建亲族，如Slider、Twill可缚，目前均處于孵化器狀態(tài)霎迫，暫時不討論。Yarn本身也自帶了一個例子“Distributed Shell Application”帘靡，向我們展示了如果通過Yarn Client API完成Client知给、Application Master與Yarn Daemons之間的交互。
? 構(gòu)建Yarn應(yīng)用程序的例子可以參閱：實現(xiàn)一個簡單的Application框架描姚、hadoop Yarn 編程API
參考資料：
? YARN學(xué)習(xí)筆記——Overview and Architecture
