大數據面試殺招——Hadoop高頻考點，正在刷新你的認知！

一、什麼是Hadoop？

    這是一個看着不起眼，實則“送命題”的典型。往往大家關於大數據的其他內容準備得非常充分，反倒問你什麼是Hadoop卻有點猝不及防，回答磕磕絆絆，給面試官的印象就很不好。另外，回答這個問題，一定要從事物本身上升到廣義去介紹。面試官往往通過這個問題來判斷你是否具有最基本的認知能力。

    Hadoop是一個能夠對大量數據進行分佈式處理的軟件框架。以一種可靠、高效、可伸縮的方式進行數據處理。主要包括三部分內容：*Hdfs，MapReduce，Yarn*

    Hadoop在廣義上指一個生態圈，泛指大數據技術相關的開源組件或產品，如HBase，Hive，Spark，Zookeeper，Kafka，flume…

二、能跟我介紹下Hadoop和Spark的差異嗎？

    被問到也不要驚訝，面試官往往通過你對於不同技術的差異描述，就能看出你是不是真的具有很強的學習能力。

	Hadoop	Spark
類型	基礎平臺，包含計算，存儲，調度	分佈式計算工具
場景	大規模數據集上的批處理	迭代計算，交互式計算，流計算
價格	對機器要求低，便宜	對內存有要求，相對較貴
編程範式	MapReduce，API 較爲底層，算法適應性差	RDD組成DAG有向無環圖，API較爲頂層，方便使用
數據存儲結構	MapReduce中間計算結果存在HDFS磁盤上，延遲大	RDD中間運算結果存在內存中，延遲小
運行方式	Task以進程方式維護，任務啓動慢	Task以線程方式維護，任務啓動快

三、Hadoop常見的版本有哪些，分別有哪些特點，你一般是如何進行選擇的?

    這個完全就是基於個人的經驗之談的，如果平時沒有細緻研究過這些，這個問題一定是答不好的。

    由於Hadoop的飛速發展，功能不斷更新和完善，Hadoop的版本非常多，同時也顯得雜亂。目前市面上，主流的是以下幾個版本：

• Apache 社區版本

  Apache 社區版本 完全開源，免費，是非商業版本。Apache社區的Hadoop版本分支較多，而且部分Hadoop存在Bug。在選擇Hadoop、Hbase、Hive等時，需要考慮兼容性。同時，這個版本的Hadoop的部署對Hadoop開發人員或運維人員的技術要求比較高。
  

• Cloudera版本

  Cloudera 版本 開源，免費，有商業版和非商業版本，是在Apache社區版本的Hadoop基礎上，選擇相對穩定版本的Hadoop，進行開發和維護的Hadoop版本。由於此版本的Hadoop在開發過程中對其他的框架的集成進行了大量的兼容性測試，因此使用者不必考慮Hadoop、Hbase、Hive等在使用過程中版本的兼容性問題，大大節省了使用者在調試兼容性方面的時間成本。
  

• Hortonworks版本

  Hortonworks 版本 的 Hadoop 開源、免費，有商業和非商業版本，其在 Apache 的基礎上修改，對相關的組件或功能進行了二次開發，其中商業版本的功能是最強大，最齊全的。
  
  所以基於以上特點進行選擇，我們一般剛接觸大數據用的就是CDH，在工作中大概率用 Apache 或者 Hortonworks。
  

四、能簡單介紹Hadoop1.0，2.0，3.0的區別嗎？

    一般能問出這種問題的面試官都是“狠人”，基本技術都不差，他們往往是更希望應聘者能在這些“細節”問題上脫穎而出。

    Hadoop1.0由分佈式存儲系統HDFS和分佈式計算框架MapReduce組成，其中HDFS由一個NameNode和多個DateNode組成，MapReduce由一個JobTracker和多個TaskTracker組成。在Hadoop1.0中容易導致單點故障，拓展性差，性能低，支持編程模型單一的問題。

    Hadoop2.0即爲克服Hadoop1.0中的不足，提出了以下關鍵特性：

• Yarn：它是Hadoop2.0引入的一個全新的通用資源管理系統，完全代替了Hadoop1.0中的JobTracker。在MRv1 中的 JobTracker 資源管理和作業跟蹤的功能被抽象爲 ResourceManager 和 AppMaster 兩個組件。Yarn 還支持多種應用程序和框架，提供統一的資源調度和管理功能

• NameNode 單點故障得以解決：Hadoop2.2.0 同時解決了 NameNode 單點故障問題和內存受限問題，並提供 NFS，QJM 和 Zookeeper 三種可選的共享存儲系統

