2022大數(shù)據(jù)面試寶典

2022

最新大數(shù)據(jù)面試寶典

目錄

Hadoop6

1.請說下HDFS讀寫流程6

2.HDFS在讀取文件的時候，如果其中一個塊突然損壞了怎么辦7

3.HDFS在上傳文件的時候，如果其中一個DataNode突然掛掉了怎么辦8

4.NameNode在啟動的時候會做哪些操作8

5.SecondaryNameNode了解嗎，它的工作機制是怎樣的9

6.SecondaryNameNode不能恢復(fù)NameNode的全部數(shù)據(jù)，那如何保證NameNode

數(shù)據(jù)存儲安全9

7.在NameNodeHA中，會出現(xiàn)腦裂問題嗎？怎么解決腦裂10

8.小文件過多會有什么危害，如何避免11

9.請說下HDFS的組織架構(gòu)11

10.請說下MR中MapTask的工作機制12

11.請說下MR中ReduceTask的工作機制13

12.請說下MR中Shuffle階段14

13.Shuffle階段的數(shù)據(jù)壓縮機制了解嗎15

14.在寫MR時，什么情況下可以使用規(guī)約15

15.YARN集群的架構(gòu)和工作原理知道多少15

16.YARN的任務(wù)提交流程是怎樣的16

17.YARN的資源調(diào)度三種模型了解嗎17

Hive18

1.Hive內(nèi)部表和外部表的區(qū)別18

2.Hive有索引嗎19

3.運維如何對Hive進行調(diào)度19

4.ORC、Parquet等列式存儲的優(yōu)點20

5.數(shù)據(jù)建模用的哪些模型？21

6.為什么要對數(shù)據(jù)倉庫分層？23

7.使用過Hive解析JSON串嗎23

8.sortby和orderby的區(qū)另!)23

9.數(shù)據(jù)傾斜怎么解決24

10.Hive小文件過多怎么解決24

11.Hive優(yōu)化有哪些26

Spark27

1.Spark的運行流程？27

2.Spark有哪些組件？28

3.Spark中的RDD機制理解嗎？29

4.RDD中reduceBykey與groupByKey哪個性能好，為什么？29

5.介紹一下cogrouprdd實現(xiàn)原理，你在什么場景下用過這個rdd?30

6.如何區(qū)分RDD的寬窄依賴？30

7.為什么要設(shè)計寬窄依賴？30

8.DAG是什么？31

9.DAG中為什么要劃分Stage?31

10.如何劃分DAG的stage?31

11.DAG劃分為Stage的算法了解嗎？31

12.對于Spark中的數(shù)據(jù)傾斜問題你有什么好的方案？32

13.Spark中的00M問題？32

14.Spark中數(shù)據(jù)的位置是被誰管理的？33

15.Spaek程序執(zhí)行，有時候默認(rèn)為什么會產(chǎn)生很多task,怎么修改默認(rèn)

task執(zhí)行個數(shù)？33

16.介紹一下join操作優(yōu)化經(jīng)驗？34

17.Spark與MapReduce的Shuffle的區(qū)別？34

18.SparkSQL執(zhí)行的流程？35

19.SparkSQL是如何將數(shù)據(jù)寫到Hive表的？35

20.通常來說，Spark與MapReduce相比，Spark運行效率更高。請說明效

率更高來源于Spark內(nèi)置的哪些機制？36

21.Hadoop和Spark的相同點和不同點？36

22.Hadoop和Spark使用場景?37

23.Spark如何保證宕機迅速恢復(fù)?37

24.RDD持久化原理？37

25.Checkpoint檢查點機制？37

26.Checkpoint和持久化機制的區(qū)別？38

27.SparkStreaming以及基本工作原理？38

28.DStream以及基本工作原理？39

29.SparkStreaming整合Kafka的兩種模式？39

30.Spark主備切換機制原理知道嗎？41

31.Spark解決了Hadoop的哪些問題？41

32.數(shù)據(jù)傾斜的產(chǎn)生和解決辦法？42

33.你用SparkSql處理的時候，處理過程中用的DataFrame還是直接寫

的Sql?為什么？42

34.SparkMasterHA主從切換過程不會影響到集群已有作業(yè)的運行，為什

么？42

35.SparkMaster使用Zookeeper進行HA,有哪些源數(shù)據(jù)保存到

Zookeeper里面？43

36.如何實現(xiàn)SparkStreaming讀取Flume中的數(shù)據(jù)？43

37.在實際開發(fā)的時候是如何保證數(shù)據(jù)不丟失的？43

38.RDD有哪些缺陷？44

Kafka44

1.為什么要使用kafka?45

2.Kafka消費過的消息如何再消費？45

3.kafka的數(shù)據(jù)是放在磁盤上還是內(nèi)存上，為什么速度會快？46

4.Kafka數(shù)據(jù)怎么保障不丟失？46

5.采集數(shù)據(jù)為什么選擇kafka?48

6.kafka重啟是否會導(dǎo)致數(shù)據(jù)丟失？48

7.kafka宕機了如何解決？48

8.為什么Kafka不支持讀寫分離？49

9.kafka數(shù)據(jù)分區(qū)和消費者的關(guān)系？49

10.kafka的數(shù)據(jù)offset讀取流程49

11.kafka內(nèi)部如何保證順序，結(jié)合外部組件如何保證消費者的順序？50

12.Kafka消息數(shù)據(jù)積壓，Kafka消費能力不足怎么處理？50

13.Kafka單條日志傳輸大小50

Hbase51

1.Hbase是怎么寫數(shù)據(jù)的？51

2.HDFS和HBase各自使用場景51

3.Hbase的存儲結(jié)構(gòu)52

