在這篇博客中，主要介紹了Yarn對(duì)MRv1的改進(jìn)，以及Yarn簡(jiǎn)單的內(nèi)存配置和Yarn的資源抽象container。
我么知道MRv1存在的主要問(wèn)題是：在運(yùn)行時(shí)，JobTracker既負(fù)責(zé)資源管理又負(fù)責(zé)任務(wù)調(diào)度，這導(dǎo)致了它的擴(kuò)展性、資源利用率低等問(wèn)題。之所以存在這樣的問(wèn)題，是與其最初的設(shè)計(jì)有關(guān)，如下圖：

從上圖可以看到，MRv1是圍繞著MapReduce進(jìn)行，并沒(méi)有過(guò)多地考慮以后出現(xiàn)的其它數(shù)據(jù)處理方式 。按著上圖的設(shè)計(jì)思路，我們每開(kāi)發(fā)一種數(shù)據(jù)處理方式（例如spark），都要重復(fù)實(shí)現(xiàn)相應(yīng)的集群資源管理和數(shù)據(jù)處理。因此，Yarn就很自然的被開(kāi)發(fā)出來(lái)了。
Yarn對(duì)MRv1的最大改進(jìn)就是將資源管理與任務(wù)調(diào)度分離，使得各種數(shù)據(jù)處理方式能夠共享資源管理，如下圖所示：

從上圖我們可以看到，Yarn是一種統(tǒng)一資源管理方式，是從MRv1中的JobTracker分離出來(lái)的。這樣的好處顯而易見(jiàn)：資源共享，擴(kuò)展性好等。
MRv1與Yarn的主要區(qū)別：在MRv1中，由JobTracker負(fù)責(zé)資源管理和作業(yè)控制，而Yarn中，JobTracker被分為兩部分：ResourceManager（RM）和ApplicationMaster（AM）。如下圖所示：

從上圖中，我們可以清晰的看到 ，對(duì)于MRv1無(wú)論是資源管理里還是任務(wù)調(diào)度都是有JobTracker來(lái)完成得。這導(dǎo)致了，JobTracker負(fù)荷太大不便于管理和擴(kuò)展而對(duì)于Yarn，我們看可以清晰地看到資源管理和任務(wù)調(diào)度被分為了兩個(gè)部分：RM和AM。
Yarn與MRv1的差異對(duì)編程的影響：我們知道，MRv1主要由三部分組成：編程模型(API)、數(shù)據(jù)處理引擎(MapTask和ReduceTask)和運(yùn)行環(huán)境(JobTracker和TaskTracker);Yarn繼承了MRv1的編程模型和數(shù)據(jù)處理，改變的只是運(yùn)行環(huán)境，所以對(duì)編程沒(méi)有什么影響。
為了更好 的說(shuō)明Yarn的資源管理，首先來(lái)看下Yarn的框架，如下圖所示：

從上圖可以看到 ，當(dāng)客戶向RM提交 作業(yè)時(shí)，由AM負(fù)責(zé)向RM提出資源申請(qǐng)，和向NameManager（NM）提出task執(zhí)行 。也就是說(shuō) 在這個(gè)過(guò)程中，RM負(fù)責(zé)資源調(diào)度，AM 負(fù)責(zé)任務(wù)調(diào)度。幾點(diǎn)重要說(shuō)明：RM負(fù)責(zé)整個(gè)集群的資源管理與調(diào)度；Nodemanager(NM)負(fù)責(zé)單個(gè)節(jié)點(diǎn)的資源管理與調(diào)度；NM定時(shí)的通過(guò)心跳的形式與RM進(jìn)行通信，報(bào)告節(jié)點(diǎn)的健康狀態(tài)與內(nèi)存使用情況；AM通過(guò)與RM交互獲取資源，然后然后通過(guò)與NM交互，啟動(dòng)計(jì)算任務(wù)。
下面對(duì)上面的內(nèi)容通過(guò)內(nèi)存資源配置進(jìn)行詳細(xì)說(shuō)明：下面對(duì)上面的內(nèi)容通過(guò)內(nèi)存資源配置進(jìn)行詳細(xì)說(shuō)明：

RM的內(nèi)存資源配置，主要是通過(guò)下面的兩個(gè)參數(shù)進(jìn)行的（這兩個(gè)值是Yarn平臺(tái)特性，應(yīng)在yarn-sit.xml中配置好）：?
yarn.scheduler.minimum-allocation-mb?
yarn.scheduler.maximum-allocation-mb
說(shuō)明：單個(gè)容器可申請(qǐng)的最小與最大內(nèi)存，應(yīng)用在運(yùn)行申請(qǐng)內(nèi)存時(shí)不能超過(guò)最大值，小于最小值則分配最小值，從這個(gè)角度看，最小值有點(diǎn)想操作系統(tǒng)中的頁(yè)。最小值還有另外一種用途，計(jì)算一個(gè)節(jié)點(diǎn)的最大container數(shù)目注：這兩個(gè)值一經(jīng)設(shè)定不能動(dòng)態(tài)改變(此處所說(shuō)的動(dòng)態(tài)改變是指應(yīng)用運(yùn)行時(shí))。