• HDFS 快照：指 HDFS（或子系統）在某一時刻的只讀鏡像，該只讀鏡像對於防止數據誤刪、丟失等是非常重要的。例如，管理員可定時爲重要文件或目錄做快照，當發生了數據誤刪或者丟失的現象時，管理員可以將這個數據快照作爲恢復數據的依據

• 支持Windows 操作系統：Hadoop 2.2.0 版本的一個重大改進就是開始支持 Windows 操作系統

• Append：新版本的 Hadoop 引入了對文件的追加操作

  同時，新版本的Hadoop對於HDFS做了兩個非常重要的**增強**，分別是支持異構的存儲層次和通過數據節點爲存儲在HDFS中的數據提供內存緩衝功能
  
  相比於Hadoop2.0，Hadoop3.0 是直接基於 JDK1.8 發佈的一個新版本，同時，Hadoop3.0引入了一些重要的功能和特性
  

• HDFS可擦除編碼：這項技術使HDFS在不降低可靠性的前提下節省了很大一部分存儲空間

• 多NameNode支持：在Hadoop3.0中，新增了對多NameNode的支持。當然，處於Active狀態的NameNode實例必須只有一個。也就是說，從Hadoop3.0開始，在同一個集羣中，支持一個 ActiveNameNode 和 多個 StandbyNameNode 的部署方式。

• MR Native Task優化

• Yarn基於cgroup 的內存和磁盤 I/O 隔離

• Yarn container resizing

  限於篇幅原因，這還都只是部分特性，大家多注意菌哥標記顏色的部分，就足以應對面試了。
  

五、說下Hadoop常用的端口號

    Hadoop常用的端口號總共就那麼幾個，大家選擇好記的幾個就OK了

• dfs.namenode.http-address:50070
• dfs.datanode.http-address:50075
• SecondaryNameNode：50090
• dfs.datanode.address:50010
• fs.defaultFS:8020 或者9000
• yarn.resourcemanager.webapp.address:8088
• 歷史服務器web訪問端口：19888

六、簡單介紹一下搭建Hadoop集羣的流程

    這個問題實在基礎，這裏也簡單概述下。

    在正式搭建之前，我們需要準備以下6步：

準備工作

1. 關閉防火牆
2. 關閉SELINUX
3. 修改主機名
4. ssh無密碼拷貝數據
5. 設置主機名和IP對應
6. jdk1.8安裝

搭建工作:

• 下載並解壓Hadoop的jar包
• 配置hadoop的核心文件
• 格式化namenode
• 啓動…

七、介紹一下HDFS讀寫流程

    這個問題非常基礎，同時出現的頻率也是異常的高，但是大家也不要被HDFS的讀寫流程嚇到。相信看到這裏的朋友，應該不是第一次背HDFS讀寫繁多的步驟了，菌哥在這裏也不建議大家去背那些文字，這裏貼上兩張圖，大家要學會做到心中有圖，萬般皆易。

• HDFS讀數據流程

• HDFS的寫數據流程

  
  

八、介紹一下MapReduce的Shuffle過程，並給出Hadoop優化的方案(包括：壓縮、小文件、集羣的優化)

    MapReduce數據讀取並寫入HDFS流程實際上是有10步

    其中最重要，也是最不好講的就是 shuffle 階段，當面試官着重要求你介紹 Shuffle 階段時，可就不能像上邊圖上寫的那樣簡單去介紹了。

    你可以這麼說：

    1) Map方法之後Reduce方法之前這段處理過程叫**Shuffle**

    2) Map方法之後，數據首先進入到分區方法，把數據標記好分區，然後把數據發送到環形緩衝區；環形緩衝區默認大小100m，環形緩衝區達到80%時，進行溢寫；溢寫前對數據進行排序，排序按照對key的索引進行字典順序排序，排序的手段**快排**；溢寫產生大量溢寫文件，需要對溢寫文件進行**歸併排序**；對溢寫的文件也可以進行Combiner操作，前提是彙總操作，求平均值不行。最後將文件按照分區存儲到磁盤，等待Reduce端拉取。

    3）每個Reduce拉取Map端對應分區的數據。拉取數據後先存儲到內存中，內存不夠了，再存儲到磁盤。拉取完所有數據後，採用歸併排序將內存和磁盤中的數據都進行排序。在進入Reduce方法前，可以對數據進行分組操作。

