Hadoop 面試，有它就夠了

Map Reduce & YARN
簡介
Apache Hadoop 是一個開源軟件框架，可安裝在一個商用機器集羣中，使機器可彼此通訊並協同工做，以高度分佈式的方式共同存儲和處理大量數據。最初，Hadoop 包含如下兩個主要組件：Hadoop Distributed File System (HDFS) 和一個分佈式計算引擎，該引擎支持以 MapReduce 做業的形式實現和運行程序。
MapReduce 是 Google 推廣的一個簡單的編程模型，它對以高度並行和可擴展的方式處理大數據集頗有用。MapReduce 的靈感來源於函數式編程，用戶可將他們的計算表達爲 map 和 reduce 函數，將數據做爲鍵值對來處理。Hadoop 提供了一個高級 API 來在各類語言中實現自定義的 map 和 reduce 函數。
Hadoop 還提供了軟件基礎架構，以一系列 map 和 reduce 任務的形式運行 MapReduce 做業。Map 任務 在輸入數據的子集上調用 map 函數。在完成這些調用後，reduce 任務 開始在 map 函數所生成的中間數據上調用 reduce 任務，生成最終的輸出。 map 和 reduce 任務彼此單獨運行，這支持並行和容錯的計算。
最重要的是，Hadoop 基礎架構負責處理分佈式處理的全部複雜方面：並行化、調度、資源管理、機器間通訊、軟件和硬件故障處理，等等。得益於這種乾淨的抽象，實現處理數百（或者甚至數千）個機器上的數 TB 數據的分佈式應用程序從未像如今這麼容易過，甚至對於以前沒有使用分佈式系統的經驗的開發人員也是如此。
MR架構

將任務分割爲 Map 端和 reduce 端。

JobClient JobTracker TaskTracker

1. JobClient 向 JobTracker 請求一個新的 jobID
2. 檢查做業輸出說明
3. 計算做業輸出劃分split
4. 將運行做業所須要的資源（做業的jar文件、配置文件、計算所得的輸入劃分）複製到一個以做業ID命名的目錄中JobTracker的文件系統。
5. 經過調用JobTracker的submitJob()方法，告訴JobTracker做業準備執行
6. JobTracker接收到submitJob()方法調用後，把此調用放到一個內部隊列中，交由做業調度器進行調度，並對其進行初始化
7. 建立運行任務列表，做業調度去首先從共享文件系統中獲取JobClient已經計算好的輸入劃分信息（圖中step6），而後爲每一個劃分建立一個Map任務（一個split對應一個map，有多少split就有多少map）。
8. TaskTracker執行一個簡單的循環，按期發送心跳（heartbeat）調用JobTracker

shuffle combine

總體的Shuffle過程包含如下幾個部分：Map端Shuffle、Sort階段、Reduce端Shuffle。便是說：Shuffle 過程橫跨 map 和 reduce 兩端，中間包含 sort 階段，就是數據從 map task 輸出到reduce task輸入的這段過程。

sort、combine 是在 map 端的，combine 是提早的 reduce ，須要本身設置。

Hadoop 集羣中，大部分 map task 與 reduce task 的執行是在不一樣的節點上。固然不少狀況下 Reduce 執行時須要跨節點去拉取其它節點上的map task結果。若是集羣正在運行的 job 有不少，那麼 task 的正常執行對集羣內部的網絡資源消耗會很嚴重。而對於必要的網絡資源消耗，最終的目的就是最大化地減小沒必要要的消耗。還有在節點內，相比於內存，磁盤 IO 對 job 完成時間的影響也是可觀的。從最基本的要求來講，對於 MapReduce 的 job 性能調優的 Shuffle 過程，目標指望能夠有：

• 完整地從map task端拉取數據到reduce 端。
• 在跨節點拉取數據時，儘量地減小對帶寬的沒必要要消耗。
• 減小磁盤IO對task執行的影響。

整體來說這段Shuffle過程，能優化的地方主要在於減小拉取數據的量及儘可能使用內存而不是磁盤。

Map Shuffle

• 輸入
  在map task 執行時，其輸入來源 HDFS的 block ，map task 只讀取split 。Split 與 block 的對應關係多是多對一，默認爲一對一。

• 切分
  決定於當前的 mapper的 part交給哪一個 reduce的方法是：mapreduce 提供的Partitioner接口，對key 進行 hash 後，再以 reducetask 數量取模，而後到指定的 job 上。
  而後將數據寫入內存緩衝區中，緩衝區的做用是批量收集map結果，減小磁盤IO的影響。key/value對以及 Partition 的結果都會被寫入緩衝區。寫入以前，key 與value 值都會被序列化成字節數組。

