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

2022

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

目錄

Hadoop6

1.請(qǐng)說(shuō)下HDFS讀寫流程6

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

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

4.NameNode在啟動(dòng)的時(shí)候會(huì)做哪些操作8

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

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

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

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

8.小文件過(guò)多會(huì)有什么危害，如何避免11

9.請(qǐng)說(shuō)下HDFS的組織架構(gòu)11

10.請(qǐng)說(shuō)下MR中MapTask的工作機(jī)制12

11.請(qǐng)說(shuō)下MR中ReduceTask的工作機(jī)制13

12.請(qǐng)說(shuō)下MR中Shuffle階段14

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

14.在寫MR時(shí)，什么情況下可以使用規(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.運(yùn)維如何對(duì)Hive進(jìn)行調(diào)度19

4.ORC、Parquet等列式存儲(chǔ)的優(yōu)點(diǎn)20

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

6.為什么要對(duì)數(shù)據(jù)倉(cāng)庫(kù)分層？23

7.使用過(guò)Hive解析JSON串嗎23

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

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

10.Hive小文件過(guò)多怎么解決24

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

Spark27

1.Spark的運(yùn)行流程？27

2.Spark有哪些組件？28

3.Spark中的RDD機(jī)制理解嗎？29

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

5.介紹一下cogrouprdd實(shí)現(xiàn)原理，你在什么場(chǎng)景下用過(guò)這個(gè)rdd?30

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

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

8.DAG是什么？31

9.DAG中為什么要?jiǎng)澐諷tage?31

10.如何劃分DAG的stage?31

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

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

13.Spark中的00M問(wèn)題？32

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

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

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

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

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

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

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

20.通常來(lái)說(shuō)，Spark與MapReduce相比，Spark運(yùn)行效率更高。請(qǐng)說(shuō)明效

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

21.Hadoop和Spark的相同點(diǎn)和不同點(diǎn)？36

22.Hadoop和Spark使用場(chǎng)景?37

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

24.RDD持久化原理？37

25.Checkpoint檢查點(diǎn)機(jī)制？37

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

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

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

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

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

31.Spark解決了Hadoop的哪些問(wèn)題？41

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

33.你用SparkSql處理的時(shí)候，處理過(guò)程中用的DataFrame還是直接寫

的Sql?為什么？42

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

么？42

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

Zookeeper里面？43

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

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

38.RDD有哪些缺陷？44

Kafka44

1.為什么要使用kafka?45

2.Kafka消費(fèi)過(guò)的消息如何再消費(fèi)？45

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

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

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

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

7.kafka宕機(jī)了如何解決？48

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

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

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

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

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

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

Hbase51

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

2.HDFS和HBase各自使用場(chǎng)景51

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

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

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

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

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

別54

Flink55

1.簡(jiǎn)單介紹一下Flink55

2.Flink的運(yùn)行必須依賴Hadoop組件嗎55

3.Flink集群運(yùn)行時(shí)角色56

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

5.介紹下Flink的容錯(cuò)機(jī)制（checkpoint）57

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

7.Flink是如何保證Exactly-once語(yǔ)義的59

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

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

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

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

12.如何排查生產(chǎn)環(huán)境中的反壓?jiǎn)栴}61

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

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

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

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

17.Flink中的Time有哪幾種63

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

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

20.FlinkCEP編程中當(dāng)狀態(tài)沒(méi)有到達(dá)的時(shí)候會(huì)將數(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的是如何實(shí)現(xiàn)的67

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

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

2.DWD層做了哪些事？68

3.DWS層做了哪些事？68

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

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

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

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

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

算法71

1.排序算法71

2.查找算法74

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

最后78

此套面試題來(lái)自于各大廠的真實(shí)面試題及常問(wèn)的知識(shí)點(diǎn)，如果能理解吃透這些問(wèn)題,

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

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

Hadoop

Hadoop中常問(wèn)的就三塊，第一：分布式存儲(chǔ)(HDFS)；第二：分布式計(jì)算框架

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

1.請(qǐng)說(shuō)下HDFS讀寫流程

這個(gè)問(wèn)題雖然見(jiàn)過(guò)無(wú)數(shù)次，面試官問(wèn)過(guò)無(wú)數(shù)次，還是有不少面試者不能完整的說(shuō)出

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

HDFS寫流程：

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

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

重名，如果這兩者有任意一個(gè)不滿足，則直接報(bào)錯(cuò)，如果兩者都滿足，則返

回給客戶端一個(gè)可以上傳的信息；

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

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

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

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

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

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

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

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

C,整個(gè)pipeline建立完成，逐級(jí)返回Client；

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

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

6/78

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

應(yīng)答；

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

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

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

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

NameNode重新選擇三臺(tái)DataNode給Client。

HDFS讀流程：

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

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

則會(huì)視情況返回部分或全部的block列表，對(duì)于每個(gè)block,NameNode都會(huì)

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

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

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

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

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

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

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

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

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

NameNode獲取下一批的block列表；

6.讀取完一^"bblock都會(huì)進(jìn)行checksum驗(yàn)證，如果讀取DataNode時(shí)出現(xiàn)錯(cuò)

誤，客戶端會(huì)通知NameNode,然后再?gòu)南乱粋€(gè)擁有該block副本的

