上一篇詳細講了MapReduce1的工作流程，這一篇主要講基於YARN系統的MapReduce 2的工作流程。
對於大於4000個節點的集羣來說，MapReduce1系統將會產生一個規模瓶頸，因此Yahoo在2010年開始設計下一代的MapReduce，因此產生了YARN。YARN通過把jobTracker的責任劃分爲幾個獨立的模塊修復了MapReduce1的缺點。jobTracker需要管理job的安排（scheduling）（用taskTracker來匹配任務）和任務進度監視（追蹤進度，重啓失敗的、慢的任務，寫任務記錄比如counter）。
YARN把這兩個角色分爲兩個獨立的模塊：資源管理器（resource manager）來管理集羣資源的利用，主應用（application master）來管理在集羣上運行的應用的生命週期。主程序與資源管理器協商集羣資源。這些集羣資源就是一些擁有內存限制的容器（containers），可以運行在這些容器中運行應用進程。這些容器被運行在集羣節點上面的節點管理器（node manager）監視，確保應用只能使用被分配的資源。相對於jobTracker來說，每一個應用的實例（一個MapReduce Job）有一個專用的主應用（application master），它在該應用運行的時候執行。
正如描述的那樣，YARN比MapReduce更普通，事實上，MapReduce是YARN的一種類型。YARN設計之美在於不同的YARN應用能夠在一個集羣上共存，因此一個MapReduce程序能夠作爲一個MPI程序運行，這對集羣的可管理性和利用率帶來了很大的提升。而且，用戶非常有可能運行不同版本的MapReduce在他噢乖一個YARN集羣上面，這使得MapReduce的升級更容易管理。YARN的MapReduce牽扯到跟多的實體：
- The Client 提交MapReduce Job
- YARN resource manager 協調集羣上面的電腦資源的分配
- YARN node manager 運行和監視集羣電腦裏面的container
- Application Master 協調運行MapReduce job的任務。application master 和MapReduce task 運行在resource manager分配的containers中。resource manager 被node manager管理。
- HDFS 用來在不同模塊間共享文件的
處理過程如圖6-4所示：
Job 提交
在MapReduce2中提交Job和MapReduce1中調用的API是相同的。（step1） MapReduce2需要配置ClientProtocol，把mapreduce.framework.name設爲yarn。提交過程和MapReduce1非常相似。新的job ID 是從資源管理器中獲取的（不是JobTracker），在YARN中叫做 application ID。（step2）*Job client覈對job的輸出規範，計算輸入劃分（input split），複製job resource（包括job JAR、配置文件和劃分信息） 到HDFS（step3）。最後通過調用資源管器的submitApplication()來提交job（step4）*。
Job 初始化
當資源管理器收到一個submitApplication（）請求，它會原封不動的傳給scheduler。scheduler 分配一個容器，然後資源管理器運行主程序（application master）進程，在節點管理器的管理下（step5a and 5b）。
MapReduce jobs的application master 是一個主類爲MRAppMaster的java程序。它通過創建一些保存job進度的對象來初始化job，同樣的它將會收到從task提交的進度和完成報告。（step6）下一步，他檢索從HDFS複製的客戶端計算的輸入分割（input split）（step7）。然後，它爲每一個split 創建一個map task，而reduce task的個數是由mapreduce.job.reduces來確定的。application master 接下來會決定如何運行組成MapReduce job的任務。
如果job非常小，application master 將會選擇在一個JVM中運行這些任務。在這種情況下，平行運行這些任務與順序運行這些任務的消耗之差比分配和在新container中運行任務的消耗要小。這樣的一個job成爲一個超級job（uber tassk）。什麼是一個小job呢？默認情況下，一個job的map task小於10個，reduce task只有一個，並且input size 小於HDFS block。你可以通過設置mapreduce.job.ubertask.enable爲false來禁用 uber task。在任何任務運行之前，創建輸出目錄的job setup方法將會被調用。
任務分配
如果一個任務不是uber task，application master 將會從資源管理器爲job中所有的map reduce task 請求container。（step8） 所有的請求都被封裝到心跳調用中（heartbeat calls），包括每一個map task 數據本地化的信息，特別的還有主機文件和輸入分割所在的rack。scheduler 利用這些信息來決定調度。在理想情況下，它嘗試把這些任務放到data–local節點上，如果不行的話，scheduler盡力把這些任務放到rack–local節點。請求會爲任務指定內存需求。默認的情況下，map和reduce task都被分配1024M內存。這個數據可以通過mapreduce.map.memory.mb和mapreduce.map.memory.mb來配置。
在內存分配方面，mapreduce1 的taskTracker 有固定數目的插槽（slots），數目是由集羣配置的時候設定的，每一個任務運行在一個獨立的插槽中。slots有一個最大的內存分配值，對一個集羣來說這個值也是固定的，這樣的話，就會造成小任務內存浪費，大任務內存不夠的情況。在YARN中，資源被分爲更小的塊，因此上述問題就會迎刃而解。默認的內存分配額是由scheduler指定的，最小爲1024M，最大是10240M，因此任務能夠請求的內存爲1G-10G（多個1G塊）。
任務執行
當一個任務被資源管理器的scheduler分配完container之後，application master將會與node manager 聯繫來啓動container。(step9a和9b)這個任務被一個主類是YarnChild的JAVA 程序執行。在運行這個任務之前，它需要從HDFS複製運行任務需要的JAR 文件，配置文件等(step10)。最後他纔會開始運行map或者reduce task。（step11）
YarnChild運行在一個指定的JVM中，和MapReduce1一樣爲了把用戶代碼和長時間運行的系統守護進程隔離開來。但是與mapReduce1不同的是，YARN不進行JVM重用，因此每一個任務都是運行在一個新的JVM中。流（streaming）和管道（pipes）進程工作的方式和MapReduce1一樣。流的通信方式依然是標準的輸入輸出，管道的還是socket。
進度和狀態更新
在YARN架構下運行，task向application master提交它的進度和狀態，application master 每隔三秒通過中央接口合併job的進度狀態視圖。過程如圖6-5所示。
客戶端每秒鐘詢問application master進度。在MapReduce1 中jobTracker 的網絡視圖展示一系列正在運行的任務進度，在YARN中,application master 的網絡視圖展示這些任務以及任務的詳細進度。
Job 完成
客戶端每隔五秒調用waitForCompletion()覈對job是否已經完成。這個時間可以通過maoreduce.client.completion.pollinterval來設置。想MapReduce1一樣，job 完成的通知也支持HTTP callback，擦亮了吧產看、是由application master初始化的。
在Job完成時，application master和task container 清除它們的工作狀態，同時OutputCommitter的job的cleanup方法被調用。Job信息由job歷史服務器記錄，確保之後想要查詢時可以找的得到。
至此，兩種架構的工作流程已講解完成。