4.熱點現(xiàn)象（數(shù)據(jù)傾斜）怎么產(chǎn)生的，以及解決方法有哪些52

5.HBase的rowkey設(shè)計原則54

6.HBase的歹U簇設(shè)計54

7.HBase中compact用途是什么，什么時候觸發(fā)，分為哪兩種，有什么區(qū)

別54

Flink55

1.簡單介紹一下Flink55

2.Flink的運行必須依賴Hadoop組件嗎55

3.Flink集群運行時角色56

4.Flink相比SparkStreaming有什么區(qū)另I]57

5.介紹下Flink的容錯機制（checkpoint）57

6.Flinkcheckpoint與SparkStreaming的有什么區(qū)別或優(yōu)勢嗎59

7.Flink是如何保證Exactly-once語義的59

8.如果下級存儲不支持事務(wù)，F(xiàn)link怎么保證exactly-once60

9.Flink常用的算子有哪些60

10.Flink任務(wù)延時高，如何入手60

11.Flink是如何處理反壓的61

12.如何排查生產(chǎn)環(huán)境中的反壓問題61

13.Flink中的狀態(tài)存儲62

14.OperatorChains（算子鏈）這個概念你了解嗎62

15.Flink的內(nèi)存管理是如何做的62

16.如何處理生產(chǎn)環(huán)境中的數(shù)據(jù)傾斜問題63

17.Flink中的Time有哪幾種63

18.Flink對于遲到數(shù)據(jù)是怎么處理的64

19.Flink中window出現(xiàn)數(shù)據(jù)傾斜怎么解決65

20.FlinkCEP編程中當(dāng)狀態(tài)沒有到達(dá)的時候會將數(shù)據(jù)保存在哪里65

21.Flink設(shè)置并行度的方式65

22.Flink中Task如何做到數(shù)據(jù)交換66

23.Flink的內(nèi)存管理是如何做的66

24.介紹下Flink的序列化66

25.Flink海量數(shù)據(jù)高效去重67

26.FlinkSQL的是如何實現(xiàn)的67

業(yè)務(wù)方面68

1.ODS層采用什么壓縮方式和存儲格式？68

2.DWD層做了哪些事？68

3.DWS層做了哪些事？68

1.在處理大數(shù)據(jù)過程中，如何保證得到期望值69

2.你感覺數(shù)倉建設(shè)中最重要的是什么69

3.數(shù)據(jù)倉庫建模怎么做的69

4.數(shù)據(jù)質(zhì)量怎么監(jiān)控69

5.數(shù)據(jù)分析方法論了解過哪些？70

算法71

1.排序算法71

2.查找算法74

3.二叉樹實現(xiàn)及遍歷76

最后78

此套面試題來自于各大廠的真實面試題及常問的知識點，如果能理解吃透這些問題,

你的大數(shù)據(jù)能力將會大大提升，進入大廠指日可待

復(fù)習(xí)大數(shù)據(jù)面試題，看這一套就夠了！

Hadoop

Hadoop中常問的就三塊，第一：分布式存儲(HDFS)；第二：分布式計算框架

(MapReduce)；第三：資源調(diào)度框架(YARN)。

1.請說下HDFS讀寫流程

這個問題雖然見過無數(shù)次，面試官問過無數(shù)次，還是有不少面試者不能完整的說出

來，所以請務(wù)必記住。并且很多問題都是從HDFS讀寫流程中引申出來的。

HDFS寫流程：

1.Client客戶端發(fā)送上傳請求，通過RPC與NameNode建立通信，NameNode

檢查該用戶是否有上傳權(quán)限，以及上傳的文件是否在HDFS對應(yīng)的目錄下

重名，如果這兩者有任意一個不滿足，則直接報錯，如果兩者都滿足，則返

回給客戶端一個可以上傳的信息；

2.Client根據(jù)文件的大小進行切分，默認(rèn)128M一塊，切分完成之后給

NameNode發(fā)送請求第一個block塊上傳到哪些服務(wù)器上；

3.NameNode收到請求之后，根據(jù)網(wǎng)絡(luò)拓?fù)浜蜋C架感知以及副本機制進行文

件分配，返回可用的DataNode的地址；

注：Hadoop在設(shè)計時考慮到數(shù)據(jù)的安全與高效，數(shù)據(jù)文件默認(rèn)在HDFS上存放三份，

存儲策略為本地一份，同機架內(nèi)其它某一節(jié)點上一份，不同機架的某一節(jié)點上一份。

4.客戶端收到地址之后與服務(wù)器地址列表中的一個節(jié)點如A進行通信，本質(zhì)

上就是RPC調(diào)用，建立pipeline,A收到請求后會繼續(xù)調(diào)用B,B在調(diào)用

C,整個pipeline建立完成，逐級返回Client；

5.Client開始向A上發(fā)送第一個block(先從磁盤讀取數(shù)據(jù)然后放到本地內(nèi)

存緩存)，以packet(數(shù)據(jù)包，64kb)為單位，A收到一個packet就會發(fā)

6/78

送給B,然后B發(fā)送給C,A每傳完一個packet就會放入一個應(yīng)答隊列等待

應(yīng)答；

6.數(shù)據(jù)被分割成一個個的packet數(shù)據(jù)包在pipeline上依次傳輸，在

pipeline反向傳輸中，逐個發(fā)送ack（命令正確應(yīng)答），最終由pipeline

中第一個DataNode節(jié)點A將pipelineack發(fā)送給Client；

7.當(dāng)一個block傳輸完成之后，Client再次請求NameNode上傳第二個block,

NameNode重新選擇三臺DataNode給Client。

HDFS讀流程：

1.Client向NameNode發(fā)送RPC請求。請求文件block的位置；

2.NameNode收到請求之后會檢查用戶權(quán)限以及是否有這個文件，如果都符合,