DataNode繼續(xù)讀；

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

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

8.最終讀取來(lái)所有的block會(huì)合并成一個(gè)完整的最終文件；

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

客戶端讀取完DataNode上的塊之后會(huì)進(jìn)行checksum驗(yàn)證，也就是把客戶端讀取

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

7/78

通知NameNode,然后再?gòu)南乱粋€(gè)擁有該block副本的DataNode繼續(xù)讀。

8/78

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

辦

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

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

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

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

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

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

傳與下載。

4.NameNode在啟動(dòng)的時(shí)候會(huì)做哪些操作

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

edits編輯日志文件。

首次啟動(dòng)NameNode：

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

2.啟動(dòng)NameNode：

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

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

3.啟動(dòng)DataNode：

?向NameNode注冊(cè)

?發(fā)送blockreport

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

否相同

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

9/78

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

改變的信息，此時(shí)會(huì)將這些改變信息寫入edits文件中，edits文

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

第二次啟動(dòng)NameNode：

1.讀取fsimage和edits文件；

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

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

4.啟動(dòng)DataNode。

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

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

它的具體工作機(jī)制：

1.SecondaryNameNode詢問(wèn)NameNode是否需要checkpointo直接帶回

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

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

3.NameNode滾動(dòng)正在寫的edits日志；

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

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

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

7.拷貝fsimage.chkpoint到NameNode；

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

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

元數(shù)據(jù)信息的，但不是全部，因?yàn)镹ameNode正在寫的edits日志還沒(méi)有拷貝到

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

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

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

這個(gè)問(wèn)題就要說(shuō)NameNode的高可用了，即NameNodeHA。

10/

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

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

NameNode掛掉之后另一個(gè)要立馬補(bǔ)上。

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

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

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

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

zookeeper中，另外兩個(gè)NameNode節(jié)點(diǎn)分別有一個(gè)進(jìn)程監(jiān)控程序，實(shí)施讀

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

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

么就會(huì)強(qiáng)制給原本的ActiveNameNode節(jié)點(diǎn)發(fā)送強(qiáng)制關(guān)閉請(qǐng)求，之后將備用

的NameNode設(shè)置為Active。

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

可以進(jìn)行解釋下:NameNode共享存儲(chǔ)方案有很多，比如LinuxHA,VMwareFT,QJM

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

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

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

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

QJM共享存儲(chǔ)的基本思想來(lái)自于Paxos算法，采用多個(gè)稱為JournalNode的節(jié)點(diǎn)組

成的JournalNode集群來(lái)存儲(chǔ)EditLogo每個(gè)JournalNode保存同樣的EditLog副

本。每次NameNode寫EditLog的時(shí)候，除了向本地磁盤寫入EditLog之外，也會(huì)

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

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

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

節(jié)點(diǎn)掛掉。

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

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

一時(shí)刻N(yùn)ameNode1對(duì)應(yīng)的ZKFailoverController進(jìn)程發(fā)生了“假死”現(xiàn)象，那么

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

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

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

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

11/78

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

會(huì)發(fā)生錯(cuò)亂且無(wú)法恢復(fù)。zookeeper社區(qū)對(duì)這種問(wèn)題的解決方法叫做fencing,

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

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

在進(jìn)行fencing的時(shí)候，會(huì)執(zhí)行以下的操作：

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

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

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

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

選擇sshfence：

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

的進(jìn)程殺死；

?shellfence：執(zhí)行一個(gè)用戶自定義的shell腳本來(lái)將對(duì)應(yīng)的進(jìn)程

隔離。

8.小文件過(guò)多會(huì)有什么危害，如何避免

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

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

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

block,則NameNode大約需要2G空間。如果存儲(chǔ)1億個(gè)文件，則NameNode需要

20G空間。

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

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

小文件的合并。

9.請(qǐng)說(shuō)下HDFS的組織架構(gòu)

1.Client：客戶端

?切分文件。文件上傳HDFS的時(shí)候，Client將文件切分成一個(gè)一個(gè)

的Block,然后進(jìn)行存儲(chǔ)

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

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

12/78

.Client提供一些命令來(lái)管理HDFS,比如啟動(dòng)關(guān)閉HDFS、訪問(wèn)HDFS

目錄及內(nèi)容等

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

數(shù)據(jù)

?管理HDFS的名稱空間

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

?配置副本策略

?處理客戶端讀寫請(qǐng)求

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

實(shí)際的操作

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

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

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

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

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

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

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

10.請(qǐng)說(shuō)下MR中MapTask的工作機(jī)制

簡(jiǎn)單概述：

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

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

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

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

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

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

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

詳細(xì)步驟：

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

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

就對(duì)應(yīng)啟動(dòng)多少個(gè)MapTasko