講到這裏你可能已經口乾舌燥，想緩一緩。
但面試官可能對你非常欣賞：
小夥幾，看來你對MapReduce的Shuffle階段掌握很透徹啊，那你跟我再介紹一下你是如何基於MapReduce做Hadoop的優化的，可以給你個提示，可以從壓縮，小文件，集羣優化層面去考慮哦~

可能你心裏彷彿有一萬隻草泥馬在奔騰，但是爲了順利拿下本輪面試，你還是不得不開始思考，如何回答比較好：

1）HDFS小文件影響

• 影響NameNode的壽命，因爲文件元數據存儲在NameNode的內存中
• 影響計算引擎的任務數量，比如每個小的文件都會生成一個Map任務

2）數據輸入小文件處理

• 合併小文件：對小文件進行歸檔（Har）、自定義Inputformat將小文件存儲成SequenceFile文件。
• 採用ConbinFileInputFormat來作爲輸入，解決輸入端大量小文件場景
• 對於大量小文件Job，可以開啓JVM重用

3）Map階段

• 增大環形緩衝區大小。由100m擴大到200m
• 增大環形緩衝區溢寫的比例。由80%擴大到90%
• 減少對溢寫文件的merge次數。（10個文件，一次20個merge）
• 不影響實際業務的前提下，採用Combiner提前合併，減少 I/O

4）Reduce階段

• 合理設置Map和Reduce數：兩個都不能設置太少，也不能設置太多。太少，會導致Task等待，延長處理時間；太多，會導致 Map、Reduce任務間競爭資源，造成處理超時等錯誤。
• 設置Map、Reduce共存：調整 slowstart.completedmaps 參數，使Map運行到一定程度後，Reduce也開始運行，減少Reduce的等待時間
• 規避使用Reduce，因爲Reduce在用於連接數據集的時候將會產生大量的網絡消耗。
• 增加每個Reduce去Map中拿數據的並行數
• 集羣性能可以的前提下，增大Reduce端存儲數據內存的大小

5) IO 傳輸

• 採用數據壓縮的方式，減少網絡IO的的時間
• 使用SequenceFile二進制文件

6) 整體

• MapTask默認內存大小爲1G，可以增加MapTask內存大小爲4
• ReduceTask默認內存大小爲1G，可以增加ReduceTask內存大小爲4-5g
• 可以增加MapTask的cpu核數，增加ReduceTask的CPU核數
• 增加每個Container的CPU核數和內存大小
• 調整每個Map Task和Reduce Task最大重試次數

7) 壓縮

    壓縮，可以參考這張圖

[圖片上傳失敗...(image-91591f-1604558885350)]

    **提示**：如果面試過程問起，我們一般回答壓縮方式爲Snappy，特點速度快，缺點無法切分（可以回答在鏈式MR中，Reduce端輸出使用bzip2壓縮，以便後續的map任務對數據進行split）

九、介紹一下 Yarn 的 Job 提交流程

    這裏一共也有兩個版本，分別是詳細版和簡略版，具體使用哪個還是分不同的場合。正常情況下，將簡略版的回答清楚了就很OK，詳細版的最多做個內容的補充：

• 詳細版

  
  

• 簡略版

[圖片上傳失敗...(image-9b8096-1604558885350)]

    其中簡略版對應的步驟分別如下：

1. client向RM提交應用程序，其中包括啓動該應用的ApplicationMaster的必須信息，例如ApplicationMaster程序、啓動ApplicationMaster的命令、用戶程序等
2. ResourceManager啓動一個container用於運行ApplicationMaster
3. 啓動中的ApplicationMaster向ResourceManager註冊自己，啓動成功後與RM保持心跳
4. ApplicationMaster向ResourceManager發送請求,申請相應數目的container
5. 申請成功的container，由ApplicationMaster進行初始化。container的啓動信息初始化後，AM與對應的NodeManager通信，要求NM啓動container
6. NM啓動container
7. container運行期間，ApplicationMaster對container進行監控。container通過RPC協議向對應的AM彙報自己的進度和狀態等信息
8. 應用運行結束後，ApplicationMaster向ResourceManager註銷自己，並允許屬於它的container被收回

十、介紹下Yarn默認的調度器，調度器分類，以及它們之間的區別

    關於Yarn的知識點考察實際上在面試中佔的比重並的不多，像面試中常問的無非就Yarn的Job執行流程或者調度器的分類，答案往往也都差不多，以下回答做個參考：

    1）Hadoop調度器主要分爲三類：