則會視情況返回部分或全部的block列表，對于每個block,NameNode都會

返回含有該block副本的DataNode地址；這些返回的DataNode地址，會

按照集群拓?fù)浣Y(jié)構(gòu)得出DataNode與客戶端的距離，然后進行排序，排序兩

個規(guī)則：網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)中距離Client近的排靠前；心跳機制中超時匯報的

DataNode狀態(tài)為STALE,這樣的排靠后；

3.Client選取排序靠前的DataNode來讀取block,如果客戶端本身就是

DataNode,那么將從本地直接獲取數(shù)據(jù)（短路讀取特性）；

4.底層上本質(zhì)是建立SocketStream（FSDatalnputStream）,重復(fù)的調(diào)用

父類DatalnputStream的read方法，直到這個塊上的數(shù)據(jù)讀取完畢；

5.當(dāng)讀完列表的block后，若文件讀取還沒有結(jié)束，客戶端會繼續(xù)向

NameNode獲取下一批的block列表；

6.讀取完一^"bblock都會進行checksum驗證，如果讀取DataNode時出現(xiàn)錯

誤，客戶端會通知NameNode,然后再從下一個擁有該block副本的

DataNode繼續(xù)讀；

7.read方法是并行的讀取block信息，不是一塊一塊的讀??；NameNode只是

返回Client請求包含塊的DataNode地址，并不是返回請求塊的數(shù)據(jù)；

8.最終讀取來所有的block會合并成一個完整的最終文件；

2.HDFS在讀取文件的時候，如果其中一個塊突然損壞了怎么辦

客戶端讀取完DataNode上的塊之后會進行checksum驗證，也就是把客戶端讀取

到本地的塊與HDFS上的原始塊進行校驗，如果發(fā)現(xiàn)校驗結(jié)果不一致，客戶端會

7/78

通知NameNode,然后再從下一個擁有該block副本的DataNode繼續(xù)讀。

8/78

3.HDFS在上傳文件的時候，如果其中一個DataNode突然掛掉了怎么

辦

客戶端上傳文件時與DataNode建立pipeline管道，管道的正方向是客戶端向

DataNode發(fā)送的數(shù)據(jù)包，管道反向是DataNode向客戶端發(fā)送ack確認(rèn)，也就是

正確接收到數(shù)據(jù)包之后發(fā)送一個已確認(rèn)接收到的應(yīng)答。

當(dāng)DataNode突然掛掉了，客戶端接收不到這個DataNode發(fā)送的ack確認(rèn)，客戶

端會通知NameNode,NameNode檢查該塊的副本與規(guī)定的不符，NameNode會通知

DataNode去復(fù)制副本，并將掛掉的DataNode作下線處理，不再讓它參與文件上

傳與下載。

4.NameNode在啟動的時候會做哪些操作

NameNode數(shù)據(jù)存儲在內(nèi)存和本地磁盤，本地磁盤數(shù)據(jù)存儲在fsimage鏡像文件和

edits編輯日志文件。

首次啟動NameNode：

1.格式化文件系統(tǒng)，為了生成fsimage鏡像文件；

2.啟動NameNode：

?讀取fsimage文件，將文件內(nèi)容加載進內(nèi)存

?等待DataNade注冊與發(fā)送blockreport

3.啟動DataNode：

?向NameNode注冊

?發(fā)送blockreport

?檢查fsimage中記錄的塊的數(shù)量和blockreport中的塊的總數(shù)是

否相同

4.對文件系統(tǒng)進行操作（創(chuàng)建目錄，上傳文件，刪除文件等）：

9/78

?此時內(nèi)存中已經(jīng)有文件系統(tǒng)改變的信息，但是磁盤中沒有文件系統(tǒng)

改變的信息，此時會將這些改變信息寫入edits文件中，edits文

件中存儲的是文件系統(tǒng)元數(shù)據(jù)改變的信息。

第二次啟動NameNode：

1.讀取fsimage和edits文件；

2.將fsimage和edits文件合并成新的fsimage文件；

3.創(chuàng)建新的edits文件，內(nèi)容開始為空；

4.啟動DataNode。

5.SecondaryNameNode了解嗎，它的工作機制是怎樣的

SecondaryNameNode是合并NameNode的editlogs到fsimage文件中；

它的具體工作機制：

1.SecondaryNameNode詢問NameNode是否需要checkpointo直接帶回

NameNode是否檢查結(jié)果；

2.SecondaryNameNode請求執(zhí)行：checkpoint；

3.NameNode滾動正在寫的edits日志；

4.將滾動前的編輯日志和鏡像文件拷貝到SecondaryNameNode；

5.SecondaryNameNode加載編輯日志和鏡像文件到內(nèi)存，并合并；

6.生成新的鏡像文件fsimage.chkpoint；

7.拷貝fsimage.chkpoint到NameNode；

8.NameNode將fsimage.chkpoint重新命名成fsimage；

所以如果NameNode中的元數(shù)據(jù)丟失，是可以從SecondaryNameNode恢復(fù)一部分

元數(shù)據(jù)信息的，但不是全部，因為NameNode正在寫的edits日志還沒有拷貝到

SecondaryNameNode,這部分恢復(fù)不了。

6.SecondaryNameNode不能恢復(fù)NameNode的全部數(shù)據(jù)，那如何保證

NameNode數(shù)據(jù)存儲安全

這個問題就要說NameNode的高可用了，即NameNodeHA。

10/

一個NameNode有單點故障的問題，那就配置雙NameNode,配置有兩個關(guān)鍵點，

一是必須要保證這兩個NameNode的元數(shù)據(jù)信息必須要同步的，二是一個

NameNode掛掉之后另一個要立馬補上。