• 溢寫
  因爲內存緩衝區的大小限制（默認100MB），當map task輸出結果不少時就可能發生內存溢出，因此須要在必定條件下將緩衝區的數據臨時寫入磁盤，而後從新利用這塊緩衝區。這個從內存往磁盤寫數據的過程被稱爲Spill，中文可譯爲溢寫。
  這個溢寫是由另外單獨線程來完成，不影響往緩衝區寫map結果的線程。
  整個緩衝區有個溢寫的比例spill.percent。這個比例默認是0.8

• Combiner 將有相同key的 key/value 對加起來，減小溢寫spill到磁盤的數據量。Combiner的適用場景：因爲Combiner的輸出是Reducer的輸入，Combiner毫不能改變最終的計算結果。故大多數狀況下，combiner適用於輸入輸出的key/value類型徹底一致，且不影響最終結果的場景（好比累加、最大值等……）。

1. Merge
   map 很大時，每次溢寫會產生一個 spill_file，這樣會有多個 spill_file，而最終的輸出只有一個文件，在最終輸出以前會對多箇中間過程屢次產生的溢寫文件 spill_file 進行合併，此過程就是 merge。

merge 就是把相同 key 的結果加起來。（固然，若是設置過combiner，也會使用combiner來合併相同的key）

 Reduce Shuffle

在 reduce task 以前，不斷拉取當前 job 裏每一個 maptask 的最終結果，而後對從不一樣地方拉取過來的數據不斷地作 merge ，也最終造成一個文件做爲 reduce task 的輸入文件。

1. copy
   Reduce進程啓動一些數據copy線程(Fetcher)，經過HTTP方式請求map task所在的TaskTracker獲取map task的輸出文件。由於maptask早已結束，這些文件就歸TaskTracker管理在本地磁盤中。

2. merge
   Copy 過來的數據會先放入內存緩衝區中，這裏的緩衝區大小要比 map 端的更爲靈活，它基於 JVM 的 heap size 設置，由於 Shuffle 階段 Reducer 不運行，因此應該把絕大部分的內存都給 Shuffle 用。這裏須要強調的是，merge 有三種形式：1)內存到內存 2)內存到磁盤 3)磁盤到磁盤。默認狀況下第一種形式不啓用，讓人比較困惑，是吧。當內存中的數據量到達必定閾值，就啓動內存到磁盤的 merge 。與 map 端相似，這也是溢寫的過程，這個過程當中若是你設置有Combiner，也是會啓用的，而後在磁盤中生成了衆多的溢寫文件。第二種merge方式一直在運行，直到沒有 map 端的數據時才結束，而後啓動第三種磁盤到磁盤的 merge 方式生成最終的那個文件。

3. reducer的輸入
   merge 的最後會生成一個文件，大多數狀況下存在於磁盤中，可是須要將其放入內存中。當reducer 輸入文件已定，整個 Shuffle 階段纔算結束。而後就是 Reducer 執行，把結果放到 HDFS 上。

YARN

YARN（Yet Another Resource Negotiator）,下一代MapReduce框架的名稱，爲了容易記憶，通常稱爲MRv2（MapReduce version 2）。該框架已經再也不是一個傳統的MapReduce框架，甚至與MapReduce無關，她是一個通用的運行時框架，用戶能夠編寫本身的計算框架，在該運行環境中運行。用於本身編寫的框架做爲客戶端的一個lib，在運用提交做業時打包便可。

why YARN instead of MR

MR 的缺點

經典 MapReduce 的最嚴重的限制主要關係到可伸縮性、資源利用和對與 MapReduce 不一樣的工做負載的支持。在 MapReduce 框架中，做業執行受兩種類型的進程控制：

• 一個稱爲 JobTracker 的主要進程，它協調在集羣上運行的全部做業，分配要在 TaskTracker 上運行的 map 和 reduce 任務。
• 許多稱爲 TaskTracker 的下級進程，它們運行分配的任務並按期向 JobTracker 報告進度。

