1. mapreduce 的運行機制（Hadoop 2）
首先看下 mapreduce 在 yarn 中的執行流程圖
詳細流程如下：
client通過API提交一個job
向資源管理器(ResourceManager)申請作業的id。
作業客戶端端檢查作業的輸出是否存在，如果存在則報錯，檢查作業的輸入是否存在，如果不存在則報錯。并計算輸入的分片。將運行作業所需要的資源（包括作業jar文件，配置文件和計算所得的輸入分片）復制到HDFS中。
提交作業
資源管理器收到提交作業的請求后，將請求轉發給調度器(scheduler)，調度器分配一個容器，resourcemanager在nodemanager的節點上啟動MRAppMaster進程
MRAppMaster將作業初始化
接收來自共享文件系統的在客戶端計算的輸入分片，對每一個分片創建一個map任務，以及由mapreduce.job.reduces屬性確定的多個reduce對象
MRAppMaster向ResourceManager請求容器運行job
ResourceManager分配了容器之后，MRAppMaster通過與NodeManager通信來啟動容器，在NodeManager節點上啟動一個task JVM，進程名為YarnChild，任務由主類為YarnChild的java應用程序執行，執行任務之前首先將需要的資源本地化，將作業需要的jar文件等資源拷貝到本地，然后運行map任務或reduce任務
作業完成后，執行任務清理工作。
2. maptask和reducetask實例數的決定機制
2.1 maptask實例數的決定機制
map 端的分片大小默認和 hdfs 塊的大小保持一致，在 hadoop2 中的大小為 128M。即數據有多少個 hdfs 數據塊，則就有多少個 map task。
可以自定義切片大小，分配機制定義在FileInputFormat類中，切片主要由這幾個值來運算決定
計算切片的算法：
Math.max(minSize, Math.min(maxSize, blockSize));
mapreduce.input.fileinputformat.split.maxsize
參數如果調得比blocksize小,則會讓切片變小,而且就等于配置的這個參數的值
mapreduce.input.fileinputformat.split.minsize
參數調的比blockSize大,則可以讓切片變得比blocksize還大
2.2 reducetask實例數的決定機制
Reducetask數量的決定是由代碼中api來設置：
//默認值是1
job.setNumReduceTasks(4);//設置reducetask為4個
如果數據分布不均勻(針對 hashcode 而言),就有可能在 reduce 階段產生數據傾斜
注意：reducetask 數量并不是任意設置,還要考慮業務邏輯需求,有些情況下,需要計算全局匯總結果,就只能有 1 個 reducetask。
3. mapreduce 的 shuffle 過程
3.1 主要流程概述
maptask收集我們的map()方法輸出的kv對，放到內存緩沖區中(100M)
從內存緩沖區不斷溢出本地磁盤文件(0.8)，可能會溢出多個文件
多個溢出文件會被合并成大的溢出文件
在溢出過程中，及合并的過程中，都要調用partitoner進行分組和針對key進行排序
reducetask根據自己的分區號，去各個maptask機器上去相應的結果分區數據
reducetask會取到同一個分區的來自不同maptask的結果文件，reducetask會將這些文件再進行合并（歸并排序）
合并成大文件后，shuffle的過程也就結束了，后面進入reducetask的邏輯運算過程（從文件中取出一個一個的鍵值對group，調用用戶自定義的reduce()方法）
Shuffle中的緩沖區大小會影響到mapreduce程序的執行效率，原則上說，緩沖區越大，磁盤io的次數越少，執行速度就越快
緩沖區的大小可以通過參數調整, 參數：io.sort.mb 默認100M
文件最后到達 reducer 端，文件合并的過程是以合并最小數量的文件以便滿足最后一趟的合并系數。即每次合并的文件數是不一樣的。目的盡量減少寫磁盤的數據量，最后一次直接合并到reduce。
3.2 詳細流程解釋
3.2.1 map 端流程
每個map task讀取自己的split的數據。
將計算后的結果進行分區，交給不同的reduce端進行處理，默認hash partion。這里假設經過分區后交給第一個reduce進行處理。接下來將map端輸出的數據寫入內存緩沖區中，目的是批量收集map輸出結果，減少磁盤IO的影響。在寫入之前， key與value值都會被序列化成字節數組。 (整個內存緩沖區就是一個字節數組)
由于內存緩沖區是默認大小是100MB。當map task的輸出結果很多時，就可能會撐爆內存，所以需要在一定條件下將緩沖區中的數據臨時寫入磁盤，然后重新利用這塊緩沖區。這個從內存往磁盤寫數據的過程被稱為Spill，中文可譯為溢寫。這個溢寫是由單獨線程來完成，不影響往緩沖區寫map結果的線程。整個緩沖區有個溢寫的比例spill.percent。這個比例默認是0.8，也就是當緩沖區的數據已經達到閾值（buffer size * spill percent = 100MB * 0.8 = 80MB），溢寫線程啟動，鎖定這80MB的內存，執行溢寫過程。Map task的輸出結果還可以往剩下的20MB內存中寫，互不影響。 當溢寫線程啟動后，需要對這80MB空間內的key做排序(Sort)。排序是MapReduce模型默認的行為，這里的排序也是對序列化的字節做的排序。
在這里我們可以想想，因為map task的輸出是需要發送到不同的reduce端去，而內存緩沖區沒有對將發送到相同reduce端的數據做合并，那么這種合并應該是體現是磁盤文件中的。從官方圖上也可以看到寫到磁盤中的溢寫文件是對不同的reduce端的數值做過合并。所以溢寫過程一個很重要的細節在于，如果有很多個 key/value對需要發送到某個reduce端去，那么需要將這些key/value值拼接到一塊，減少與partition相關的索引記錄。
在針對每個reduce端而合并數據時，有些數據可能像這樣：“aaa”/1， “aaa”/1。對于WordCount例子，就是簡單地統計單詞出現的次數，如果在同一個map task的結果中有很多個像“aaa”一樣出現多次的key，我們就應該把它們的值合并到一塊，這個過程叫reduce也叫combine。但 MapReduce的術語中，reduce只指reduce端執行從多個map task取數據做計算的過程。除reduce外，非正式地合并數據只能算做combine了。其實大家知道的，MapReduce中將Combiner等同于Reducer。
如果client設置過Combiner，那么現在就是使用Combiner的時候了。將有相同key的key/value對的value加起來， 減少溢寫到磁盤的數據量。Combiner會優化MapReduce的中間結果，所以它在整個模型中會多次使用。那哪些場景才能使用Combiner呢？ 從這里分析，Combiner的輸出是Reducer的輸入，Combiner絕不能改變最終的計算結果。所以從我的想法來看，Combiner只應該用于那種Reduce的輸入key/value與輸出key/value類型完全一致，且不影響最終結果的場景。比如累加，最大值等。Combiner的使 用一定得慎重，如果用好，它對job執行效率有幫助，反之會影響reduce的最終結果。
- 每次溢寫會在磁盤上生成一個溢寫文件，如果map的輸出結果真的很大，有多次這樣的溢寫發生，磁盤上相應的就會有多個溢寫文件存在。當map task真正完成時，內存緩沖區中的數據也全部溢寫到磁盤中形成一個溢寫文件。最終磁盤中會至少有一個這樣的溢寫文件存在(如果map的輸出結果很少，當 map執行完成時，只會產生一個溢寫文件)，因為最終的文件只有一個，所以需要將這些溢寫文件歸并到一起，這個過程就叫做Merge。Merge是怎樣的？如前面的例子，“aaa”從某個map task讀取過來時值是5，從另外一個map 讀取時值是8，因為它們有相同的key，所以得merge成group。什么是group。對于“aaa”就是像這樣的：{“aaa”, [5, 8, 2, …]}，數組中的值就是從不同溢寫文件中讀取出來的，然后再把這些值加起來。請注意，因為merge是將多個溢寫文件合并到一個文件，所以可能也有相同的key存在，在這個過程中如果client設置過Combiner，也會使用Combiner來合并相同的key。
至此，map端的所有工作都已結束，最終生成的這個文件也存放在TaskTracker夠得著的某個本地目錄內。每個reduce task不斷地通過RPC從JobTracker那里獲取map task是否完成的信息，如果reduce task得到通知，獲知某臺TaskTracker上的map task執行完成，Shuffle的后半段過程開始啟動。
3.2.2 reduce 端流程
Copy過程，簡單地拉取數據。Reduce進程啟動一些數據copy線程(Fetcher)，通過HTTP方式請求map task所在的TaskTracker獲取map task的輸出文件。因為map task早已結束，這些文件就歸TaskTracker管理在本地磁盤中。
Merge階段。這里的merge如map端的merge動作，只是數組中存放的是不同map端copy來的數值。Copy過來的數據會先放入內存緩沖區中，這里的緩沖區大小要比map端的更為靈活，它基于JVM的heap size設置，因為Shuffle階段Reducer不運行，所以應該把絕大部分的內存都給Shuffle用。這里需要強調的是，merge有三種形式：(1)內存到內存 (2)內存到磁盤 (3)磁盤到磁盤。默認情況下第一種形式不啟用。當內存中的數據量到達一定閾值，就啟動內存到磁盤的merge。與map端類似，這也是溢寫的過程，這個過程中如果你設置有Combiner，也是會啟用的，然后在磁盤中生成了眾多的溢寫文件。第二種merge方式一直在運行，直到沒有map端的數據時才結束，然后啟動第三種磁盤到磁盤的merge方式生成最終的那個文件。
Reducer的輸入文件。不斷地merge后，最后會生成一個"最終文件"，默認情況下，這個文件是存放于磁盤中的。當Reducer的輸入文件已定，整個 Shuffle才最終結束。然后就是Reducer執行，把結果放到HDFS上。