1.元數(shù)據(jù)信息同步在HA方案中采用的是“共享存儲”。每次寫文件時，需

要將日志同步寫入共享存儲，這個步驟成功才能認(rèn)定寫文件成功。然后備

份節(jié)點定期從共享存儲同步日志，以便進行主備切換。

2.監(jiān)控NameNode狀態(tài)采用zookeeper,兩個NameNode節(jié)點的狀態(tài)存放在

zookeeper中，另外兩個NameNode節(jié)點分別有一個進程監(jiān)控程序，實施讀

取zookeeper中有NameNode的狀態(tài)，來判斷當(dāng)前的NameNode是不是已經(jīng)

down機。如果Standby的NameNode節(jié)點的ZKFC發(fā)現(xiàn)主節(jié)點已經(jīng)掛掉，那

么就會強制給原本的ActiveNameNode節(jié)點發(fā)送強制關(guān)閉請求，之后將備用

的NameNode設(shè)置為Active。

如果面試官再問HA中的共享存儲是怎么實現(xiàn)的知道嗎？

可以進行解釋下:NameNode共享存儲方案有很多，比如LinuxHA,VMwareFT,QJM

等，目前社區(qū)已經(jīng)把由Clouderea公司實現(xiàn)的基于QJM(QuorumJournalManager)

的方案合并到HDFS的trunk之中并且作為默認(rèn)的共享存儲實現(xiàn)。

基于QJM的共享存儲系統(tǒng)主要用于保存EditLog,并不保存FSImage文件。FSImage

文件還是在NameNode的本地磁盤上°

QJM共享存儲的基本思想來自于Paxos算法，采用多個稱為JournalNode的節(jié)點組

成的JournalNode集群來存儲EditLogo每個JournalNode保存同樣的EditLog副

本。每次NameNode寫EditLog的時候，除了向本地磁盤寫入EditLog之外，也會

并行地向JournalNode集群之中的每一個JournalNode發(fā)送寫請求，只要大多數(shù)的

JournalNode節(jié)點返回成功就認(rèn)為向JournalNode集群寫入EditLog成功。如果有

2N+1臺JournalNode,那么根據(jù)大多數(shù)的原則，最多可以容忍有N臺JournalNode

節(jié)點掛掉。

7.在NameNodeHA中，會出現(xiàn)腦裂問題嗎？怎么解決腦裂

假設(shè)NameNode1當(dāng)前為Active狀態(tài)，NameNode2當(dāng)前為Standby狀態(tài)。如果某

一時刻NameNode1對應(yīng)的ZKFailoverController進程發(fā)生了“假死”現(xiàn)象，那么

Zookeeper服務(wù)端會認(rèn)為NameNode1掛掉了，根據(jù)前面的主備切換邏輯，NameNode2

會替代NameNode1進入Active狀態(tài)。但是此時NameNode1可能仍然處于Active

狀態(tài)正常運行，這樣NameNode1和NameNode2都處于Active狀態(tài)，都可以對外

提供服務(wù)。這種情況稱為腦裂。

11/78

腦裂對于NameNode這類對數(shù)據(jù)一致性要求非常高的系統(tǒng)來說是災(zāi)難性的，數(shù)據(jù)

會發(fā)生錯亂且無法恢復(fù)。zookeeper社區(qū)對這種問題的解決方法叫做fencing,

中文翻譯為隔離，也就是想辦法把舊的ActiveNameNode隔離起來，使它不能

正常對外提供服務(wù)。

在進行fencing的時候，會執(zhí)行以下的操作：

1.首先嘗試調(diào)用這個舊ActiveNameNode的HAServiceProtocolRPC接口

的transitionToStandby方法，看能不能把它轉(zhuǎn)換為Standby狀態(tài)。

2.如果transitionToStandby方法調(diào)用失敗，那么就執(zhí)行Hadoop配置文

件之中預(yù)定義的隔離措施，Hadoop目前主要提供兩種隔離措施，通常會

選擇sshfence：

?sshfence：通過SSH登錄到目標(biāo)機器上，執(zhí)行命令fuser將對應(yīng)

的進程殺死；

?shellfence：執(zhí)行一個用戶自定義的shell腳本來將對應(yīng)的進程

隔離。

8.小文件過多會有什么危害，如何避免

Hadoop上大量HDFS元數(shù)據(jù)信息存儲在NameNode內(nèi)存中，因此過多的小文件必定

會壓垮NameNode的內(nèi)存。

每個元數(shù)據(jù)對象約占150byte,所以如果有1千萬個小文件，每個文件占用一個

block,則NameNode大約需要2G空間。如果存儲1億個文件，則NameNode需要

20G空間。

顯而易見的解決這個問題的方法就是合并小文件，可以選擇在客戶端上傳時執(zhí)行

一定的策略先合并，或者是使用Hadoop的CombineFileInputFormat\<K,V\>實現(xiàn)

小文件的合并。

9.請說下HDFS的組織架構(gòu)

1.Client：客戶端

?切分文件。文件上傳HDFS的時候，Client將文件切分成一個一個

的Block,然后進行存儲

?與NameNode交互,獲取文件的位置信息

?與DataNode交互，讀取或者寫入數(shù)據(jù)

12/78

.Client提供一些命令來管理HDFS,比如啟動關(guān)閉HDFS、訪問HDFS

目錄及內(nèi)容等

2.NameNode：名稱節(jié)點，也稱主節(jié)點，存儲數(shù)據(jù)的元數(shù)據(jù)信息，不存儲具體的

數(shù)據(jù)

?管理HDFS的名稱空間

?管理數(shù)據(jù)塊（Block）映射信息

?配置副本策略

?處理客戶端讀寫請求

3.DataNode：數(shù)據(jù)節(jié)點，也稱從節(jié)點。NameNode下達(dá)命令，DataNode執(zhí)行

