一、什么是Hadoop？

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

    Hadoop是一個能夠?qū)Υ罅繑?shù)據(jù)進(jìn)行分布式處理的軟件框架。以一種可靠、高效、可伸縮的方式進(jìn)行數(shù)據(jù)處理。主要包括三部分內(nèi)容：*Hdfs，MapReduce，Yarn*

    Hadoop在廣義上指一個生態(tài)圈，泛指大數(shù)據(jù)技術(shù)相關(guān)的開源組件或產(chǎn)品，如HBase，Hive，Spark，Zookeeper，Kafka，flume…

image.png

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

    被問到也不要驚訝，面試官往往通過你對于不同技術(shù)的差異描述，就能看出你是不是真的具有很強(qiáng)的學(xué)習(xí)能力。

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

    這個完全就是基于個人的經(jīng)驗之談的，如果平時沒有細(xì)致研究過這些，這個問題一定是答不好的。

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

• Apache 社區(qū)版本

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

• Cloudera版本

  Cloudera 版本 開源，免費，有商業(yè)版和非商業(yè)版本，是在Apache社區(qū)版本的Hadoop基礎(chǔ)上，選擇相對穩(wěn)定版本的Hadoop，進(jìn)行開發(fā)和維護(hù)的Hadoop版本。由于此版本的Hadoop在開發(fā)過程中對其他的框架的集成進(jìn)行了大量的兼容性測試，因此使用者不必考慮Hadoop、Hbase、Hive等在使用過程中版本的兼容性問題，大大節(jié)省了使用者在調(diào)試兼容性方面的時間成本。
  

• Hortonworks版本

  Hortonworks 版本 的 Hadoop 開源、免費，有商業(yè)和非商業(yè)版本，其在 Apache 的基礎(chǔ)上修改，對相關(guān)的組件或功能進(jìn)行了二次開發(fā)，其中商業(yè)版本的功能是最強(qiáng)大，最齊全的。
  
  所以基于以上特點進(jìn)行選擇，我們一般剛接觸大數(shù)據(jù)用的就是CDH，在工作中大概率用 Apache 或者 Hortonworks。
  

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

    一般能問出這種問題的面試官都是“狠人”，基本技術(shù)都不差，他們往往是更希望應(yīng)聘者能在這些“細(xì)節(jié)”問題上脫穎而出。

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

    Hadoop2.0即為克服Hadoop1.0中的不足，提出了以下關(guān)鍵特性：

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

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

• HDFS 快照：指 HDFS（或子系統(tǒng)）在某一時刻的只讀鏡像，該只讀鏡像對于防止數(shù)據(jù)誤刪、丟失等是非常重要的。例如，管理員可定時為重要文件或目錄做快照，當(dāng)發(fā)生了數(shù)據(jù)誤刪或者丟失的現(xiàn)象時，管理員可以將這個數(shù)據(jù)快照作為恢復(fù)數(shù)據(jù)的依據(jù)

• 支持Windows 操作系統(tǒng)：Hadoop 2.2.0 版本的一個重大改進(jìn)就是開始支持 Windows 操作系統(tǒng)

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

  同時，新版本的Hadoop對于HDFS做了兩個非常重要的**增強(qiáng)**，分別是支持異構(gòu)的存儲層次和通過數(shù)據(jù)節(jié)點為存儲在HDFS中的數(shù)據(jù)提供內(nèi)存緩沖功能
  
  相比于Hadoop2.0，Hadoop3.0 是直接基于 JDK1.8 發(fā)布的一個新版本，同時，Hadoop3.0引入了一些重要的功能和特性
  

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

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

• MR Native Task優(yōu)化

• Yarn基于cgroup 的內(nèi)存和磁盤 I/O 隔離

• Yarn container resizing

  限于篇幅原因，這還都只是部分特性，大家多注意菌哥標(biāo)記顏色的部分，就足以應(yīng)對面試了。
  

五、說下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
• 歷史服務(wù)器web訪問端口：19888

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

    這個問題實在基礎(chǔ)，這里也簡單概述下。

    在正式搭建之前，我們需要準(zhǔn)備以下6步：

準(zhǔn)備工作

1. 關(guān)閉防火墻
2. 關(guān)閉SELINUX
3. 修改主機(jī)名
4. ssh無密碼拷貝數(shù)據(jù)
5. 設(shè)置主機(jī)名和IP對應(yīng)
6. jdk1.8安裝

搭建工作:

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

七、介紹一下HDFS讀寫流程

    這個問題非?；A(chǔ)，同時出現(xiàn)的頻率也是異常的高，但是大家也不要被HDFS的讀寫流程嚇到。相信看到這里的朋友，應(yīng)該不是第一次背HDFS讀寫繁多的步驟了，菌哥在這里也不建議大家去背那些文字，這里貼上兩張圖，大家要學(xué)會做到心中有圖，萬般皆易。

• HDFS讀數(shù)據(jù)流程

在這里插入圖片描述

