Yarn的JVM重用功能—uber

理解一下Container：容器中封裝了機器資源，如記憶體，CPU, 磁碟，網路等，每個任務（Task）會被分配一個容器，該任務只能在該容器中執行，並使用該容器封裝的資源。

一個應用程式所需的Container分為兩大類，如下：

（1） 執行ApplicationMaster的Container：這是由ResourceManager（向內部的資源排程器）申請和啟動的，使用者提交應用程式時，可指定唯一的ApplicationMaster所需的資源；

（2） 執行各類任務的Container：這是由ApplicationMaster向ResourceManager申請的，並由ApplicationMaster與NodeManager通訊以啟動之。

以上兩類Container可能在任意節點上，它們的位置通常而言是隨機的，即ApplicationMaster可能與它管理的任務執行在一個節點上。

Jvm重用：

首先，簡單回顧一下Hadoop 1.x中的JVM重用功能：使用者可以透過更改配置，來指定TaskTracker在同一個JVM裡面最多可以累積執行的Task的數量（預設是1）。這樣的好處是減少JVM啟動、退出的次數，從而達到提高任務執行效率的目的。 配置的方法也很簡單：透過設定mapred-site.xml裡面引數mapred.job.reuse.jvm.num.tasks的值。該值預設是1，意味著TaskTracker會為每一個Map任務或Reduce任務都啟動一個JVM，當任務執行完後再退出該JVM。依次類推，如果該值設定為3，TaskTracker則會在同一個JVM裡面最多依次執行3個Task，然後才會退出該JVM。

在 Yarn（Hadoop MapReduce v2）裡面，不再有引數mapred.job.reuse.jvm.num.tasks，但它也有類似JVM Reuse的功能——uber。據Arun的說法，啟用該功能能夠讓一些任務的執行效率提高2到3倍（“we've observed 2x-3x speedup for some jobs”）。不過，由於Yarn的結構已經大不同於MapReduce v1中JobTracker/TaskTracker的結構，因此uber的原理和配置都和之前的JVM重用機制大不相同。

1) uber的原理：

Yarn的預設配置會禁用uber元件，即不允許JVM重用。我們先看看在這種情況下，Yarn是如何執行一個MapReduce job的。首先，Resource Manager裡的Application Manager會為每一個application(比如一個使用者提交的MapReduce Job)在NodeManager裡面申請一個container，然後在該container裡面啟動一個Application Master。container在Yarn中是分配資源的容器(記憶體、cpu、硬碟等)，它啟動時便會相應啟動一個JVM。此時，Application Master便陸續為application包含的每一個task(一個Map task或Reduce task)向Resource Manager申請一個container。等每得到一個container後，便要求該container所屬的NodeManager將此container啟動，然後就在這個container裡面執行相應的task。等這個task執行完後，這個container便會被NodeManager收回，而container所擁有的JVM也相應地被退出。在這種情況下，可以看出每一個JVM僅會執行一Task， JVM並未被重用。

使用者可以透過啟用uber元件來允許JVM重用——即在同一個container裡面依次執行多個task。在yarn-site.xml檔案中，改變一下幾個引數的配置即可啟用uber的方法：

引數| 預設值 | 描述

- mapreduce.job.ubertask.enable | (false) | 是否啟用user功能。如果啟用了該功能，則會將一個“小的application”的所有子task在同一個JVM裡面執行，達到JVM重用的目的。這個JVM便是負責該application的ApplicationMaster所用的JVM（執行在其container裡）。那具體什麼樣的application算是“小的application"呢？下面幾個引數便是用來定義何謂一個“小的application"

- mapreduce.job.ubertask.maxmaps | 9 | map任務數的閥值，如果一個application包含的map數小於該值的定義，那麼該application就會被認為是一個小的application

- mapreduce.job.ubertask.maxreduces | 1 | reduce任務數的閥值，如果一個application包含的reduce數小於該值的定義，那麼該application就會被認為是一個小的application。不過目前Yarn不支援該值大於1的情況“CURRENTLY THE CODE CANNOT SUPPORT MORE THAN ONE REDUCE”

- mapreduce.job.ubertask.maxbytes | | application的輸入大小的閥值。預設為dfs.block.size的值。當實際的輸入大小部超過該值的設定，便會認為該application為一個小的application。

最後，我們來看當uber功能被啟用的時候，Yarn是如何執行一個application的。首先，Resource Manager裡的Application Manager會為每一個application在NodeManager裡面申請一個container，然後在該container裡面啟動一個Application Master。containe啟動時便會相應啟動一個JVM。此時，如果uber功能被啟用，並且該application被認為是一個“小的application”，那麼Application Master便會將該application包含的每一個task依次在這個container裡的JVM裡順序執行，直到所有task被執行完("WIth 'uber' mode enabled, you'll run everything within the container of the AM itself")。這樣Application Master便不用再為每一個task向Resource Manager去申請一個單獨的container，最終達到了 JVM重用（資源重用）的目的。


原文：http://blog.csdn.net/samhacker/article/details/15692003