實際的操作

?存儲實際的數(shù)據(jù)塊

?執(zhí)行數(shù)據(jù)塊的讀/寫操作

4.SecondaryNameNode：并非NameNode的熱備。當(dāng)NameNode掛掉的時候，

它并不能馬上替換NameNode并提供服務(wù)

?輔助NameNode,分擔(dān)其工作量

?定期合并Fsimage和Edits,并推送給NameNode

?在緊急情況下，可輔助恢復(fù)NameNode

10.請說下MR中MapTask的工作機制

簡單概述：

inputFile通過split被切割為多個split文件，通過Record按行讀取內(nèi)容給

map（自己寫的處理邏輯的方法），數(shù)據(jù)被map處理完之后交給OutputCollect

收集器，對其結(jié)果key進行分區(qū)（默認(rèn)使用的hashPartitioner）,然后寫入buffer,

每個maptask都有一個內(nèi)存緩沖區(qū)（環(huán)形緩沖區(qū)），存放著map的輸出結(jié)果，

當(dāng)緩沖區(qū)快滿的時候需要將緩沖區(qū)的數(shù)據(jù)以一個臨時文件的方式溢寫到磁盤，當(dāng)整

個maptask結(jié)束后再對磁盤中這個maptask產(chǎn)生的所有臨時文件做合并，生成最

終的正式輸出文件，然后等待reducetask的拉取。

詳細(xì)步驟：

1.讀取數(shù)據(jù)組件InputFormat（默認(rèn)TextlnputFormat）會通過getSplits

方法對輸入目錄中的文件進行邏輯切片規(guī)劃得到block,有多少個block

就對應(yīng)啟動多少個MapTasko

13/78

2.將輸入文件切分為block之后，由RecordReader對象（默認(rèn)是

LineRecordReader）進行讀取，以\n作為分隔符，讀取一行數(shù)據(jù)，返回

〈key,value>,Key表示每行首字符偏移值，Value表示這一行文本內(nèi)

容。

3.讀取block返回〈key,value〉，進入用戶自己繼承的Mapper類中，執(zhí)

行用戶重寫的map函數(shù)，RecordReader讀取一行這里調(diào)用一次。

4.Mapper邏輯結(jié)束之后，將Mapper的每條結(jié)果通過context,write進行

collect數(shù)據(jù)收集。在collect中，會先對其進行分區(qū)處理，默認(rèn)使用

HashPartitionero

5.接下來，會將數(shù)據(jù)寫入內(nèi)存，內(nèi)存中這片區(qū)域叫做環(huán)形緩沖區(qū)（默認(rèn)100M）,

緩沖區(qū)的作用是批量收集Mapper結(jié)果，減少磁盤10的影響。我們的

Key/Value對以及Partition的結(jié)果都會被寫入緩沖區(qū)。當(dāng)然，寫入之前，

Key與Value值都會被序列化成字節(jié)數(shù)組。

6.當(dāng)環(huán)形緩沖區(qū)的數(shù)據(jù)達(dá)到溢寫比列（默認(rèn)0.8）,也就是80M時，溢寫線程

啟動，需要對這80MB空間內(nèi)的Key做排序（Sort）。排序是MapReduce

模型默認(rèn)的行為，這里的排序也是對序列化的字節(jié)做的排序。

7.合并溢寫文件，每次溢寫會在磁盤上生成一個臨時文件（寫之前判斷是否有

Combiner）,如果Mapper的輸出結(jié)果真的很大，有多次這樣的溢寫發(fā)生,

磁盤上相應(yīng)的就會有多個臨時文件存在。當(dāng)整個數(shù)據(jù)處理結(jié)束之后開始對

磁盤中的臨時文件進行Merge合并，因為最終的文件只有一個寫入磁盤,

并且為這個文件提供了一個索引文件，以記錄每個reduce對應(yīng)數(shù)據(jù)的偏

移量。

11.請說下MR中ReduceTask的工作機制

簡單描述：

Reduce大致分為copy>sort>reduce三個階段，重點在前兩個階段。

copy階段包含一個eventFetcher來獲取已完成的map列表，由Fetcher線

程去copy數(shù)據(jù)，在此過程中會啟動兩個merge線程，分別為inMemoryMerger

和onDiskMerger,分別將內(nèi)存中的數(shù)據(jù)merge到磁盤和將磁盤中的數(shù)據(jù)進行

mergeo待數(shù)據(jù)copy完成之后，copy階段就完成了。

開始進行sort階段，sort階段主要是執(zhí)行finalMerge操作，純粹的sort階

14/78

段，完成之后就是reduce階段，調(diào)用用戶定義的reduce函數(shù)進行處理。

15/78

詳細(xì)步驟：

1.Copy階段：簡單地拉取數(shù)據(jù)。Reduce進程啟動一些數(shù)據(jù)copy線程

(Fetcher),通過HTTP方式請求maptask獲取屬于自己的文件(maptask

的分區(qū)會標(biāo)識每個maptask屬于哪個reducetask,默認(rèn)reducetask

的標(biāo)識從0開始)。

2.Merge階段：在遠(yuǎn)程拷貝數(shù)據(jù)的同時，ReduceTask啟動了兩個后臺線程對

內(nèi)存和磁盤上的文件進行合并，以防止內(nèi)存使用過多或磁盤上文件過多。

merge有三種形式：內(nèi)存到內(nèi)存；內(nèi)存到磁盤；磁盤到磁盤。默認(rèn)情況下第

一種形式不啟用。當(dāng)內(nèi)存中的數(shù)據(jù)量到達(dá)一定閾值，就直接啟動內(nèi)存到磁盤的

merge。與map端類似，這也是溢寫的過程，這個過程中如果你設(shè)置有

