Apache Hadoop是一個開源軟件框架，可安裝在一個商用機器集群中，使機器可彼此通信并協(xié)同工作，以高度分布式的方式共同存儲和處理大量數(shù)據(jù)。最初，Hadoop 包含以下兩個主要組件: Hadoop Distributed File System (HDFS) 和一個分布式計算引擎，該引擎支持以 MapReduce 作業(yè)的形式實現(xiàn)和運行程序。

MapReduce 是 Google 推廣的一個簡單的編程模型，它對以高度并行和可擴展的方式處理大數(shù)據(jù)集很有用。MapReduce 的靈感來源于函數(shù)式編程，用戶可將他們的計算表達為 Map和 Reduce 函數(shù)，將數(shù)據(jù)作為鍵值對來處理。Hadoop 提供了一個高級 API 來在各種語言中實現(xiàn)自定義的 Map和 Reduce 函數(shù)。

Hadoop 還提供了軟件基礎(chǔ)架構(gòu)，以一系列Map和 Reduce 任務(wù)的形式運行 MapReduce 作業(yè)。Map任務(wù) 在輸入數(shù)據(jù)的子集上調(diào)用 Map函數(shù)。在完成這些調(diào)用后，Reduce任務(wù) 開始在 map 函數(shù)所生成的中間數(shù)據(jù)上調(diào)用 Reduce 任務(wù)，生成最終的輸出。Map和Reduce 任務(wù)彼此單獨運行，這支持并行和容錯的計算。

最重要的是，Hadoop 基礎(chǔ)架構(gòu)負責(zé)處理分布式處理的所有復(fù)雜方面：并行化、調(diào)度、資源管理、機器間通信、軟件和硬件故障處理，等等。得益于這種干凈的抽象，實現(xiàn)處理數(shù)百(或者甚至數(shù)千)個機器上的數(shù) TB 數(shù)據(jù)的分布式應(yīng)用程序從未像現(xiàn)在這么容易過，甚至對于之前沒有使用分布式系統(tǒng)的經(jīng)驗的開發(fā)人員也是如此。

Map Reduce 過程圖

將任務(wù)分割為Map端和Reduce 端，下圖是JobClient、JobTracker和TaskTracker架構(gòu)。

• 1、JobClient 向 JobTracker 請求一個新的JobID

• 2、檢查作業(yè)輸出說明
  

• 3、計算作業(yè)輸出劃分split
  

• 4、將運行作業(yè)所需要的資源(作業(yè)的 jar 文件、配置文件、計算所得的輸入劃分)復(fù)制到一個以作業(yè) ID 命名的目錄中JobTracker 的文件系統(tǒng)。
  

• 5、通過調(diào)用JobTracker 的submitJob() 方法，告訴JobTracker作業(yè)準(zhǔn)備執(zhí)行
  

• 6、JobTracker 接收到 submitJob() 方法調(diào)用后，把此調(diào)用放到一個內(nèi)部隊列中，交由作業(yè)調(diào)度器進行調(diào)度，并對其進行初始化
  

• 7、創(chuàng)建運行任務(wù)列表，作業(yè)調(diào)度去首先從共享文件系統(tǒng)中獲取 JobClient 已經(jīng)計算好的輸入劃分信息(圖中 step6)，然后為每個劃分創(chuàng)建一個 Map 任務(wù)(一個 split 對應(yīng)一個 map，有多少 split 就有多少map)

• 8、TaskTracker 執(zhí)行一個簡單的循環(huán)，定期發(fā)送心跳調(diào)用JobTracker
  

整體的 Shuffle 過程包含以下幾個部分: Map端Shuffle、Sort階段、Reduce端 Shuffle。即是說: Shuffle過程橫跨 Map 和 Reduce兩端，中間包含 Sort 階段，就是數(shù)據(jù)從 map task 輸出到 Reduce task 輸入的這段過程。Sort、Combine是在 Map端的，Combine是提前的Reduce，需要自己設(shè)置。

Hadoop集群中，大部分Map Task 與 Reduce Task 的執(zhí)行是在不同的節(jié)點上。當(dāng)然很多情況下 Reduce 執(zhí)行時需要跨節(jié)點去拉取其它節(jié)點上的 Map Task 結(jié)果。如果集群正在運行的Job 有很多，那么Task 的正常執(zhí)行對集群內(nèi)部的網(wǎng)絡(luò)資源消耗會很嚴(yán)重。而對于必要的網(wǎng)絡(luò)資源消耗，最終的目的就是最大化地減少不必要的消耗。還有在節(jié)點內(nèi)，相比于內(nèi)存，磁盤IO對Job完成時間的影響也是可觀的。從最基本的要求來說，對于MapReduce的Job性能調(diào)優(yōu)的Shuffle 過程，目標(biāo)期望可以有：

完整地從Map Task 端拉取數(shù)據(jù)到Reduce 端。在跨節(jié)點拉取數(shù)據(jù)時，盡可能地減少對帶寬的不必要消耗。減少磁盤IO對Task 執(zhí)行的影響。

