我麼知道MRv1存在的主要問題是:在運行時,JobTracker既負責資源管理又負責任務調度,這導致了它的擴展性、資源利用率低等問題。之所以存在這樣的問題,是與其最初的設計有關,如下圖:
Yarn對MRv1的最大改進就是將資源管理與任務調度分離,使得各種數據處理方式能夠共享資源管理,如下圖所示:
MRv1與Yarn的主要區別:在MRv1中,由JobTracker負責資源管理和作業控制,而Yarn中,JobTracker被分爲兩部分:ResourceManager(RM)和ApplicationMaster(AM)。如下圖所示:
Yarn與MRv1的差異對編程的影響:我們知道,MRv1主要由三部分組成:編程模型(API)、數據處理引擎(MapTask和ReduceTask)和運行環境(JobTracker和TaskTracker);Yarn繼承了MRv1的編程模型和數據處理,改變的只是運行環境,所以對編程沒有什麼影響。
爲了更好 的說明Yarn的資源管理,首先來看下Yarn的框架,如下圖所示:
下面對上面的內容通過內存資源配置進行詳細說明:下面對上面的內容通過內存資源配置進行詳細說明:
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>
memory used”。而由於使用了默認虛擬內存率(也就是2.1倍),所以對於Map Task和Reduce Task總的虛擬內存爲都爲3000*2.1=6.2G。而應用的虛擬內存超過了這個數值,故報錯 。解決辦
法:在啓動Yarn是調節虛擬內存率或者應用運行時調節內存大小。
在上Yarn的框架管理中,無論是AM從RM申請資源,還是NM管理自己所在節點的資源,都是通過container進行的。Container是Yarn的資源抽象,此處的資源包括內存和cup等。下面對
container,進行比較詳細的介紹。爲了是大家對container有個比較形象的認識,首先看下圖:
以便啓動該任務。下面通過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,申請方式:<memory_num,cup_num>
注: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,用於安全認證
- }
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 ctx = Records.newRecord(ContainerLaunchContext.class);
-
填寫必要的信息:
-
ctx.setEnvironment(...);
-
childRsrc.setResource(...);
-
ctx.setLocalResources(...);
-
ctx.setCommands(...);
-
啓動任務:
- startReq.setContainerLaunchContext(ctx);
最後對container進行如下總結:container是Yarn的資源抽象,封裝了節點上的一些資源,主要是CPU與內存;container是AM向NM申請的,其運行是由AM向資源所在NM發起的,並最終運行
的。有兩類container:一類是AM運行需要的container;另一類是AP爲執行任務向RM申請的。