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) | 是否啓用uber功能。若是啓用了該功能，則會將一個「小的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重用（資源重用）的目的。