13/78

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

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

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

容。

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

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

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

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

HashPartitionero

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

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

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

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

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

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

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

7.合并溢寫文件，每次溢寫會(huì)在磁盤上生成一個(gè)臨時(shí)文件（寫之前判斷是否有

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

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

磁盤中的臨時(shí)文件進(jìn)行Merge合并，因?yàn)樽罱K的文件只有一個(gè)寫入磁盤,

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

移量。

11.請(qǐng)說(shuō)下MR中ReduceTask的工作機(jī)制

簡(jiǎn)單描述：

Reduce大致分為copy>sort>reduce三個(gè)階段，重點(diǎn)在前兩個(gè)階段。

copy階段包含一個(gè)eventFetcher來(lái)獲取已完成的map列表，由Fetcher線

程去copy數(shù)據(jù)，在此過(guò)程中會(huì)啟動(dòng)兩個(gè)merge線程，分別為inMemoryMerger

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

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

開(kāi)始進(jìn)行sort階段，sort階段主要是執(zhí)行finalMerge操作，純粹的sort階

14/78

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

15/78

詳細(xì)步驟：

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

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

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

的標(biāo)識(shí)從0開(kāi)始)。

2.Merge階段：在遠(yuǎn)程拷貝數(shù)據(jù)的同時(shí)，ReduceTask啟動(dòng)了兩個(gè)后臺(tái)線程對(duì)

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

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

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

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

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

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

啟動(dòng)第三種磁盤到磁盤的merge方式生成最終的文件。

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

排序。

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

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

HDFS文件中。

12.請(qǐng)說(shuō)下MR中Shuffle階段

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

驟在map階段完成，最后一個(gè)步驟在reduce階段完成。

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

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

作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í)候，就會(huì)將數(shù)據(jù)寫入

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

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

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

16/78

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

17/78

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

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

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

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

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

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

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

最終整體有效性即可。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

務(wù)：ResourceManager和ApplicationMaster。

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

18/78

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

19/78

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

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

理器(ApplicationManager)。

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

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

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

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

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

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

ApplicationMaster,它的主要功能有：

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

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

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

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

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

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

它會(huì)定期地向RM匯報(bào)本節(jié)點(diǎn)上的資源使用情況和各個(gè)Container的運(yùn)行狀

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

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

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

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

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

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

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

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

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

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

ApplicationMaster的命令、用戶程序。

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

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

20/78

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

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

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

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

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

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

并通過(guò)運(yùn)行這個(gè)腳本啟動(dòng)任務(wù)。

8.各個(gè)任務(wù)向AM匯報(bào)自己的狀態(tài)和進(jìn)度，以便當(dāng)任務(wù)失敗時(shí)可以重啟任務(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（先來(lái)先服務(wù)）：

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

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

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

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

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

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

一直被阻塞。

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

對(duì)于Capacity調(diào)度器，有一個(gè)專門的隊(duì)列用來(lái)運(yùn)行小任務(wù)，但是為小任務(wù)專門

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

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

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

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

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

21/78

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

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

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

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

遲，因?yàn)樗枰却谝粋€(gè)任務(wù)釋放占用的Container。小任務(wù)執(zhí)行完成之后也

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

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

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ù)存儲(chǔ)的位置是hive.metastore.warehouse.dir（默認(rèn)：

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

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

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

22/78

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

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

2.Hive有索引嗎

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

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

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

?索引適用的場(chǎng)景：

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

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

?Hive索引的機(jī)制如下：

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

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

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

列（例如，某字段的取值只可能是幾個(gè)枚舉值）因?yàn)樗饕怯每臻g換時(shí)間，索

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

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

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

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

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

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

自動(dòng)重寫的物化視圖替代了索引的功能。

3.運(yùn)維如何對(duì)Hive進(jìn)行調(diào)度

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

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

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

23/78

4.ORC、Parquet等列式存儲(chǔ)的優(yōu)點(diǎn)

ORC和Parquet都是高性能的存儲(chǔ)方式，這兩種存儲(chǔ)格式總會(huì)帶來(lái)存儲(chǔ)和性能上的

提升。

Parquet:

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

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

型和字段名。

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

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

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

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

和group組合來(lái)實(shí)現(xiàn)的。

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

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

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

Striping/Assembly算法。通過(guò)Striping/Assembly算法，parquet可以

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

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

縮，進(jìn)一步降低存儲(chǔ)空間。

4.Parquet文件是以二進(jìn)制方式存儲(chǔ)的，是不可以直接讀取和修改的，

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

0RC:

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

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

2.和Parquet類似，ORC文件也是以二進(jìn)制方式存儲(chǔ)的，所以是不可以直接

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

ProtoBuffer進(jìn)行序列化的。

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

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

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

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

24/78

的存儲(chǔ)空間也更小。

25/78

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

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

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

1.星型模型

部門雄虎表

承注跳

堆度信亙

總公司

分公司

代度處

產(chǎn)品雉度表