MapReduce

MapReduce

參考： https://www.cnblogs.com/wcwen...
http://zheming.wang/blog/2015...
https://www.ibm.com/developer...
http://www.cnblogs.com/yurunm...

本文結構：

1. MapReduce模型說明
2. MapReduce1與MapReduce2對比
3. Yarn架構
4. Yarn運行流程

MapReduce模型說明

MapReduce模型基於「映射」與「歸約」的思想，把一堆雜亂無章的數據按照某種特徵概括起來，而後處理並獲得最後的結果。Map面對的是雜亂無章的互不相關的數據，它解析每一個數據，從中提取出key和value，也就是提取了數據的特徵。通過MapReduce的Shuffle階段以後，在Reduce階段看到的都是已經概括好的數據了，在此基礎上咱們能夠作進一步的處理以便獲得結果。在hadoop的不一樣版本中有MapReduce1與MapReduce2(Yarn),這兩種都是基於MapReduce模型構建的分佈式計算框架。MapReduce編程思想，用於解決一些大問題能夠被分解爲許多子問題的場景，且這些子問題相對獨立，將這些子問題並行處理完後，大問題也就被解決。

MapReduce過程

參考： https://blog.csdn.net/u010697...

Spill過程

MapReduce Shuffle可優化方向

• 壓縮：對數據進行壓縮，減小寫讀數據量；
• 減小沒必要要的排序：並非全部類型的Reduce須要的數據都是須要排序的，排序這個nb的過程若是不須要最好仍是不要的好；
• 內存化：Shuffle的數據不放在磁盤而是儘可能放在內存中，除非逼不得已往磁盤上放；固然了若是有性能和內存至關的第三方存儲系統，那放在第三方存儲系統上也是很好的；這個是個大招；
• 網絡框架：netty的性能聽說要佔優了；
• 本節點上的數據不走網絡框架：對於本節點上的Map輸出，Reduce直接去讀吧，不須要繞道網絡框架。

MapReduce1與MapReduce2對比

hadoop1.x版本中的MapReduce，主要由jobTracker與TaskTracker來完成MapReduce任務，jobTracker主要進行集羣資源監控與任務調度工做，taskTracker分佈在每一個節點上執行由jobTracker指派的任務與監控本機資源，這種架構在mapreduce任務很是多時會出現以下問題：

1. JobTracker 是 Map-reduce 的集中處理點，存在單點故障。
2. JobTracker 完成了太多的任務，形成了過多的資源消耗，當 map-reduce job 很是多的時候，會形成很大的內存開銷，潛在來講，也增長了 JobTracker fail 的風險，這也是業界廣泛總結出老 Hadoop 的 Map-Reduce 只能支持 4000 節點主機的上限。
3. 在 TaskTracker 端，以 map/reduce task 的數目做爲資源的表示過於簡單，沒有考慮到 cpu/ 內存的佔用狀況，若是兩個大內存消耗的 task 被調度到了一塊，很容易出現 OOM。
4. 在 TaskTracker 端，把資源強制劃分爲 map task slot 和 reduce task slot, 若是當系統中只有 map task 或者只有 reduce task 的時候，會形成資源的浪費，也就是前面提過的集羣資源利用的問題。
5. 源代碼層面分析的時候，會發現代碼很是的難讀，經常由於一個 class 作了太多的事情，代碼量達 3000 多行，，形成 class 的任務不清晰，增長 bug 修復和版本維護的難度。
6. 從操做的角度來看，如今的 Hadoop MapReduce 框架在有任何重要的或者不重要的變化 ( 例如 bug 修復，性能提高和特性化 ) 時，都會強制進行系統級別的升級更新。更糟的是，它無論用戶的喜愛，強制讓分佈式集羣系統的每個用戶端同時更新。這些更新會讓用戶爲了驗證他們以前的應用程序是否是適用新的 Hadoop 版本而浪費大量時間。

當hadoop2.x版本從新設計mapreduce框架時，mapreduce2(Yarn)的基本設計思想是將MRv1中的JobTracker拆分紅了兩個獨立的服務：一個全局的資源管理器ResourceManager和每一個應用程序特有的ApplicationMaster。其中ResourceManager負責整個系統的資源管理和分配，而ApplicationMaster負責單個應用程序的管理。