• HDFS的寫數(shù)據(jù)流程

  
  
  在這里插入圖片描述

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

    MapReduce數(shù)據(jù)讀取并寫入HDFS流程實際上是有10步

在這里插入圖片描述

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

    你可以這么說：

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

    2) Map方法之后，數(shù)據(jù)首先進(jìn)入到分區(qū)方法，把數(shù)據(jù)標(biāo)記好分區(qū)，然后把數(shù)據(jù)發(fā)送到環(huán)形緩沖區(qū)；環(huán)形緩沖區(qū)默認(rèn)大小100m，環(huán)形緩沖區(qū)達(dá)到80%時，進(jìn)行溢寫；溢寫前對數(shù)據(jù)進(jìn)行排序，排序按照對key的索引進(jìn)行字典順序排序，排序的手段**快排**；溢寫產(chǎn)生大量溢寫文件，需要對溢寫文件進(jìn)行**歸并排序**；對溢寫的文件也可以進(jìn)行Combiner操作，前提是匯總操作，求平均值不行。最后將文件按照分區(qū)存儲到磁盤，等待Reduce端拉取。

    3）每個Reduce拉取Map端對應(yīng)分區(qū)的數(shù)據(jù)。拉取數(shù)據(jù)后先存儲到內(nèi)存中，內(nèi)存不夠了，再存儲到磁盤。拉取完所有數(shù)據(jù)后，采用歸并排序?qū)?nèi)存和磁盤中的數(shù)據(jù)都進(jìn)行排序。在進(jìn)入Reduce方法前，可以對數(shù)據(jù)進(jìn)行分組操作。

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

image.png

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

1）HDFS小文件影響

• 影響NameNode的壽命，因為文件元數(shù)據(jù)存儲在NameNode的內(nèi)存中
• 影響計算引擎的任務(wù)數(shù)量，比如每個小的文件都會生成一個Map任務(wù)

2）數(shù)據(jù)輸入小文件處理

• 合并小文件：對小文件進(jìn)行歸檔（Har）、自定義Inputformat將小文件存儲成SequenceFile文件。
• 采用ConbinFileInputFormat來作為輸入，解決輸入端大量小文件場景
• 對于大量小文件Job，可以開啟JVM重用

3）Map階段

• 增大環(huán)形緩沖區(qū)大小。由100m擴(kuò)大到200m
• 增大環(huán)形緩沖區(qū)溢寫的比例。由80%擴(kuò)大到90%
• 減少對溢寫文件的merge次數(shù)。（10個文件，一次20個merge）
• 不影響實際業(yè)務(wù)的前提下，采用Combiner提前合并，減少 I/O

4）Reduce階段

• 合理設(shè)置Map和Reduce數(shù)：兩個都不能設(shè)置太少，也不能設(shè)置太多。太少，會導(dǎo)致Task等待，延長處理時間；太多，會導(dǎo)致 Map、Reduce任務(wù)間競爭資源，造成處理超時等錯誤。
• 設(shè)置Map、Reduce共存：調(diào)整 slowstart.completedmaps 參數(shù)，使Map運行到一定程度后，Reduce也開始運行，減少Reduce的等待時間
• 規(guī)避使用Reduce，因為Reduce在用于連接數(shù)據(jù)集的時候?qū)a(chǎn)生大量的網(wǎng)絡(luò)消耗。
• 增加每個Reduce去Map中拿數(shù)據(jù)的并行數(shù)
• 集群性能可以的前提下，增大Reduce端存儲數(shù)據(jù)內(nèi)存的大小

5) IO 傳輸

• 采用數(shù)據(jù)壓縮的方式，減少網(wǎng)絡(luò)IO的的時間
• 使用SequenceFile二進(jìn)制文件

6) 整體

• MapTask默認(rèn)內(nèi)存大小為1G，可以增加MapTask內(nèi)存大小為4
• ReduceTask默認(rèn)內(nèi)存大小為1G，可以增加ReduceTask內(nèi)存大小為4-5g
• 可以增加MapTask的cpu核數(shù)，增加ReduceTask的CPU核數(shù)
• 增加每個Container的CPU核數(shù)和內(nèi)存大小
• 調(diào)整每個Map Task和Reduce Task最大重試次數(shù)

7) 壓縮

    壓縮，可以參考這張圖

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

    **提示**：如果面試過程問起，我們一般回答壓縮方式為Snappy，特點速度快，缺點無法切分（可以回答在鏈?zhǔn)組R中，Reduce端輸出使用bzip2壓縮，以便后續(xù)的map任務(wù)對數(shù)據(jù)進(jìn)行split）

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

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

• 詳細(xì)版

  
  
  在這里插入圖片描述

• 簡略版

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

    其中簡略版對應(yīng)的步驟分別如下：