Combiner,也是會啟用的，然后在磁盤中生成了眾多的溢寫文件。內(nèi)存到

磁盤的merge方式一直在運行，直到?jīng)]有map端的數(shù)據(jù)時才結(jié)束，然后

啟動第三種磁盤到磁盤的merge方式生成最終的文件。

3.合并排序：把分散的數(shù)據(jù)合并成一個大的數(shù)據(jù)后，還會再對合并后的數(shù)據(jù)

排序。

4.對排序后的鍵值對調(diào)用reduce方法：鍵相等的鍵值對調(diào)用一次reduce方

法，每次調(diào)用會產(chǎn)生零個或者多個鍵值對，最后把這些輸出的鍵值對寫入到

HDFS文件中。

12.請說下MR中Shuffle階段

shuffle階段分為四個步驟：依次為：分區(qū)，排序，規(guī)約，分組，其中前三個步

驟在map階段完成，最后一個步驟在reduce階段完成。

shuffle是Mapreduce的核心，它分布在Mapreduce的map階段和reduce

階段。一般把從Map產(chǎn)生輸出開始到Reduce取得數(shù)據(jù)作為輸入之前的過程稱

作shuffleo

1.Collect階段:將MapTask的結(jié)果輸出到默認(rèn)大小為100M的環(huán)形緩沖區(qū)，

保存的是key/value,Partition分區(qū)信息等。

2.Spill階段：當(dāng)內(nèi)存中的數(shù)據(jù)量達(dá)到一定的閥值的時候，就會將數(shù)據(jù)寫入

本地磁盤，在將數(shù)據(jù)寫入磁盤之前需要對數(shù)據(jù)進行一次排序的操作，如果

配置了combiner,還會將有相同分區(qū)號和key的數(shù)據(jù)進行排序。

3.MapTask階段的Merge：把所有溢出的臨時文件進行一次合并操作，以確

16/78

保一個MapTask最終只產(chǎn)生一個中間數(shù)據(jù)文件。

17/78

4.Copy階段：ReduceTask啟動Fetcher線程到已經(jīng)完成MapTask的節(jié)點

上復(fù)制一份屬于自己的數(shù)據(jù)，這些數(shù)據(jù)默認(rèn)會保存在內(nèi)存的緩沖區(qū)中，當(dāng)

內(nèi)存的緩沖區(qū)達(dá)到一定的閥值的時候，就會將數(shù)據(jù)寫到磁盤之上。

5.ReduceTask階段的Merge：在ReduceTask遠(yuǎn)程復(fù)制數(shù)據(jù)的同時，會在后

臺開啟兩個線程對內(nèi)存到本地的數(shù)據(jù)文件進行合并操作。

6.Sort階段：在對數(shù)據(jù)進行合并的同時，會進行排序操作，由于MapTask階

段已經(jīng)對數(shù)據(jù)進行了局部的排序，ReduceTask只需保證Copy的數(shù)據(jù)的

最終整體有效性即可。

Shuffle中的緩沖區(qū)大小會影響到mapreduce程序的執(zhí)行效率，原則上說，緩沖區(qū)

越大，磁盤io的次數(shù)越少，執(zhí)行速度就越快。

緩沖區(qū)的大小可以通過參數(shù)調(diào)整，參數(shù)：mapreduce.task.io.sort.mb默認(rèn)1OOM

13.Shuffle階段的數(shù)據(jù)壓縮機制了解嗎

在shuffle階段，可以看到數(shù)據(jù)通過大量的拷貝，從map階段輸出的數(shù)據(jù)，都要

通過網(wǎng)絡(luò)拷貝，發(fā)送到reduce階段，這一過程中，涉及到大量的網(wǎng)絡(luò)10,如果

數(shù)據(jù)能夠進行壓縮，那么數(shù)據(jù)的發(fā)送量就會少得多。

hadoop當(dāng)中支持的壓縮算法：

gzip、bzip2、LZO>LZ4>Snappy,這幾種壓縮算法綜合壓縮和解壓縮的速率，

谷歌的Snappy是最優(yōu)的，一般都選擇Snappy壓縮。谷歌出品，必屬精品。

14.在寫MR時，什么情況下可以使用規(guī)約

規(guī)約(combiner)是不能夠影響任務(wù)的運行結(jié)果的局部匯總，適用于求和類，不

適用于求平均值，如果reduce的輸入?yún)?shù)類型和輸出參數(shù)的類型是一樣的，則

規(guī)約的類可以使用reduce類，只需要在驅(qū)動類中指明規(guī)約的類即可。

15.YARN集群的架構(gòu)和工作原理知道多少

YARN的基本設(shè)計思想是將MapReduceVI中的JobTracker拆分為兩個獨立的服

務(wù)：ResourceManager和ApplicationMaster。

ResourceManager負(fù)責(zé)整個系統(tǒng)的資源管理和分配，ApplicationMaster負(fù)責(zé)單

18/78

個應(yīng)用程序的的管理。

19/78

1.ResourceManager：RM是一個全局的資源管理器，負(fù)責(zé)整個系統(tǒng)的資源管

理和分配，它主要由兩個部分組成：調(diào)度器(Scheduler)和應(yīng)用程序管

理器(ApplicationManager)。

調(diào)度器根據(jù)容量、隊列等限制條件，將系統(tǒng)中的資源分配給正在運行的應(yīng)用程序，在

保證容量、公平性和服務(wù)等級的前提下，優(yōu)化集群資源利用率，讓所有的資源都被

充分利用應(yīng)用程序管理器負(fù)責(zé)管理整個系統(tǒng)中的所有的應(yīng)用程序，包括應(yīng)用程序的提

交、與調(diào)度器協(xié)商資源以啟動ApplicationMaster^監(jiān)控ApplicationMaster運行