Yarn架構

YARN主要由ResourceManager、NodeManager、ApplicationMaster和Container等幾個組件構成,整體上仍然是master/slave結構，在整個資源管理框架中，resourcemanager爲master，nodemanager是slave。Resourcemanager負責對各個nademanger上資源進行統一管理和調度。當用戶提交一個應用程序時，須要提供一個用以跟蹤和管理這個程序的ApplicationMaster，它負責向ResourceManager申請資源，並要求NodeManger啓動能夠佔用必定資源的任務。因爲不一樣的ApplicationMaster被分佈到不一樣的節點上，所以它們之間不會相互影響。

ResourceManager

RM是一個全局的資源管理器，集羣中真正工做的只有一個，經過active與standby的namenode來進行HA,負責整個系統的資源管理和分配，包括處理客戶端請求、啓動/監控APP master、監控nodemanager、資源的分配與調度。它主要由兩個組件構成：調度器（Scheduler）和應用程序管理器（Applications Manager，ASM）。

1. 調度器：根據容量、隊列等限制條件（如每一個隊列分配必定的資源，最多執行必定數量的做業等），將系統中的資源分配給各個正在運行的應用程序。須要注意的是，該調度器是一個「純調度器」，它再也不從事任何與具體應用程序相關的工做，好比不負責監控或者跟蹤應用的執行狀態等，也不負責從新啓動因應用執行失敗或者硬件故障而產生的失敗任務，這些均交由應用程序相關的ApplicationMaster完成。調度器僅根據各個應用程序的資源需求進行資源分配，而資源分配單位用一個抽象概念「資源容器」（Resource Container，簡稱Container）表示，Container是一個動態資源分配單位，它將內存、CPU、磁盤、網絡等資源封裝在一塊兒，從而限定每一個任務使用的資源量。此外，該調度器是一個可插拔的組件，用戶可根據本身的須要設計新的調度器，YARN提供了多種直接可用的調度器，好比Fair Scheduler和Capacity Scheduler等。
2. 應用程序管理器：負責管理整個系統中全部應用程序，包括應用程序提交、與調度器協商資源以啓動ApplicationMaster、監控ApplicationMaster運行狀態並在失敗時從新啓動它等。

ApplicationMaster

管理YARN內運行的應用程序的每一個實例,通過ResourceManager分配資源後，運行於某一個Slave節點的Container中，具體作事情的Task，一樣也運行與某一個Slave節點的Container中,AM主要功能爲：

1. 數據切分
2. 爲應用程序申請資源並進一步分配給內部任務
3. 任務監控與容錯
4. 負責協調來自resourcemanager的資源，並經過nodemanager監視容易的執行和資源使用狀況。

NodeManager（NM）

Nodemanager整個集羣有多個，負責每一個節點上的資源和使用。主要功能爲：

1. 單個節點上的資源管理和任務
2. 處理來自於resourcemanager的命令
3. 處理來自域app master的命令
4. 管理着抽象容器，這些抽象容器表明着一些特定程序使用針對每一個節點的資源。
5. 定時地向RM彙報本節點上的資源使用狀況和各個Container的運行狀態（cpu和內存等資源）

Container

Container是YARN中的資源抽象，它封裝了某個節點上的多維度資源，如內存、CPU、磁盤、網絡等，當AM向RM申請資源時，RM爲AM返回的資源即是用Container表示的。YARN會爲每一個任務分配一個Container，且該任務只能使用該Container中描述的資源。須要注意的是，Container不一樣於MRv1中的slot，它是一個動態資源劃分單位，是根據應用程序的需求動態生成的。目前爲止，YARN僅支持CPU和內存兩種資源，且使用了輕量級資源隔離機制Cgroups進行資源隔離。主要功能有：

1. 對task環境的抽象
2. 描述一系列信息
3. 任務運行資源的集合（cpu、內存、io等）
4. 任務運行環境

Yarn的運行流程

1. Client請求Resource Manager運行一個Application Master實例（step 1）；
2. Resource Manager選擇一個Node Manager，啓動一個Container並運行Application Master實例（step 2a、step 2b）；
3. Application Master根據實際須要向Resource Manager請求更多的Container資源（step 3）；
4. Application Master經過獲取到的Container資源執行分佈式計算（step 4a、step 4b）。