NM的內(nèi)存資源配置，主要是通過(guò)下面兩個(gè)參數(shù)進(jìn)行的（這兩個(gè)值是Yarn平臺(tái)特性，應(yīng)在yarn-sit.xml中配置） ：
yarn.nodemanager.resource.memory-mb
yarn.nodemanager.vmem-pmem-ratio
說(shuō)明：每個(gè)節(jié)點(diǎn)可用的最大內(nèi)存，RM中的兩個(gè)值不應(yīng)該超過(guò)此值。此數(shù)值可以用于計(jì)算container最大數(shù)目，即：用此值除以RM中的最小容器內(nèi)存。虛擬內(nèi)存率，是占task所用內(nèi)存的百分比，默認(rèn)值為2.1倍;注意：第一個(gè)參數(shù)是不可修改的，一旦設(shè)置，整個(gè)運(yùn)行過(guò)程中不可動(dòng)態(tài)修改，且該值的默認(rèn)大小是8G，即使計(jì)算機(jī)內(nèi)存不足8G也會(huì)按著8G內(nèi)存來(lái)使用。

AM內(nèi)存配置相關(guān)參數(shù)，此處以MapReduce為例進(jìn)行說(shuō)明（這兩個(gè)值是AM特性，應(yīng)在mapred-site.xml中配置），如下：
mapreduce.map.memory.mb
mapreduce.reduce.memory.mb
說(shuō)明：這兩個(gè)參數(shù)指定用于MapReduce的兩個(gè)任務(wù)（Map and Reduce task）的內(nèi)存大小，其值應(yīng)該在RM中的最大最小container之間。如果沒(méi)有配置則通過(guò)如下簡(jiǎn)單公式獲得：
max(MIN_CONTAINER_SIZE, (Total Available RAM) / containers))
一般的reduce應(yīng)該是map的2倍。注：這兩個(gè)值可以在應(yīng)用啟動(dòng)時(shí)通過(guò)參數(shù)改變；

AM中其它與內(nèi)存相關(guān)的參數(shù)，還有JVM相關(guān)的參數(shù)，這些參數(shù)可以通過(guò)，如下選項(xiàng)配置：
mapreduce.map.java.opts
mapreduce.reduce.java.opts
說(shuō)明：這兩個(gè)參主要是為需要運(yùn)行JVM程序（java、scala等）準(zhǔn)備的，通過(guò)這兩個(gè)設(shè)置可以向JVM中傳遞參數(shù)的，與內(nèi)存有關(guān)的是，-Xmx，-Xms等選項(xiàng)。此數(shù)值大小，應(yīng)該在AM中的map.mb和reduce.mb之間。

我們對(duì)上面的內(nèi)容進(jìn)行下總結(jié)，當(dāng)配置Yarn內(nèi)存的時(shí)候主要是配置如下三個(gè)方面：每個(gè)Map和Reduce可用物理內(nèi)存限制；對(duì)于每個(gè)任務(wù)的JVM對(duì)大小的限制；虛擬內(nèi)存的限制；

下面通過(guò)一個(gè)具體錯(cuò)誤實(shí)例，進(jìn)行內(nèi)存相關(guān)說(shuō)明，錯(cuò)誤如下：
Container[pid=41884,containerID=container_1405950053048_0016_01_000284] is running beyond virtual memory limits. Current usage: 314.6 MB of 2.9 GB physical memory used; 8.7 GB of 6.2 GB virtual memory used. Killing container.
配置如下：

點(diǎn)擊(此處)折疊或打開(kāi)

<property>

????????<name>yarn.nodemanager.resource.memory-mb</name>

????????<value>100000</value>

????</property>

????<property>

????????<name>yarn.scheduler.maximum-allocation-mb</name>

????????<value>10000</value>

????</property>

????<property>

????????<name>yarn.scheduler.minimum-allocation-mb</name>

????????<value>3000</value>

????</property>

???<property>

????????<name>mapreduce.reduce.memory.mb</name>

????????<value>2000</value>

????</property>

通過(guò)配置我們看到，容器的最小內(nèi)存和最大內(nèi)存分別為：3000m和10000m，而reduce設(shè)置的默認(rèn)值小于2000m，map沒(méi)有設(shè)置，所以兩個(gè)值均為3000m，也就是log中的“2.9 GB physical?
memory used”。而由于使用了默認(rèn)虛擬內(nèi)存率(也就是2.1倍)，所以對(duì)于Map Task和Reduce Task總的虛擬內(nèi)存為都為3000*2.1=6.2G。而應(yīng)用的虛擬內(nèi)存超過(guò)了這個(gè)數(shù)值，故報(bào)錯(cuò) 。解決辦
法：在啟動(dòng)Yarn是調(diào)節(jié)虛擬內(nèi)存率或者應(yīng)用運(yùn)行時(shí)調(diào)節(jié)內(nèi)存大小。

在上Yarn的框架管理中，無(wú)論是AM從RM申請(qǐng)資源，還是NM管理自己所在節(jié)點(diǎn)的資源，都是通過(guò)container進(jìn)行的。Container是Yarn的資源抽象，此處的資源包括內(nèi)存和cup等。下面對(duì)
container，進(jìn)行比較詳細(xì)的介紹。為了是大家對(duì)container有個(gè)比較形象的認(rèn)識(shí)，首先看下圖：