1. client向RM提交應(yīng)用程序，其中包括啟動該應(yīng)用的ApplicationMaster的必須信息，例如ApplicationMaster程序、啟動ApplicationMaster的命令、用戶程序等
2. ResourceManager啟動一個container用于運行ApplicationMaster
3. 啟動中的ApplicationMaster向ResourceManager注冊自己，啟動成功后與RM保持心跳
4. ApplicationMaster向ResourceManager發(fā)送請求,申請相應(yīng)數(shù)目的container
5. 申請成功的container，由ApplicationMaster進(jìn)行初始化。container的啟動信息初始化后，AM與對應(yīng)的NodeManager通信，要求NM啟動container
6. NM啟動container
7. container運行期間，ApplicationMaster對container進(jìn)行監(jiān)控。container通過RPC協(xié)議向?qū)?yīng)的AM匯報自己的進(jìn)度和狀態(tài)等信息
8. 應(yīng)用運行結(jié)束后，ApplicationMaster向ResourceManager注銷自己，并允許屬于它的container被收回

十、介紹下Yarn默認(rèn)的調(diào)度器，調(diào)度器分類，以及它們之間的區(qū)別

    關(guān)于Yarn的知識點考察實際上在面試中占的比重并的不多，像面試中常問的無非就Yarn的Job執(zhí)行流程或者調(diào)度器的分類，答案往往也都差不多，以下回答做個參考：

    1）Hadoop調(diào)度器主要分為三類：

• FIFO Scheduler：先進(jìn)先出調(diào)度器：優(yōu)先提交的，優(yōu)先執(zhí)行，后面提交的等待【生產(chǎn)環(huán)境不會使用】
• Capacity Scheduler：容量調(diào)度器：允許看創(chuàng)建多個任務(wù)對列，多個任務(wù)對列可以同時執(zhí)行。但是一個隊列內(nèi)部還是先進(jìn)先出?！綡adoop2.7.2默認(rèn)的調(diào)度器】
• Fair Scheduler：公平調(diào)度器：第一個程序在啟動時可以占用其他隊列的資源（100%占用），當(dāng)其他隊列有任務(wù)提交時，占用資源的隊列需要將資源還給該任務(wù)。還資源的時候，效率比較慢?！綜DH版本的yarn調(diào)度器默認(rèn)】

十一、了解過哪些Hadoop的參數(shù)優(yōu)化

    前面剛回答完Hadoop基于壓縮，小文件，IO的集群優(yōu)化，現(xiàn)在又要回答參數(shù)優(yōu)化，真的好煩啊(Ｔ▽Ｔ)如果你把自己放在實習(xí)生這個level，你 duck 不必研究這么多關(guān)于性能調(diào)優(yōu)這塊的內(nèi)容，畢竟對于稍有工作經(jīng)驗的工程師來說，調(diào)優(yōu)這塊是非常重要的

    我們常見的**Hadoop參數(shù)調(diào)優(yōu)**有以下幾種：

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

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

    比如集群規(guī)模為10臺時，此參數(shù)設(shè)置為60

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

十二、了解過Hadoop的基準(zhǔn)測試嗎?

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

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

十三、你是怎么處理Hadoop宕機(jī)的問題的?

    相信被問到這里，一部分的小伙伴已經(jīng)堅持不下去了

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

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

    如果MR造成系統(tǒng)宕機(jī)。此時要控制Yarn同時運行的任務(wù)數(shù)，和每個任務(wù)申請的最大內(nèi)存。調(diào)整參數(shù)：yarn.scheduler.maximum-allocation-mb（單個任務(wù)可申請的最多物理內(nèi)存量，默認(rèn)是8192MB）。

    如果寫入文件過量造成NameNode宕機(jī)。那么調(diào)高Kafka的存儲大小，控制從Kafka到HDFS的寫入速度。高峰期的時候用Kafka進(jìn)行緩存，高峰期過去數(shù)據(jù)同步會自動跟上。

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

    **性能優(yōu)化**和**數(shù)據(jù)傾斜**，如果在面試前不好好準(zhǔn)備，那就準(zhǔn)備在面試時吃虧吧~其實掌握得多了，很多方法都有相通的地方。下面貼出一種靠譜的回答，大家可以借鑒下：

    1）提前在map進(jìn)行combine，減少傳輸?shù)臄?shù)據(jù)量

    在Mapper加上combiner相當(dāng)于提前進(jìn)行reduce，即把一個Mapper中的相同key進(jìn)行了聚合，減少shuffle過程中傳輸?shù)臄?shù)據(jù)量，以及Reducer端的計算量。

    如果導(dǎo)致數(shù)據(jù)傾斜的key 大量分布在不同的mapper的時候，這種方法就不是很有效了

    2）數(shù)據(jù)傾斜的key 大量分布在不同的mapper

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

• 局部聚合加全局聚合

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

• 增加Reducer，提升并行度

JobConf.setNumReduceTasks(int)

• 實現(xiàn)自定義分區(qū)

  根據(jù)數(shù)據(jù)分布情況，自定義散列函數(shù)，將key均勻分配到不同Reducer