Yarn源碼分析之MRAppMaster：作業運作方式Local、Uber、Non-Uber

        基于作業大小因素，MRAppMaster提供了三種作業運作方式：本地Local模式、Uber模式、Non-Uber模式。其中，

        1、本地Local模式：通常用于調試；

        2、Uber模式：為降低小作業延遲而設計的一種模式，所有任務，不管是Map Task，還是Reduce Task，均在同一個Container中順序執行，這個Container其實也是MRAppMaster所在Container；

        3、Non-Uber模式：對于運作時間較長的大作業，先為Map Task申請資源，當Map Task運作完成數目達到一定比例後再為Reduce Task申請資源。

         在Yarn中，作業運作的資源，統一被抽象為容器Container，在MRAppMaster中關于作業運作時需要的資源的配置設定與加載代碼中，容器配置設定申請服務、容器配置設定完成後加載服務中，都有關于Uber模式和Non-Uber模式的處理，如下：

        1、容器配置設定申請路由服務

         容器配置設定申請路由服務ContainerAllocatorRouter繼承自AbstractService，是Hadoop中一個典型的服務，其正常提供服務需要經曆初始化init、啟動start等過程，而在服務啟動的serviceStart()方法中，存在以下關于Uber模式和Non-Uber模式的處理：

        可見，如果Job在Uber模式下運作，啟動構造容器配置設定器LocalContainerAllocator執行個體，否則構造RM容器配置設定器RMContainerAllocator執行個體。而LocalContainerAllocator代表的是本地容器配置設定器，其構造過程中傳入的containerID為MRAppMaster的成員變量containerID，什麼意思呢？不就正好說明LocalContainerAllocator所使用的容器，也就是Uber模式下所使用的容器，就是MRAppMaster所在Container，與上面所介紹的Uber模式正好一緻，而Non-Uber模式下則需要使用Yarn的RMContainerAllocator，通過與ResourceManager進行通信來申請容器的配置設定，總的原則就是：先為Map Task申請資源，當Map Task運作完成數目達到一定比例後再為Reduce Task申請資源。

        2、容器加載路由服務

        容器加載路由服務ContainerLauncherRouter同樣繼承自AbstractService，也是Hadoop中一個典型的服務，我們同樣看下服務啟動serviceStart()方法，如下：

        也是針對Uber模式和Non-Uber模式分别處理，如果Job在Uber模式下運作，啟動構造本地容器加載器LocalContainerLauncher執行個體；否則，構造容器加載器ContainerLauncherImpl執行個體。

        另外，由于Uber模式下不管是Map Task，還是Reduce Task，均在同一個Container中順序執行，是以MapReduce的推測執行機制對于Uber模式是不适用的，故在MRAppMaster服務啟動的serviceStart()方法中，對于Uber模式，會禁用推測執行機制，相關代碼如下：

        可以看到，Uber模式下禁用推測執行機制，即Disable Speculation，Non-Uber模式下發送SpeculatorEvent事件，初始化speculator，是以，對于Uber模式，會禁用推測執行機制。

        在作業的抽象實作JobImpl中，會針對Uber模式進行一些特定參數設定，如下：

        主要包括：

        1、mapreduce.job.reduce.slowstart.completedmaps參數設定為1，即全部Map任務完成後才會為Reduce任務配置設定資源；

        2、參數mapreduce.map.maxattempts、mapreduce.reduce.maxattempts設定為1，即Map、Reduce任務的最大嘗試次數均為1；

        3、參數mapreduce.map.speculative、mapreduce.reduce.speculative設定為false，即禁用Map、Reduce任務的推測執行機制；