• FIFO Scheduler：先進先出調度器：優先提交的，優先執行，後面提交的等待【生產環境不會使用】
• Capacity Scheduler：容量調度器：允許看創建多個任務對列，多個任務對列可以同時執行。但是一個隊列內部還是先進先出。【Hadoop2.7.2默認的調度器】
• Fair Scheduler：公平調度器：第一個程序在啓動時可以佔用其他隊列的資源（100%佔用），當其他隊列有任務提交時，佔用資源的隊列需要將資源還給該任務。還資源的時候，效率比較慢。【CDH版本的yarn調度器默認】

十一、瞭解過哪些Hadoop的參數優化

    前面剛回答完Hadoop基於壓縮，小文件，IO的集羣優化，現在又要回答參數優化，真的好煩啊(Ｔ▽Ｔ)如果你把自己放在實習生這個level，你 duck 不必研究這麼多關於性能調優這塊的內容，畢竟對於稍有工作經驗的工程師來說，調優這塊是非常重要的

    我們常見的**Hadoop參數調優**有以下幾種：

• 在hdfs-site.xml文件中配置多目錄，最好提前配置好，否則更改目錄需要重新啓動集羣
• NameNode有一個工作線程池，用來處理不同DataNode的併發心跳以及客戶端併發的元數據操作

dfs.namenode.handler.count=20 * log2(Cluster Size)

    比如集羣規模爲10臺時，此參數設置爲60

• 編輯日誌存儲路徑dfs.namenode.edits.dir設置與鏡像文件存儲路徑dfs.namenode.name.dir儘量分開，達到最低寫入延遲
• 服務器節點上YARN可使用的物理內存總量，默認是8192（MB），注意，如果你的節點內存資源不夠8GB，則需要調減小這個值，而YARN不會智能的探測節點的物理內存總量
• 單個任務可申請的最多物理內存量，默認是8192（MB）

十二、瞭解過Hadoop的基準測試嗎?

    這個完全就是基於項目經驗的面試題了，暫時回答不上來的朋友可以留意一下：

    我們搭建完Hadoop集羣后需要對HDFS讀寫性能和MR計算能力測試。測試jar包在hadoop的share文件夾下。

十三、你是怎麼處理Hadoop宕機的問題的?

    相信被問到這裏，一部分的小夥伴已經堅持不下去了

[圖片上傳失敗...(image-c6c351-1604558885350)]

    但言歸正傳，被問到了，我們總不能說俺不知道，灑家不會之類的吧٩(๑❛ᴗ❛๑)۶下面展示一種回答，給大家來個Demo。

    如果MR造成系統宕機。此時要控制Yarn同時運行的任務數，和每個任務申請的最大內存。調整參數：yarn.scheduler.maximum-allocation-mb（單個任務可申請的最多物理內存量，默認是8192MB）。

    如果寫入文件過量造成NameNode宕機。那麼調高Kafka的存儲大小，控制從Kafka到HDFS的寫入速度。高峯期的時候用Kafka進行緩存，高峯期過去數據同步會自動跟上。

十四、你是如何解決Hadoop數據傾斜的問題的，能舉個例子嗎?

    **性能優化**和**數據傾斜**，如果在面試前不好好準備，那就準備在面試時喫虧吧~其實掌握得多了，很多方法都有相通的地方。下面貼出一種靠譜的回答，大家可以借鑑下：

    1）提前在map進行combine，減少傳輸的數據量

    在Mapper加上combiner相當於提前進行reduce，即把一個Mapper中的相同key進行了聚合，減少shuffle過程中傳輸的數據量，以及Reducer端的計算量。

    如果導致數據傾斜的key 大量分佈在不同的mapper的時候，這種方法就不是很有效了

    2）數據傾斜的key 大量分佈在不同的mapper

    在這種情況，大致有如下幾種方法：

• 局部聚合加全局聚合

  第一次在map階段對那些導致了數據傾斜的key 加上1到n的隨機前綴，這樣本來相同的key 也會被分到多個Reducer 中進行局部聚合，數量就會大大降低。
  
  第二次mapreduce，去掉key的隨機前綴，進行全局聚合。
  
  **思想**：二次mr，第一次將key隨機散列到不同 reducer 進行處理達到負載均衡目的。第二次再根據去掉key的隨機前綴，按原key進行reduce處理。
  
  這個方法進行兩次mapreduce，性能稍差。
  

• 增加Reducer，提升並行度

JobConf.setNumReduceTasks(int)

• 實現自定義分區

  根據數據分佈情況，自定義散列函數，將key均勻分配到不同Reducer