從上圖中我們可以看到，首先AM通過(guò)請(qǐng)求包ResourceRequest從RM申請(qǐng)資源，當(dāng)獲取到資源后，AM對(duì)其進(jìn)行封裝，封裝成ContainerLaunchContext對(duì)象，通過(guò)這個(gè)對(duì)象，AM與NM進(jìn)行通訊，
以便啟動(dòng)該任務(wù)。下面通過(guò)ResourceRequest、container和ContainerLaunchContext的protocol buffs定義，對(duì)其進(jìn)行具體分析。

ResourceRequest結(jié)構(gòu)如下：

點(diǎn)擊(此處)折疊或打開(kāi)

message ResourceRequestProto?{

optional PriorityProto priority?=?1;?// 資源優(yōu)先級(jí)

optional?string?resource_name?=?2;?// 期望資源所在的host

optional ResourceProto capability?=?3;?// 資源量（mem、cpu）

optional int32 num_containers?=?4;?// 滿足條件container個(gè)數(shù)

optional bool relax_locality?=?5?;?//default = true;?

}

對(duì)上面結(jié)構(gòu)進(jìn)行簡(jiǎn)要按序號(hào)說(shuō)明：
2：在提交申請(qǐng)時(shí)，期望從哪臺(tái)主機(jī)上獲得，但最終還是AM與RM協(xié)商決定；
3：只包含兩種資源，即：內(nèi)存和cpu，申請(qǐng)方式：
注：1、由于2與4并沒(méi)有限制資源申請(qǐng)量，則AP在資源申請(qǐng)上是無(wú)限的。2、Yarn采用覆蓋式資源申請(qǐng)方式，即：AM每次發(fā)出的資源請(qǐng)求會(huì)覆蓋掉之前在同一節(jié)點(diǎn)且優(yōu)先級(jí)相同的資源請(qǐng)求,
也就是說(shuō)同一節(jié)點(diǎn)中相同優(yōu)先級(jí)的資源請(qǐng)求只能有一個(gè)。

container結(jié)構(gòu)：

點(diǎn)擊(此處)折疊或打開(kāi)

message ContainerProto?{

optional ContainerIdProto?id?=?1;?//container id

optional NodeIdProto nodeId?=?2;?//container（資源）所在節(jié)點(diǎn)

optional?string?node_http_address?=?3;

optional ResourceProto resource?=?4;?//分配的container數(shù)量

optional PriorityProto priority?=?5;?//container的優(yōu)先級(jí)

optional hadoop.common.TokenProto container_token?=?6;?//container token，用于安全認(rèn)證

}

注：每個(gè)container一般可以運(yùn)行一個(gè)任務(wù)，當(dāng)AM收到多個(gè)container時(shí)，將進(jìn)一步分給某個(gè)人物。如：MapReduce

ContainerLaunchContext結(jié)構(gòu)：

點(diǎn)擊(此處)折疊或打開(kāi)

message ContainerLaunchContextProto?{

repeated StringLocalResourceMapProto localResources?=?1;?//該Container運(yùn)行的程序所需的在資源，例如：jar包

optional bytes tokens?=?2;//Security模式下的SecurityTokens

repeated StringBytesMapProto service_data?=?3;

repeated StringStringMapProto?environment?=?4;?//Container啟動(dòng)所需的環(huán)境變量

repeated?string?command?=?5;?//該Container所運(yùn)行程序的命令,比如運(yùn)行的為java程序,即$JAVA_HOME/bin/java org.ourclassrepeated ApplicationACLMapProto application_ACLs = 6;//該Container所屬的Application的訪問(wèn)

控制列表

}

下面結(jié)合一段代碼，僅以ContainerLaunchContext為例進(jìn)行描述(本應(yīng)該寫個(gè)簡(jiǎn)單的有限狀態(tài)機(jī)的，便于大家理解，但時(shí)間不怎么充分)：

點(diǎn)擊(此處)折疊或打開(kāi)

申請(qǐng)一個(gè)新的ContainerLaunchContext：

ContainerLaunchContext?ctx?=?Records.newRecord(ContainerLaunchContext.class);

??????????填寫必要的信息：

ctx.setEnvironment(...);

childRsrc.setResource(...);

ctx.setLocalResources(...);

ctx.setCommands(...);

啟動(dòng)任務(wù)：

startReq.setContainerLaunchContext(ctx);

最后對(duì)container進(jìn)行如下總結(jié)：container是Yarn的資源抽象，封裝了節(jié)點(diǎn)上的一些資源，主要是CPU與內(nèi)存；container是AM向NM申請(qǐng)的，其運(yùn)行是由AM向資源所在NM發(fā)起的，并最終運(yùn)行

的。有兩類container：一類是AM運(yùn)行需要的container；另一類是AP為執(zhí)行任務(wù)向RM申請(qǐng)的。

總結(jié)

以上是生活随笔為你收集整理的Yarn简单介绍及内存配置的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。