狀態(tài)并在失敗時重啟它。

2.App1icationMaster：用戶提交的一個應(yīng)用程序會對應(yīng)于一個

ApplicationMaster,它的主要功能有：

?與RM調(diào)度器協(xié)商以獲得資源，資源以Container表示。

?將得到的任務(wù)進一步分配給內(nèi)部的任務(wù)。

?與NM通信以啟動/停止任務(wù)。

?監(jiān)控所有的內(nèi)部任務(wù)狀態(tài)，并在任務(wù)運行失敗的時候重新為任務(wù)申

請資源以重啟任務(wù)。

3.NodeManager：NodeManager是每個節(jié)點上的資源和任務(wù)管理器，一方面，

它會定期地向RM匯報本節(jié)點上的資源使用情況和各個Container的運行狀

態(tài)；另一方面，他接收并處理來自AM的Container啟動和停止請求。

4.Container：Container是YARN中的資源抽象，封裝了各種資源。一個應(yīng)

用程序會分配一個Container,這個應(yīng)用程序只能使用這個Container中描

述的資源。不同于MapReduceVl中槽位slot的資源封裝，Container是一

個動態(tài)資源的劃分單位，更能充分利用資源。

16.YARN的任務(wù)提交流程是怎樣的

當(dāng)jobclient向YARN提交一個應(yīng)用程序后，YARN將分兩個階段運行這個應(yīng)用程

序：一是啟動ApplicationMaster;第二個階段是由ApplicationMaster創(chuàng)建應(yīng)

用程序，為它申請資源，監(jiān)控運行直到結(jié)束。具體步驟如下：

1.用戶向YARN提交一個應(yīng)用程序，并指定ApplicationMaster程序、啟動

ApplicationMaster的命令、用戶程序。

2.RM為這個應(yīng)用程序分配第一個Container,并與之對應(yīng)的NM通訊，要求

它在這個Container中啟動應(yīng)用程序ApplicationMaster。

20/78

3.ApplicationMaster向RM注冊，然后拆分為內(nèi)部各個子任務(wù)，為各個內(nèi)

部任務(wù)申請資源，并監(jiān)控這些任務(wù)的運行，直到結(jié)束。

4.AM采用輪詢的方式向RM申請和領(lǐng)取資源。

5.RM為AM分配資源，以Container形式返回。

6.AM申請到資源后，便與之對應(yīng)的NM通訊，要求NM啟動任務(wù)。

7.NodeManager為任務(wù)設(shè)置好運行環(huán)境，將任務(wù)啟動命令寫到一個腳本中，

并通過運行這個腳本啟動任務(wù)。

8.各個任務(wù)向AM匯報自己的狀態(tài)和進度，以便當(dāng)任務(wù)失敗時可以重啟任務(wù)。

9.應(yīng)用程序完成后，ApplicationMaster向ResourceManager注銷并關(guān)閉自

己。

17.YARN的資源調(diào)度三種模型了解嗎

在Yarn中有三種調(diào)度器可以選擇：FIFOScheduler,CapacityScheduler,Fair

Schedulero

Apache版本的hadoop默認(rèn)使用的是CapacityScheduler調(diào)度方式。CDH版本的

默認(rèn)使用的是FairScheduler調(diào)度方式

FIFOScheduler（先來先服務(wù)）：

FIFOScheduler把應(yīng)用按提交的順序排成一個隊列，這是一個先進先出隊列，

在進行資源分配的時候，先給隊列中最頭上的應(yīng)用進行分配資源，待最頭上的應(yīng)用

需求滿足后再給下一個分配，以此類推。

FIFOScheduler是最簡單也是最容易理解的調(diào)度器，也不需要任何配置，但它并

不適用于共享集群。大的應(yīng)用可能會占用所有集群資源，這就導(dǎo)致其它應(yīng)用被阻塞,

比如有個大任務(wù)在執(zhí)行，占用了全部的資源，再提交一個小任務(wù)，則此小任務(wù)會

一直被阻塞。

CapacityScheduler（能力調(diào)度器）：

對于Capacity調(diào)度器，有一個專門的隊列用來運行小任務(wù)，但是為小任務(wù)專門

設(shè)置一個隊列會預(yù)先占用一定的集群資源，這就導(dǎo)致大任務(wù)的執(zhí)行時間會落后于使

用FIFO調(diào)度器時的時間。

FairScheduler（公平調(diào)度器）：

在Fair調(diào)度器中，我們不需要預(yù)先占用一定的系統(tǒng)資源，F(xiàn)air調(diào)度器會為所有

運行的job動態(tài)的調(diào)整系統(tǒng)資源。

21/78

比如：當(dāng)?shù)谝粋€大job提交時，只有這一個job在運行，此時它獲得了所有集群

資源；當(dāng)?shù)诙€小任務(wù)提交后，F(xiàn)air調(diào)度器會分配一半資源給這個小任務(wù)，讓

這兩個任務(wù)公平的共享集群資源。

需要注意的是，在Fair調(diào)度器中，從第二個任務(wù)提交到獲得資源會有一定的延

遲，因為它需要等待第一個任務(wù)釋放占用的Container。小任務(wù)執(zhí)行完成之后也

會釋放自己占用的資源，大任務(wù)又獲得了全部的系統(tǒng)資源。最終的效果就是Fair

調(diào)度器即得到了高的資源利用率又能保證小任務(wù)及時完成。

Hive

1.Hive內(nèi)部表和外部表的區(qū)別

未被external修飾的是內(nèi)部表，被external修飾的為外部表。

區(qū)別：

1.內(nèi)部表數(shù)據(jù)由Hive自身管理，外部表數(shù)據(jù)由HDFS管理；