總體來講這段Shuffle 過程，能優(yōu)化的地方主要在于減少拉取數(shù)據(jù)的量及盡量使用內(nèi)存而不是磁盤。

1、輸入

在Map Task執(zhí)行時，其輸入來源HDFS 的Block，Map Task只讀取Split。Split 與Block 的對應(yīng)關(guān)系可能是多對一，默認為一對一。

2、切分
決定于當(dāng)前的Mpper的part 交給哪個Reduce 的方法是MapReduce提供的 Partitioner接口，對Key進行Hash 后，再以Reducetask 數(shù)量取模，然后到指定的Job 上。

然后將數(shù)據(jù)寫入內(nèi)存緩沖區(qū)中，緩沖區(qū)的作用是批量收集Map 結(jié)果，減少磁盤 IO 的影響。Key/Value 對以及Partition 的結(jié)果都會被寫入緩沖區(qū)。寫入之前，Key與Value 值都會被序列化成字節(jié)數(shù)組。

3、溢寫
由于內(nèi)存緩沖區(qū)的大小限制(默認100MB)，當(dāng)Map Task 輸出結(jié)果很多時就可能發(fā)生內(nèi)存溢出，所以需要在一定條件下將緩沖區(qū)的數(shù)據(jù)臨時寫入磁盤，然后重新利用這塊緩沖區(qū)。這個從內(nèi)存往磁盤寫數(shù)據(jù)的過程被稱為Spill，中文可譯為溢寫。

這個溢寫是由另外單獨線程來完成，不影響往緩沖區(qū)寫Map結(jié)果的線程。整個緩沖區(qū)有個溢寫的比例spill.percent。這個比例默認是0.8，

Combiner 將有相同Key的Key/Value對加起來，減少溢寫 spill 到磁盤的數(shù)據(jù)量。Combiner 的適用場景: 由于Combiner的輸出是Reducer的輸入，Combiner 絕不能改變最終的計算結(jié)果。故大多數(shù)情況下，Combiner 適用于輸入輸出的 key/value 類型完全一致，且不影響最終結(jié)果的場景(比如累加、最大值等)。

Map很大時，每次溢寫會產(chǎn)生一個spill_file，這樣會有多個spill_file，而最終的輸出只有一個文件，在最終輸出之前會對多個中間過程多次產(chǎn)生的溢寫文件 spill_file 進行合并，此過程就是Merge。

Merge 就是把相同Key 的結(jié)果加起來(當(dāng)然，如果設(shè)置過Combiner，也會使用 combiner 來合并相同的Key)。

Reduce Shuffle

在Reduce Task 之前，不斷拉取當(dāng)前Job 里每個Maptask的最終結(jié)果，然后對從不同地方拉取過來的數(shù)據(jù)不斷地做Merge ，也最終形成一個文件作為Reduce Task 的輸入文件。

1、Copy

Reduce進程啟動一些數(shù)據(jù)copy 線程 (Fetcher)，通過HTTP方式請求map task 所在的 TaskTracker 獲取map task 的輸出文件。因為 maptask 早已結(jié)束，這些文件就歸 TaskTracker 管理在本地磁盤中。

2、Merge

Copy 過來的數(shù)據(jù)會先放入內(nèi)存緩沖區(qū)中，這里的緩沖區(qū)大小要比 map 端的更為靈活，它基于JVM的 heap size設(shè)置，因為Shuffle 階段 Reducer不運行，所以應(yīng)該把絕大部分的內(nèi)存都給 Shuffle 用。這里需要強調(diào)的是，Merge有三種形式:

• 1) 內(nèi)存到內(nèi)存 

• 2) 內(nèi)存到磁盤 

• 3) 磁盤到磁盤

      默認情況下第一種形式不啟用，讓人比較困惑，是吧。當(dāng)內(nèi)存中的數(shù)據(jù)量到達一定閾值，就啟動內(nèi)存到磁盤的Merge 。與Map端類似，這也是溢寫的過程，這個過程中如果你設(shè)置有Combiner，也是會啟用的，然后在磁盤中生成了眾多的溢寫文件。第二種Merge 方式一直在運行，直到?jīng)]有Map 端的數(shù)據(jù)時才結(jié)束，然后啟動第三種磁盤到磁盤的Merge 方式生成最終的那個文件。

3、Reducer的輸入

Merge 的最后會生成一個文件，大多數(shù)情況下存在于磁盤中，但是需要將其放入內(nèi)存中。當(dāng)Reducer輸入文件已定，整個Shuffle 階段才算結(jié)束。然后就是 Reducer 執(zhí)行，把結(jié)果放到 HDFS 上。

YARN(Yet Another Resource Negotiator)是下一代 MapReduce框架的名稱，為了容易記憶，一般稱為MR v2。該框架已經(jīng)不再是一個傳統(tǒng)的MapReduce 框架，甚至與 MapReduce 無關(guān)，她是一個通用的運行時框架，用戶可以編寫自己的計算框架，在該運行環(huán)境中運行。用于自己編寫的框架作為客戶端的一個lib，在運用提交作業(yè)時打包即可。

