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重用（资源重用）的目的。