2.內(nèi)部表數(shù)據(jù)存儲的位置是hive.metastore.warehouse.dir（默認(rèn)：

/user/hive/warehouse）,外部表數(shù)據(jù)的存儲位置由自己制定（如果沒有

LOCATION,Hive將在HDFS上的/user/hive/warehouse文件夾下以外部表

的表名創(chuàng)建一個文件夾，并將屬于這個表的數(shù)據(jù)存放在這里）；

22/78

3.刪除內(nèi)部表會直接刪除元數(shù)據(jù)（metadata）及存儲數(shù)據(jù)；刪除外部表僅僅會

刪除元數(shù)據(jù)，HDFS上的文件并不會被刪除。

2.Hive有索引嗎

Hive支持索引（3.0版本之前），但是Hive的索引與關(guān)系型數(shù)據(jù)庫中的索引并

不相同，比如，Hive不支持主鍵或者外鍵。并且Hive索引提供的功能很有限，

效率也并不高，因此Hive索引很少使用。

?索引適用的場景：

適用于不更新的靜態(tài)字段。以免總是重建索引數(shù)據(jù)。每次建立、更新數(shù)據(jù)后，都

要重建索引以構(gòu)建索引表。

?Hive索引的機制如下：

hive在指定列上建立索引，會產(chǎn)生一張索引表（Hive的一張物理表），里面的

字段包括：索引列的值、該值對應(yīng)的HDFS文件路徑、該值在文件中的偏移量。

Hive0.8版本后引入bitmap索引處理器，這個處理器適用于去重后，值較少的

列（例如，某字段的取值只可能是幾個枚舉值）因為索引是用空間換時間，索

引列的取值過多會導(dǎo)致建立bitmap索引表過大。

注意：Hive中每次有數(shù)據(jù)時需要及時更新索引，相當(dāng)于重建一個新表，否則會影

響數(shù)據(jù)查詢的效率和準(zhǔn)確性，Hive官方文檔已經(jīng)明確表示Hive的索引不推薦被使

用，在新版本的Hive中已經(jīng)被廢棄了。

擴展：Hive是在0.7版本之后支持索引的，在0.8版本后引入bitmap索引處理

器，在3.0版本開始移除索引的功能，取而代之的是2.3版本開始的物化視圖，

自動重寫的物化視圖替代了索引的功能。

3.運維如何對Hive進行調(diào)度

1.將hive的sql定義在腳本當(dāng)中；

2.使用azkaban或者"oozie進行任務(wù)的調(diào)度；

3.監(jiān)控任務(wù)調(diào)度頁面。

23/78

4.ORC、Parquet等列式存儲的優(yōu)點

ORC和Parquet都是高性能的存儲方式，這兩種存儲格式總會帶來存儲和性能上的

提升。

Parquet:

1.Parquet支持嵌套的數(shù)據(jù)模型，類似于ProtocolBuffers,每一個數(shù)據(jù)模

型的schema包含多個字段，每一個字段有三個屬性：重復(fù)次數(shù)、數(shù)據(jù)類

型和字段名。

重復(fù)次數(shù)可以是以下三種：required（只出現(xiàn)1次），repeated（出現(xiàn)0次

或多次），optional（出現(xiàn)0次或1次）。每一個字段的數(shù)據(jù)類型可以分成

兩種：group（復(fù)雜類型）和primitive（基本類型）。

2.Parquet中沒有Map、Array這樣的復(fù)雜數(shù)據(jù)結(jié)構(gòu)，但是可以通過repeated

和group組合來實現(xiàn)的。

3.由于Parquet支持的數(shù)據(jù)模型比較松散，可能一條記錄中存在比較深的嵌套

關(guān)系，如果為每一條記錄都維護一個類似的樹狀結(jié)可能會占用較大的存儲空

間，因此Dremel論文中提出了一種高效的對于嵌套數(shù)據(jù)格式的壓縮算法：

Striping/Assembly算法。通過Striping/Assembly算法，parquet可以

使用較少的存儲空間表示復(fù)雜的嵌套格式，并且通常Repetitionlevel

和Definitionlevel都是較小的整數(shù)值，可以通過RLE算法對其進行壓

縮，進一步降低存儲空間。

4.Parquet文件是以二進制方式存儲的，是不可以直接讀取和修改的，

Parquet文件是自解析的，文件中包括該文件的數(shù)據(jù)和元數(shù)據(jù)。

0RC:

1.ORC文件是自描述的，它的元數(shù)據(jù)使用ProtocolBuffers序列化，并且

文件中的數(shù)據(jù)盡可能的壓縮以降低存儲空間的消耗。

2.和Parquet類似，ORC文件也是以二進制方式存儲的，所以是不可以直接

讀取，ORC文件也是自解析的，它包含許多的元數(shù)據(jù)，這些元數(shù)據(jù)都是同構(gòu)

ProtoBuffer進行序列化的。

3.0RC會盡可能合并多個離散的區(qū)間盡可能的減少I/O次數(shù)。

4.ORC中使用了更加精確的索引信息，使得在讀取數(shù)據(jù)時可以指定從任意一行

開始讀取，更細(xì)粒度的統(tǒng)計信息使得讀取ORC文件跳過整個rowgroup,

ORC默認(rèn)會對任何一塊數(shù)據(jù)和索引信息使用ZLIB壓縮，因此ORC文件占用

24/78

的存儲空間也更小。

25/78

5.在新版本的ORC中也加入了對BloomFilter的支持，它可以進一步提升

謂詞下推的效率，在Hive1.2.0版本以后也加入了對此的支持。

5.數(shù)據(jù)建模用的哪些模型?

1.星型模型

部門雄虎表

承注跳

堆度信亙

總公司

分公司

代度處

產(chǎn)品雉度表