經(jīng)典 MapReduce 的最嚴(yán)重的限制主要關(guān)系到可伸縮性、資源利用和對與 MapReduce 不同的工作負載的支持。在 MapReduce 框架中，作業(yè)執(zhí)行受兩種類型的進程控制：

一個稱為JobTracker 的主要進程，它協(xié)調(diào)在集群上運行的所有作業(yè)，分配要在 TaskTracker上運行的Map和Reduce 任務(wù)。

許多稱為TaskTracker 的下級進程，它們運行分配的任務(wù)并定期向 JobTracker報告進度。

大型的Hadoop 集群顯現(xiàn)出了由單個JobTracker 導(dǎo)致的可伸縮性瓶頸。

此外，較小和較大的 Hadoop 集群都從未最高效地使用他們的計算資源。在 Hadoop MapReduce 中，每個從屬節(jié)點上的計算資源由集群管理員分解為固定數(shù)量的Map和Reduce slot，這些Slot 不可替代。設(shè)定Map Slot 和Reduce Slot 的數(shù)量后，節(jié)點在任何時刻都不能運行比Map Slot 更多的Map 任務(wù)，即使沒有 Reduce 任務(wù)在運行。這影響了集群的利用率，因為在所有Map Slot 都被使用(而且我們還需要更多)時，我們無法使用任何Reduce Slot，即使它們可用，反之亦然。

Hadoop 設(shè)計為僅運行 MapReduce 作業(yè)。隨著替代性的編程模型(比如 Apache Giraph 所提供的圖形處理)的到來，除 MapReduce 外，越來越需要為可通過高效的、公平的方式在同一個集群上運行并共享資源的其他編程模型提供支持。

JobTracker是集群事務(wù)的集中處理點，存在單點故障。JobTracker 需要完成的任務(wù)太多，既要維護 job 的狀態(tài)又要維護 job 的 task 的狀態(tài)，造成過多的資源消耗。

在TaskTracker 端，用Map/Reduce Task 作為資源的表示過于簡單，沒有考慮到 CPU、內(nèi)存等資源情況，當(dāng)把兩個需要消耗大內(nèi)存的 task 調(diào)度到一起，很容易出現(xiàn)OOM。

把資源強制劃分為Map/Reduce Slot, 當(dāng)只有Map Task 時，Reduce Slot不能用；當(dāng)只有Reduce Task 時，Map Slot 不能用，容易造成資源利用不足。

在 Hadoop MapReduce中，JobTracker具有兩種不同的職責(zé)。管理集群中的計算資源，這涉及到維護活動節(jié)點列表、可用和占用的Map 和Reduce Slots 列表，以及依據(jù)所選的調(diào)度策略將可用 slots 分配給合適的作業(yè)和任務(wù)

協(xié)調(diào)在集群上運行的所有任務(wù)，這涉及到指導(dǎo)TaskTracker 啟動Map和 Reduce 任務(wù)，監(jiān)視任務(wù)的執(zhí)行，重新啟動失敗的任務(wù)，推測性地運行緩慢的任務(wù)，計算作業(yè)計數(shù)器值的總和等等。

為單個進程安排大量職責(zé)會導(dǎo)致重大的可伸縮性問題，尤其是在較大的集群上，JobTracker 必須不斷跟蹤數(shù)千個 TaskTracker、數(shù)百個作業(yè)，以及數(shù)萬個 map 和 reduce 任務(wù)。相反，TaskTracker 通常近運行十來個任務(wù)，這些任務(wù)由勤勉的JobTracker 分配給它們。

為了解決可伸縮性問題，一個簡單而又絕妙的想法應(yīng)運而生: 我們減少了單個 JobTracker 的職責(zé)，將部分職責(zé)委派給TaskTracker，因為集群中有許多 TaskTracker。在新設(shè)計中，這個概念通過將 JobTracker 的雙重職責(zé)(集群資源管理和任務(wù)協(xié)調(diào))分開為兩種不同類型的進程來反映。

• 1、更快地 MapReduce 計算

• 2、對多框架支持

• 3、框架升級更容易

• 1、ResourceManager代替集群管理器

• 2、ApplicationMaster代替一個專用且短暫的JobTracker

• 3、NodeManager代替TaskTracker

• 4、一個分布式應(yīng)用程序代替一個MapReduce作業(yè)

一個全局 ResourceManager以主要后臺進程的形式運行，它通常在專用機器上運行，在各種競爭的應(yīng)用程序之間仲裁可用的集群資源。

在用戶提交一個應(yīng)用程序時，一個稱為 ApplicationMaster 的輕量型進程實例會啟動來協(xié)調(diào)應(yīng)用程序內(nèi)的所有任務(wù)的執(zhí)行。這包括監(jiān)視任務(wù)，重新啟動失敗的任務(wù)，推測性地運行緩慢的任務(wù)，以及計算應(yīng)用程序計數(shù)器值的總和。有趣的是，ApplicationMaster 可在容器內(nèi)運行任何類型的任務(wù)。

NodeManager是TaskTracker 的一種更加普通和高效的版本。沒有固定數(shù)量的Map 和Reduce slots，NodeManager擁有許多動態(tài)創(chuàng)建的資源容器。