Yarn簡單介紹及內存配置

在這篇博客中，主要介紹了Yarn對MRv1的改進，以及Yarn簡單的內存配置和Yarn的資源抽象container。
我么知道MRv1存在的主要問題是：在運行時，JobTracker既負責資源管理又負責任務調度，這導致了它的擴展性、資源利用率低等問題。之所以存在這樣的問題，是與其最初的設計有關，如下圖：

從上圖可以看到，MRv1是圍繞著MapReduce進行，并沒有過多地考慮以后出現的其它數據處理方式。按著上圖的設計思路，我們每開發一種數據處理方式（例如spark），都要重復實現相應的集群資源管理和數據處理。因此，Yarn就很自然的被開發出來了。
Yarn對MRv1的最大改進就是將資源管理與任務調度分離，使得各種數據處理方式能夠共享資源管理，如下圖所示：

從上圖我們可以看到，Yarn是一種統一資源管理方式，是從MRv1中的JobTracker分離出來的。這樣的好處顯而易見：資源共享，擴展性好等。
MRv1與Yarn的主要區別：在MRv1中，由JobTracker負責資源管理和作業控制，而Yarn中，JobTracker被分為兩部分：ResourceManager（RM）和ApplicationMaster（AM）。如下圖所示：

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

從上圖可以看到，當客戶向RM提交作業時，由AM負責向RM提出資源申請，和向NameManager（NM）提出task執行。也就是說在這個過程中，RM負責資源調度，AM 負責任務調度。幾點重要說明：RM負責整個集群的資源管理與調度；Nodemanager(NM)負責單個節點的資源管理與調度；NM定時的通過心跳的形式與RM進行通信，報告節點的健康狀態與內存使用情況；AM通過與RM交互獲取資源，然后然后通過與NM交互，啟動計算任務。
下面對上面的內容通過內存資源配置進行詳細說明：下面對上面的內容通過內存資源配置進行詳細說明：

RM的內存資源配置，主要是通過下面的兩個參數進行的（這兩個值是Yarn平臺特性，應在yarn-sit.xml中配置好）：?
yarn.scheduler.minimum-allocation-mb?
yarn.scheduler.maximum-allocation-mb
說明：單個容器可申請的最小與最大內存，應用在運行申請內存時不能超過最大值，小于最小值則分配最小值，從這個角度看，最小值有點想操作系統中的頁。最小值還有另外一種用途，計算一個節點的最大container數目注：這兩個值一經設定不能動態改變(此處所說的動態改變是指應用運行時)。

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

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

AM中其它與內存相關的參數，還有JVM相關的參數，這些參數可以通過，如下選項配置：
mapreduce.map.java.opts
mapreduce.reduce.java.opts
說明：這兩個參主要是為需要運行JVM程序（java、scala等）準備的，通過這兩個設置可以向JVM中傳遞參數的，與內存有關的是，-Xmx，-Xms等選項。此數值大小，應該在AM中的map.mb和reduce.mb之間。

我們對上面的內容進行下總結，當配置Yarn內存的時候主要是配置如下三個方面：每個Map和Reduce可用物理內存限制；對于每個任務的JVM對大小的限制；虛擬內存的限制；

下面通過一個具體錯誤實例，進行內存相關說明，錯誤如下：
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.
配置如下：

點擊(此處)折疊或打開

  <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>

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

在上Yarn的框架管理中，無論是AM從RM申請資源，還是NM管理自己所在節點的資源，都是通過container進行的。Container是Yarn的資源抽象，此處的資源包括內存和cup等。下面對
container，進行比較詳細的介紹。為了是大家對container有個比較形象的認識，首先看下圖：

從上圖中我們可以看到，首先AM通過請求包ResourceRequest從RM申請資源，當獲取到資源后，AM對其進行封裝，封裝成ContainerLaunchContext對象，通過這個對象，AM與NM進行通訊，
以便啟動該任務。下面通過ResourceRequest、container和ContainerLaunchContext的protocol buffs定義，對其進行具體分析。

ResourceRequest結構如下：

點擊(此處)折疊或打開

  message ResourceRequestProto?{
 
 optional PriorityProto priority?=?1;?// 資源優先級
 
 optional?string?resource_name?=?2;?// 期望資源所在的host
 
 optional ResourceProto capability?=?3;?// 資源量（mem、cpu）
 
 optional int32 num_containers?=?4;?// 滿足條件container個數
 
 optional bool relax_locality?=?5?;?//default = true;?
 
 }

對上面結構進行簡要按序號說明：
2：在提交申請時，期望從哪臺主機上獲得，但最終還是AM與RM協商決定；
3：只包含兩種資源，即：內存和cpu，申請方式：
注：1、由于2與4并沒有限制資源申請量，則AP在資源申請上是無限的。2、Yarn采用覆蓋式資源申請方式，即：AM每次發出的資源請求會覆蓋掉之前在同一節點且優先級相同的資源請求,
也就是說同一節點中相同優先級的資源請求只能有一個。

container結構：

點擊(此處)折疊或打開

  message ContainerProto?{
 
 optional ContainerIdProto?id?=?1;?//container id
 
 optional NodeIdProto nodeId?=?2;?//container（資源）所在節點
 
 optional?string?node_http_address?=?3;
 
 optional ResourceProto resource?=?4;?//分配的container數量
 
 optional PriorityProto priority?=?5;?//container的優先級
 
 optional hadoop.common.TokenProto container_token?=?6;?//container token，用于安全認證
 
 }

注：每個container一般可以運行一個任務，當AM收到多個container時，將進一步分給某個人物。如：MapReduce

ContainerLaunchContext結構：

點擊(此處)折疊或打開

  message ContainerLaunchContextProto?{
 
 repeated StringLocalResourceMapProto localResources?=?1;?//該Container運行的程序所需的在資源，例如：jar包
 
 optional bytes tokens?=?2;//Security模式下的SecurityTokens
 
 repeated StringBytesMapProto service_data?=?3;
 
 repeated StringStringMapProto?environment?=?4;?//Container啟動所需的環境變量
 
 repeated?string?command?=?5;?//該Container所運行程序的命令,比如運行的為java程序,即$JAVA_HOME/bin/java org.ourclassrepeated ApplicationACLMapProto application_ACLs = 6;//該Container所屬的Application的訪問
 控制列表
 
 }

下面結合一段代碼，僅以ContainerLaunchContext為例進行描述(本應該寫個簡單的有限狀態機的，便于大家理解，但時間不怎么充分)：

點擊(此處)折疊或打開

  申請一個新的ContainerLaunchContext：
 
 ContainerLaunchContext?ctx?=?Records.newRecord(ContainerLaunchContext.class);
 
 ??????????填寫必要的信息：
 
 ctx.setEnvironment(...);
 
 childRsrc.setResource(...);
 
 ctx.setLocalResources(...);
 
 ctx.setCommands(...);
 
 啟動任務：
 
 startReq.setContainerLaunchContext(ctx);