1.概述
在接觸了第一代MapReduce和第二代MapReduce之后，或許會有這樣的疑惑，我們從一些書籍和博客當中獲取MapReduce的一些原理和算法，在第一代當中會有JobTrack，TaskTrack之類的術語，在第二代會有ResourceManager，NodeManager，ApplicationMaster等等術語。然又有Shuffle、Partitioner、Sort、Combiner等關鍵字，如何區分它們，理順其之間的聯系。
在Hadoop2.x大行其道的年代，其優秀的資源管理框架（系統），高可用的分布式存儲系統，備受企業青睞。然因上述之惑，往往不能盡得其中之深意。此篇博客筆者為大家一一解惑。
2.計算模型
在閱讀和研究第一代MapReduce和第二代MapReduce之后，我們可以發現MapReduce其實由兩部分組成，一者為其計算模型，二者為其運行環境。到這里，就不難解釋為何在第一代MapReduce里面由Shuffle、Sort等內容，而在第二代MapReduce中也同樣存在其相關內容。原因很簡單，在Hadoop2.x中，MapReduce的變化，只有其運行環境變化了，然其計算模型依舊不變。
在MapReduce的計算模型當中，對方法進行了高階抽象，其精華為Map Task和Reduce Task，在Map階段完成對應的map函數的邏輯實現，與之相對的在Reduce階段完成對應的reduce函數的邏輯實現，即可編寫好整個核心的MapReduce的處理過程，在Main函數入口之處，申請對應的Job，指定相應的Mapper和Reducer繼承類，以及其輸入輸出類型等相關信息，即可運行一個完整的MapReduce任務。
雖說我們能夠編寫一個完成MapReduce程序，並運行它。然其運行的細節，我們卻未必清楚，往往初學者在編寫一個MapReduce作業時，遇到錯誤而不去研究分析其錯誤之根本，轉而求助於搜索引擎，在搜索無望之下，會讓自己瞬間懵逼，不知所措。
這里，我們去剖析其計算模型的執行細節，雖不敢說剖析之后能解決所有的疑難雜症，但起碼能讓我們知曉錯誤原因，能夠找到解決問題的方向，繼而解決我們所遇之難題。下面為大家剖析MapReduce的計算模型。
Map階段，簡言之：
- Read：該步驟是去讀取我們的數據源，將數據進行filter成一個個的K/V
- Map：在map函數中，處理解析的K/V，並產生新的K/V
- Collect：輸出結果，存於環形內緩沖區
- Spill：內存區滿，數據寫到本地磁盤，並生產臨時文件
- Combine：合並臨時文件，確保生產一個數據文件
Reduce階段，簡言之：
- Shuffle：Copy階段，Reduce Task到各個Map Task遠程復制一分數據，針對某一份數據，若其大小超過一定閥值，則寫磁盤；否則放到內存
- Merge：合並內存和磁盤上的文件，防止內存占用過多或磁盤文件過多
- Sort：Map Task階段進行局部排序，Reduce Task階段進行一次歸並排序
- Reduce：將數據給reduce函數
- Write：reduce函數將其計算的結果寫到HDFS上
上述為其計算模型的執行過程，需有幾點要額外注意。這里有些階段，我們在編寫相關應用時，需有謹慎。
這里有一個Combine階段，這個階段的使用有助與我們對MapReduce的性能進行優化，為何這么說？細細剖析該過程便可明白。在map函數時，它只管處理數據，並不負責統計處理數據的結果，也就是說並沒有Combine階段，那么，問題來了，在reduce過程當中，因為每個map函數處理后的數據沒有統計，它除了要統計所有map的匯總數量，還要統計單個map下的處理數。也許，這里有點繞，大家可以參照下圖來理解這層意思，如下圖所示：
然而，這樣是不行的，所以Reduce為了減輕壓力，每個map都必須統計自己旗下任務處理結果，即：Combine。這樣，Reduce所做的事情就是統計每個map統計之后的結果，這樣子就會輕松許多。因而，Combine在map所做的事情，減輕了Reduce的事情，省略了上圖中的步驟1。
具體代碼細節，可在Job的屬性方法中設置對應的參數，如下所示：
job.setCombinerClass(DefReducer.class);
另外，我們也有必要理解Partition相關職責，它是分割map節點的結果，按照Key分別映射給不同的Reduce，這里我們可以理解為歸類，對一些復雜的數據進行歸類。在Job屬性中設置對應的分區類，那么你的分區函數就生效了，如下所示：
job.setPartitionerClass(DefPartition.class);
3.運行環境
在Hadoop2.x中，由於有了YARN來做資源管理，因而第二代MapReduce的運行環境，對比第一代MapReduce有了些許的改變。具體改變細節，可參考我寫的另一篇博客：《MapReduce運行環境剖析》。
4.總結
本篇博客給大家剖析了MapReduce的計算模型和運行環境，其中計算模型不變，變者乃其運行環境。所變內容，簡言之：RM下包含AM和NM，NM會RM申請Container（其可理解為一個運行時的JVM），NM與RM的通信屬於“Pull模型”，即NM主動上報狀態信息，RM被動接受上報信息。
5.結束語
這篇文章就和大家分享到這里，如果大家在研究和學習的過程中有什么疑問，可以加群進行討論或發送郵件給我，我會盡我所能為您解答，與君共勉！