大型的 Hadoop 集羣顯現出了由單個 JobTracker 致使的可伸縮性瓶頸。
此外，較小和較大的 Hadoop 集羣都從未最高效地使用他們的計算資源。在 Hadoop MapReduce 中，每一個從屬節點上的計算資源由集羣管理員分解爲固定數量的 map 和 reduce slot，這些 slot 不可替代。設定 map slot 和 reduce slot 的數量後，節點在任什麼時候刻都不能運行比 map slot 更多的 map 任務，即便沒有 reduce 任務在運行。這影響了集羣的利用率，由於在全部 map slot 都被使用（並且咱們還須要更多）時，咱們沒法使用任何 reduce slot，即便它們可用，反之亦然。
Hadoop 設計爲僅運行 MapReduce 做業。隨着替代性的編程模型（好比 Apache Giraph 所提供的圖形處理）的到來，除 MapReduce 外，愈來愈須要爲可經過高效的、公平的方式在同一個集羣上運行並共享資源的其餘編程模型提供支持。

原MapReduce框架的不足

• JobTracker是集羣事務的集中處理點，存在單點故障
• JobTracker須要完成的任務太多，既要維護job的狀態又要維護job的task的狀態，形成過多的資源消耗
• 在taskTracker端，用map/reduce task做爲資源的表示過於簡單，沒有考慮到CPU、內存等資源狀況，當把兩個須要消耗大內存的task調度到一塊兒，很容易出現OOM
• 把資源強制劃分爲map/reduce slot,當只有map task時，reduce slot不能用；當只有reduce task時，map slot不能用，容易形成資源利用不足。

解決可伸縮性問題

在 Hadoop MapReduce 中，JobTracker 具備兩種不一樣的職責：

• 管理集羣中的計算資源，這涉及到維護活動節點列表、可用和佔用的 map 和 reduce slots 列表，以及依據所選的調度策略將可用 slots 分配給合適的做業和任務
• 協調在集羣上運行的全部任務，這涉及到指導 TaskTracker 啓動 map 和 reduce 任務，監視任務的執行，從新啓動失敗的任務，推測性地運行緩慢的任務，計算做業計數器值的總和，等等

爲單個進程安排大量職責會致使重大的可伸縮性問題，尤爲是在較大的集羣上，JobTracker 必須不斷跟蹤數千個 TaskTracker、數百個做業，以及數萬個 map 和 reduce 任務。相反，TaskTracker 一般近運行十來個任務，這些任務由勤勉的 JobTracker 分配給它們。

爲了解決可伸縮性問題，一個簡單而又絕妙的想法應運而生：咱們減小了單個 JobTracker 的職責，將部分職責委派給 TaskTracker，由於集羣中有許多 TaskTracker。在新設計中，這個概念經過將 JobTracker 的雙重職責（集羣資源管理和任務協調）分開爲兩種不一樣類型的進程來反映。

YARN 的優勢

1. 更快地MapReduce計算
2. 對多框架支持
3. 框架升級更容易

YARN

• ResourceManager 代替集羣管理器
• ApplicationMaster 代替一個專用且短暫的 JobTracker
• NodeManager 代替 TaskTracker
• 一個分佈式應用程序代替一個 MapReduce 做業

一個全局 ResourceManager 以主要後臺進程的形式運行，它一般在專用機器上運行，在各類競爭的應用程序之間仲裁可用的集羣資源。
在用戶提交一個應用程序時，一個稱爲 ApplicationMaster 的輕量型進程實例會啓動來協調應用程序內的全部任務的執行。這包括監視任務，從新啓動失敗的任務，推測性地運行緩慢的任務，以及計算應用程序計數器值的總和。有趣的是，ApplicationMaster 可在容器內運行任何類型的任務。
NodeManager 是 TaskTracker 的一種更加普通和高效的版本。沒有固定數量的 map 和 reduce slots，NodeManager 擁有許多動態建立的資源容器。

感興趣能夠加Java架構師羣獲取Java工程化、高性能及分佈式、高性能、深刻淺出。高架構。性能調優、Spring，MyBatis，Netty源碼分析和大數據等多個知識點高級進階乾貨的直播免費學習權限 都是大牛帶飛 讓你少走不少的彎路的 羣..號是：855801563 對了 小白勿進 最好是有開發經驗

注：加羣要求

一、具備工做經驗的，面對目前流行的技術不知從何下手，須要突破技術瓶頸的能夠加。

二、在公司待久了，過得很安逸，但跳槽時面試碰壁。須要在短期內進修、跳槽拿高薪的能夠加。

三、若是沒有工做經驗，但基礎很是紮實，對java工做機制，經常使用設計思想，經常使用java開發框架掌握熟練的，能夠加。

四、以爲本身很牛B，通常需求都能搞定。可是所學的知識點沒有系統化，很難在技術領域繼續突破的能夠加。

5.阿里Java高級大牛直播講解知識點，分享知識，多年工做經驗的梳理和總結，帶着你們全面、科學地創建本身的技術體系和技術認知！