大廠數(shù)據(jù)倉庫面試題

大廠數(shù)據(jù)倉庫面試題

導(dǎo)讀：此套面試題來自于各大廠的真實(shí)面試題及常問的知識(shí)點(diǎn)，如

果能理解吃透這些問題，你的大數(shù)據(jù)能力將會(huì)大大提升，進(jìn)入大廠

指日可待。

本文目錄：

一、Hadoop

一、Hive

三、Spark

五、HBase

六、Flink

七、數(shù)倉業(yè)務(wù)方面

八、算法

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

10.

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

11.

拷貝fsimage.chkpoint至UNameNode；

12.

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

所以如果NameNode中的元數(shù)據(jù)喪失，是可以從SecondaryNameNode

恢復(fù)一局部元數(shù)據(jù)信息的,但不是全部，因?yàn)镹ameNode正在寫的edits

日志還沒有拷貝到SecondaryNameNode,這局部恢復(fù)不了。

6.SecondaryNameNode不能恢復(fù)NameNode的全部數(shù)

據(jù)，那如何保證NameNode數(shù)據(jù)存儲(chǔ)平安

這個(gè)問題就要說NameNode的高可用了，即NameNodeHAo

3.Flink集群運(yùn)行時(shí)角色Flink運(yùn)行時(shí)由兩種類型的進(jìn)程

組成：，個(gè)JobManager和一

個(gè)或者多個(gè)(Worker)

TaskManager0

(Worker)(Worker)

TaskManagerTaskManager

TaskTaskTaskTaskTask

SlotSlotSlotSlotSlot

TaskT

as<

Memory&I/OManager

Network

ManagerMemory&I/ONetwork

ManagerManagerActor

S糜的1System

Flink

ProgramProgTaskStatus

/：

ram/Heartbeats/Deploy,/

CancelStat

C蹴簿是運(yùn)行時(shí)和程序執(zhí)行的一局部，而是用于準(zhǔn)備數(shù)據(jù)流并將其發(fā)usupdates

code';/瓦班研cs&

Optimizer/Client'/Chech砌口總

送給歡）&Manage幟i潦后，客戶端可以斷開連接（別離模式分呼?；虮３滞?/p>

ActorSysteJobManager\

接來接收進(jìn)程報(bào)首1圖-加模式嬴叱小弼⑼

grapCance//*'Actor

客戶端可以作為觸發(fā)執(zhí)行Java/Scala程懶。j局部運(yùn)潞丁1艷卜詢以在命令

Graph

Checkpoint

行進(jìn)程./bin/flinkrun...中運(yùn)行。Coordinator

可以通過多種方式啟動(dòng)JobManager和TaskMa卷斷｝曜鑼歌就需k作

為standalone集群啟動(dòng)、在容器中啟動(dòng)、或者通過YARN等資源框架管

理并啟動(dòng)。TaskManager連接到JobManagers,宣布自己可用，并被分配

工作。

JobManager：

JobManager具有許多與協(xié)調(diào)Flink應(yīng)用程序的分布式執(zhí)行有關(guān)的職責(zé):

它決定何時(shí)調(diào)度下一個(gè)task（或一組task）、對(duì)完成的task或執(zhí)行失敗

做出反響、協(xié)調(diào)checkpoints并且協(xié)調(diào)從失敗中恢復(fù)等等。這個(gè)進(jìn)程由三

個(gè)不同的組件組成：

ResourceManagerResourceManager負(fù)責(zé)Flink集群中的資源提

供、回收、分配，管理taskslotSo

DispatcherDispatcher提供了一個(gè)REST接口，用來提交Flink

應(yīng)用程序執(zhí)行，并為每個(gè)提交的作業(yè)啟動(dòng)一個(gè)新的

JobMastero它還運(yùn)行FlinkWebUI用來提供作業(yè)執(zhí)行信息。

JobMasterJobMaster負(fù)責(zé)管理單個(gè)JobGraph的執(zhí)行。Flink集群

中可以同時(shí)運(yùn)行多個(gè)作業(yè)，每個(gè)作業(yè)都有自己的JobMastero

TaskManagers：

TaskManager（也稱為worker）執(zhí)行作業(yè)流的task,并且緩存和交換數(shù)據(jù)

流。

必須始終至少有一個(gè)TaskManager。在TaskManager中資源調(diào)度的最小

單位是taskslotoTaskManager中taskslot的數(shù)量表示并發(fā)處理task的

數(shù)量。請(qǐng)注意一個(gè)taskslot中可以執(zhí)行多個(gè)算子。

4.Flink相比SparkStreaming有什么區(qū)別.架構(gòu)模型

SparkStreaming在運(yùn)行時(shí)的主要角色包括：Master、Worker、Driver>

Executor,Flink在運(yùn)行時(shí)主要包含：Jobmanager〉Taskmanager和Sloto.

任務(wù)調(diào)度

SparkStreaming連續(xù)不斷的生成微小的數(shù)據(jù)批次，構(gòu)建有向無環(huán)圖DAG,

SparkStreaming會(huì)依次創(chuàng)立DStreamGraph>JobGenerator>

JobScheduleroFlink根據(jù)用戶提交的代碼生成StreamGraph,經(jīng)過優(yōu)化生成

JobGraph,然后提交給JobManager進(jìn)行處理，JobManager會(huì)根據(jù)

JobGraph生成ExecutionGraph,ExecutionGraph是Flink調(diào)度最核心的

數(shù)據(jù)結(jié)構(gòu)，JobManager根據(jù)ExecutionGraphXjJob進(jìn)行調(diào)度。

1.時(shí)間機(jī)制SparkStreaming支持的時(shí)間機(jī)制有限，只支持處理時(shí)間。

Flink支持了流處理程序在時(shí)間上的三個(gè)定義：處理時(shí)間、事件時(shí)間、注入

時(shí)間。同時(shí)也支持watermark機(jī)制來處理滯后數(shù)據(jù)。

2.容錯(cuò)機(jī)制對(duì)于SparkStreaming房務(wù),我們可以設(shè)置checkpoint,然后假

如發(fā)生故障并重啟，我們可以從上次checkpoint之處恢復(fù)，但是這個(gè)行

為只能使得數(shù)據(jù)不喪失，可能會(huì)重復(fù)處理，K能做到恰一次處理語義。

Flink那么使用兩階段提交協(xié)議來解決這個(gè)問即。

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

是Flink可靠性的基石，可以保證Flink集群在某個(gè)算子因?yàn)?/p>

某些原因（如異常退出）出現(xiàn)故障時(shí)，能夠?qū)⒄麄€(gè)應(yīng)用流

圖的狀態(tài)恢復(fù)到故障之前的某一狀態(tài)，保證應(yīng)用流圖狀態(tài)

的一致性。Flink的Checkpoint機(jī)制原理來自Xhandy-Lamport

algorithm〃算法。

每個(gè)需要Checkpoint的應(yīng)用在啟動(dòng)時(shí)，F(xiàn)link的JobManager為其創(chuàng)立一

個(gè)Checkpointcoordinator（檢查點(diǎn)協(xié),調(diào)器），Checkpointcoordinator全

權(quán)負(fù)責(zé)本應(yīng)用的快照制作。

Checkpointcoordinator（檢杳點(diǎn)協(xié)調(diào)器）,Checkpointcoordinato「全權(quán)負(fù)

責(zé)本應(yīng)用的快照制作。

1.

Checkpointcoordinator（檢查點(diǎn)協(xié)調(diào)器）周期性的向該流應(yīng)用的所有

source算子發(fā)送barrier（屏闡。

2.

當(dāng)某個(gè)source算子收到一個(gè)barrier時(shí)，便暫停數(shù)據(jù)處理過程，然后

將自己的當(dāng)前狀態(tài)制作成快照，并保存到指定的持久化存儲(chǔ)中，最后向

Checkpointcoordinator報(bào)告自己快照制作情況，同時(shí)向自身所有下游

算子廣播該barrier,恢復(fù)數(shù)據(jù)處理

3.

下游算子收到barrier之后，會(huì)暫停自己的數(shù)據(jù)處理過程，然后將自身

的相關(guān)狀態(tài)制作成快照，并保存到指定的持久化存儲(chǔ)中，最后向

Checkpointcoordinator報(bào)告自身快照情況，同時(shí)向自身所有下游算子

廣播該barrier,恢復(fù)數(shù)據(jù)處理。

4.

每個(gè)算子按照步驟3不斷制作快照并向下游廣播，直到最后barrier傳

遞到sink算子，快照制作完成。

8.

9.

當(dāng)Checkpointcoordinator收到所有算子的報(bào)告之后，認(rèn)為該周期的

快照制作成功；否那么，如果在規(guī)定的時(shí)間內(nèi)沒有收到所有算子的報(bào)

告，那么認(rèn)為本周期快照制作失敗。

10.

文章推薦：

Flink可靠性的基石-checkpoint機(jī)制詳細(xì)解析

6.FlinkcheckpointSparkStreaming的有什么區(qū)別

或優(yōu)勢(shì)嗎

sparkstreaming的checkpoint僅僅是針對(duì)driver的故障恢復(fù)做『數(shù)

據(jù)和元數(shù)據(jù)的checkpointo而flink的checkpoint機(jī)制要夏雜了很多,

它采用的是輕量級(jí)的分布式快照，實(shí)現(xiàn)了每個(gè)算子的快照，及流動(dòng)中

的數(shù)據(jù)的快照。

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

Flink通過實(shí)現(xiàn)兩階段提交和狀態(tài)保存來實(shí)現(xiàn)端到端的一致性語義。分

為以下幾個(gè)步驟：

開始事務(wù)(beginTransaction)創(chuàng)立一個(gè)臨時(shí)文件夾，來寫把數(shù)據(jù)寫入到

這個(gè)文件夾里面

預(yù)提交(preCommit)將內(nèi)存中緩存的數(shù)據(jù)寫入文件并關(guān)閉

正式提交(commit)將之前寫完的臨時(shí)文件放入目標(biāo)目錄下。這代表

著最終的數(shù)據(jù)會(huì)有一些延遲丟棄(abort)丟棄臨時(shí)文件

假設(shè)失敗發(fā)生在預(yù)提交成功后，正式提交前?？梢愿鶕?jù)狀態(tài)來提交預(yù)提

交的數(shù)據(jù)，也可刪除預(yù)提交的數(shù)據(jù)。

兩階段提交協(xié)議詳解：八張圖搞懂Flink的Exactly-once

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

once

端到端的exactly-once對(duì)sink要求比擬高，具體實(shí)現(xiàn)主要有幕等寫入

和事務(wù)性寫入兩種方式。

募等寫入的場(chǎng)景依賴于業(yè)務(wù)邏輯，更常見的是用事務(wù)性寫入。而事務(wù)性

寫入又有預(yù)寫日志（WAL）和兩階段提交（2PC）兩種方式。

如果外部系統(tǒng)不支持事務(wù)，那么可以用預(yù)寫日志的方式，把結(jié)果數(shù)據(jù)先

當(dāng)成狀態(tài)保存，然后在收到checkpoint完成的通知時(shí)，一次性寫入sink

系統(tǒng)。

9.Flink常用的算子有哪些

分兩局部：

1.數(shù)據(jù)讀取，這是Flink流計(jì)算應(yīng)用的起點(diǎn)，常用算子有：

從內(nèi)存讀:from日ements

從文件讀：readTextFile

Socket接入：socketTextStream

自定義讀?。篶reatelnputi.處理數(shù)據(jù)的算子，常用的算子包括：

Map（單輸入單輸出）、

FlatMap（單輸入、多輸出）、Filter（過濾）、KeyBy（分組）、Reduce

（聚合）、Window（窗口）、Connect（連接）、Split（分割）等。

推薦閱讀：一文學(xué)完Flink流計(jì)算常用算子（Flink算子大全）

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

在Flink的后臺(tái)任務(wù)管理中，我們可以看到Flink的哪個(gè)算子和task

出現(xiàn)了反壓。最主要的手段是資源調(diào)優(yōu)和算子調(diào)優(yōu)。資源調(diào)優(yōu)即是對(duì)

作業(yè)中的Operator的并發(fā)數(shù)

（parallelism）、CPU（core）＞堆內(nèi)存（heapjnemory）等參數(shù)進(jìn)行調(diào)優(yōu)。

作業(yè)參數(shù)調(diào)優(yōu)包括：并行度的設(shè)置，State的設(shè)置，checkpoint的設(shè)置。

11.Flink是如何處理反壓的

Flink內(nèi)部是基于producer-consumer模型來進(jìn)行消息傳遞的，F(xiàn)link

的反壓設(shè)計(jì)也是基于這個(gè)模型。Flink使壓了高效有界的分布式阻塞隊(duì)

列，就像Java通用的阻塞隊(duì)列

（BlockingQueue）一樣。下游消費(fèi)者消費(fèi)變慢，上游就會(huì)受到阻塞。

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

1.反壓出現(xiàn)的場(chǎng)景

反壓經(jīng)常出現(xiàn)在促銷、熱門活動(dòng)等場(chǎng)景。短時(shí)間內(nèi)流量陡增造成數(shù)據(jù)的

堆積或者消費(fèi)速度變慢。

它們有一個(gè)共同的特點(diǎn)：數(shù)據(jù)的消費(fèi)速度小于數(shù)據(jù)的生產(chǎn)速度。

2,反壓監(jiān)控方法

通過FlinkWebUI發(fā)現(xiàn)反壓問題。

Flink的TaskManager會(huì)每隔50ms觸發(fā)一次反壓狀態(tài)監(jiān)測(cè)，共監(jiān)測(cè)

100次，并將計(jì)算結(jié)果反響給JobManager,最后由JobManager進(jìn)行

計(jì)算反壓的比例，然后進(jìn)行展示。這個(gè)比例展示邏輯如下：

0K:0<=Ratio<=0.10,表示狀態(tài)良好正;

LOW:0.10<Ratio<=0.5,表示有待觀察；

HIGH:0.5<Ratio<=1,表示要處理了（增加并行度/subTask/檢查是否

有數(shù)據(jù)傾斜/增加內(nèi)存）。

0.01,代表100次中有一次阻塞在內(nèi)部調(diào)用。

3.flink反壓的實(shí)現(xiàn)方式

Flink任務(wù)的組成由基本的〃流〃和〃算子〃構(gòu)成，〃流〃中的數(shù)據(jù)在〃

算子〃間進(jìn)行計(jì)算和轉(zhuǎn)換時(shí)，會(huì)被放入分布式的阻塞隊(duì)列中。當(dāng)消費(fèi)者

的阻塞隊(duì)列滿時(shí)，那么會(huì)降低生產(chǎn)者的數(shù)據(jù)生產(chǎn)速度

4,反壓問題定位和處理

Flink會(huì)因?yàn)閿?shù)據(jù)堆積和處理速度變慢導(dǎo)致checkpoint超時(shí)，而

checkpoint是Flink保證數(shù)據(jù)一致性的關(guān)鍵所在，最終會(huì)導(dǎo)致數(shù)據(jù)的不

致發(fā)生。

數(shù)據(jù)傾斜：可以在Flink的后臺(tái)管理頁面看到每個(gè)Task處理數(shù)據(jù)的大

小。當(dāng)數(shù)據(jù)傾斜出現(xiàn)時(shí)，通常是簡單地使用類似KeyBy等分組聚合函數(shù)

導(dǎo)致的，需要用戶將熱點(diǎn)Key進(jìn)行預(yù)處理，降低或者消除熱點(diǎn)Key的

影。

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

兩個(gè)關(guān)鍵點(diǎn)，一是必須要保證這兩個(gè)NameNode的元數(shù)據(jù)信息必須要

同步的，二是一個(gè)NameNode掛掉之后另一個(gè)要立馬補(bǔ)上。

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

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

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

監(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)，來判斷當(dāng)前的

NameNode是不是已經(jīng)down機(jī)。如果Standby的NameNode節(jié)點(diǎn)

的ZKFC發(fā)現(xiàn)主節(jié)點(diǎn)已經(jīng)掛掉，那么就會(huì)強(qiáng)制給原本的Active

NameNode節(jié)點(diǎn)發(fā)送強(qiáng)制關(guān)閉請(qǐng)求，之后將備用的NameNode設(shè)置

為Activeo

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

可以進(jìn)行解釋下：NameNode共享存儲(chǔ)方案有很多,

GC：不合理的設(shè)置TaskManager的垃圾回收參數(shù)會(huì)導(dǎo)致嚴(yán)重的GC問

題，我們可以通過-XX:+PrintGCDetails參數(shù)查看GC的日志。

代碼本身：開發(fā)者錯(cuò)誤地使用Flink算子，沒有深入了解算子的實(shí)現(xiàn)機(jī)

制導(dǎo)致性能問題。我們可以通過查看運(yùn)行機(jī)器節(jié)點(diǎn)的CPU和內(nèi)存情況

定位問題。

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

Flink在做計(jì)算的過程中經(jīng)常需要存儲(chǔ)中間狀態(tài)，來防止數(shù)據(jù)喪失和狀

態(tài)恢復(fù)。選擇的狀態(tài)存儲(chǔ)策略不同，會(huì)影響狀態(tài)持久化如何和

checkpoint交互。Flink提供了三種狀態(tài)存儲(chǔ)方式：

MemoryStateBackend>FsStateBackend>

RocksDBStateBackend.,

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

為了更高效地分布式執(zhí)行，F(xiàn)link會(huì)盡可能地將operator的subtask鏈

接(chain)在一起形成task。每個(gè)task在一個(gè)線程中執(zhí)行。將operators

鏈接成task是非常有效的優(yōu)化：它能減少線程之間的切換，減少消息的

序列化/反序列化，減少數(shù)據(jù)在緩沖區(qū)的交換，減少了延遲的同時(shí)提高

整體的吞吐量。這就是我們所說的算子鏈。

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

Flink并不是將大量對(duì)象存在堆上，而是將對(duì)象都序列化到一個(gè)預(yù)分配

的內(nèi)存塊上。此外，F(xiàn)link大量的使用了堆外內(nèi)存。如果需要處理的數(shù)

據(jù)超出了內(nèi)存限制，那么會(huì)將局部數(shù)據(jù)存儲(chǔ)到硬盤上。Flink為了直接

操作二進(jìn)制數(shù)據(jù)實(shí)現(xiàn)了自己的序列化框架。

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

Lflink數(shù)據(jù)傾斜的表現(xiàn)：

任務(wù)節(jié)點(diǎn)頻繁出現(xiàn)反壓，增加并行度也不能解決問題；局部節(jié)點(diǎn)出現(xiàn)

00M異常，是因?yàn)榇罅康臄?shù)據(jù)集中在某個(gè)節(jié)點(diǎn)上，導(dǎo)致該節(jié)點(diǎn)內(nèi)存被

爆，任務(wù)失敗重啟。

2.數(shù)據(jù)傾斜產(chǎn)生的原因：

業(yè)務(wù)上有嚴(yán)重的數(shù)據(jù)熱點(diǎn)，比方滴滴打車的訂單數(shù)據(jù)中北京、上海等

幾個(gè)城市的訂單量遠(yuǎn)遠(yuǎn)超過其他地區(qū)；

技術(shù)上大量使用了KeyBy、GroupBy等操作，錯(cuò)誤的使用了分組Key,

人為產(chǎn)生數(shù)據(jù)熱點(diǎn)。

3.解決問題的思路：

業(yè)務(wù)上要盡量防止熱點(diǎn)key的設(shè)計(jì)，例如我們可以把北京、上海等熱

點(diǎn)城市分成不同的區(qū)域，并進(jìn)行單獨(dú)處理；技術(shù)上出現(xiàn)熱點(diǎn)時(shí)，要調(diào)整

方案打散原來的key,防止直接聚合；此外Flink還提供了大量的功能可

以防止數(shù)據(jù)傾斜

17.Flink中的Time有哪幾種

Flink中的時(shí)間有三種類型，如下列圖所示：

EventTime：是事件創(chuàng)立的時(shí)間。它通常由事件中的時(shí)間戳描述，例

如采集的日志數(shù)據(jù)中，每一條日志都會(huì)記錄自己的生成時(shí)間，F(xiàn)link通

過時(shí)間戳分配器訪問事件時(shí)間戳。

IngestionTime：是數(shù)據(jù)進(jìn)入Flink的時(shí)間。

ProcessingTime：是每一個(gè)執(zhí)行基于時(shí)間操作的算子的本地系統(tǒng)時(shí)間,

與機(jī)器相關(guān)，默認(rèn)的時(shí)間屬性就是

ProcessingTimeo

例如，一條日志進(jìn)入Flink的時(shí)間為2021-01-2210:00:00,123,到達(dá)

Window的系統(tǒng)時(shí)間為2021-01-2210:00:01.234,口志的內(nèi)容如下：

2021-01-0618:37:15.624INFOFailovertorm2對(duì)于業(yè)務(wù)來說，要統(tǒng)

計(jì)Imin內(nèi)的故障日志個(gè)數(shù)，哪個(gè)時(shí)間是最有意義的？一一eventTime,

因?yàn)槲覀円鶕?jù)日志的生成時(shí)間進(jìn)行統(tǒng)計(jì)。

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

Flink中WaterMark和Window機(jī)制解決了流式數(shù)據(jù)的亂序問題，對(duì)

于因?yàn)檠舆t而順序有誤的數(shù)據(jù)，可以根據(jù)eventTime進(jìn)行業(yè)務(wù)處理，

對(duì)于延遲的數(shù)據(jù)Flink也有自己的解決方法，主要的方法是給定一個(gè)

允許延遲的時(shí)間，在該時(shí)間范圍內(nèi)仍可以接受處理延遲數(shù)據(jù)

設(shè)置允許延遲的時(shí)間是通過allowedLateness(lateness:Time)設(shè)置

保存延遲數(shù)據(jù)那么是通過sideOutputLateData(outputTag:

OutputTag[T])保存

獲取延遲數(shù)據(jù)是通過DataStream.getSideOutput(tag:OutputTag[X])

獲取文章推薦：

Flink中極其重要的Time與Window詳細(xì)解析

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

數(shù)據(jù)傾斜指的是數(shù)據(jù)在不同的窗口內(nèi)堆積的數(shù)據(jù)量相差過多。本質(zhì)上產(chǎn)

生這種情況的原因是數(shù)據(jù)源頭發(fā)送的數(shù)據(jù)量速度不同導(dǎo)致的。出現(xiàn)這種

情況一般通過兩種方式來解決：

在數(shù)據(jù)進(jìn)入窗口前做預(yù)聚合

重新設(shè)計(jì)窗口聚合的key

20.FlinkCEP編程中當(dāng)狀態(tài)沒有到達(dá)的時(shí)候會(huì)將數(shù)

據(jù)保存在哪里

在流式處理中，CEP當(dāng)然是要支持EventTime的，那么相對(duì)應(yīng)的也要

支持?jǐn)?shù)據(jù)的遲到現(xiàn)象，也就是watermark的處理邏輯。CEP對(duì)未匹配

成功的事件序列的處理，和遲到數(shù)據(jù)是類似的。在FlinkCEP的處理邏

輯中，狀態(tài)沒有滿足的和遲到的數(shù)據(jù)，都會(huì)存儲(chǔ)在一個(gè)Map數(shù)據(jù)結(jié)構(gòu)

中，也就是說，如果我們限定判斷事件序列的時(shí)長為5分鐘，那么內(nèi)存

中就會(huì)存儲(chǔ)5分鐘的數(shù)據(jù)，這在我看來，也是對(duì)內(nèi)存的極大損傷之一。

推薦閱讀：一文學(xué)會(huì)FlinkCEP

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

們?cè)趯?shí)際生產(chǎn)環(huán)境中可以從四個(gè)不同層面設(shè)置并行度:

1.操作算子層面(OperatorLevel)

.map(ne\vRollmgAdditionMapper()).setParallelism(l0)”將操作算了設(shè)置并行度

$FLINK_HOME/bin/flink的-p參數(shù)修改并行度

env.setParallelism(10)

全局配置在flink-conf.yaml文件中,parallelism.default,默認(rèn)

是1：可以設(shè)置默認(rèn)值大一點(diǎn)

需要注意的優(yōu)先級(jí)：算子層面〉環(huán)境層面)客戶端層面〉系統(tǒng)層面。

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

在一個(gè)FlinkJob中，數(shù)據(jù)需要在不同的task中進(jìn)行交換，整個(gè)數(shù)據(jù)交

換是有TaskManager負(fù)責(zé)的，TaskManager的網(wǎng)絡(luò)組件首先從緩沖

buffer中收集records,然后再發(fā)送。

Records并不是一個(gè)一個(gè)被發(fā)送的，是積累一個(gè)批次再發(fā)送，batch技

術(shù)可以更加高效的利用網(wǎng)絡(luò)資源。

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

Flink并不是將大量對(duì)象存在堆上，而是將對(duì)象都序列化到一個(gè)預(yù)分配

的內(nèi)存塊上。此外，F(xiàn)link大量的使用了堆外內(nèi)存。如果需要處理的數(shù)

據(jù)超出了內(nèi)存限制，那么會(huì)將局部數(shù)據(jù)存儲(chǔ)到硬盤上。Flink為了直接

操作一進(jìn)制數(shù)據(jù)實(shí)現(xiàn)了自己的序列化框架。

24.介紹下Flink的序列化

Flink摒棄了Java原生的序列化方法，以獨(dú)特的方式處理數(shù)據(jù)類型和

序列化，包含自己的類型描述符，泛型類型提取和類型序列化框架。

Typeinformation是所有類型描述符的基類。它揭示了該類型的一些基

本屬性，并且可以生成序列化器。

Typeinformation支持以下幾種類型：

BasicTypelnfo:任意Java基本類型或String類型

BasicArrayTypelnfo:任意Java基本類型數(shù)組或String數(shù)組

WritableTypelnfo:任意HadoopWritable接口的實(shí)現(xiàn)類

任意的類型（支持）

TupleTypelnfo:FlinkTupleTupleltoTuple250Flink

tuples是固定長度固定類型的JavaTuple實(shí)現(xiàn)

CaseCassTypelnfo:任意的ScalaCaseClass（包括Scalatuples）

PojoTypelnfo:任意的POJO(JavaorScala),例如，Java對(duì)象的所有成

員變量，要么是public修飾符定義，要么有g(shù)etter/setter方法

GenericTypelnf。:任意無法匹配之前幾種類型的類

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

基于狀態(tài)后端。

2.

基于HyperLogLog：不是精準(zhǔn)的去重。

4.

基于布隆過濾器(BloomFilter)；快速判斷一個(gè)key是否存在于某容器,

不存在就直接返回。

5.

基于BitMap；用一個(gè)bit位來標(biāo)記某個(gè)元素對(duì)應(yīng)的Value,而Key即是

該元素。由于采用了Bit為單位來存儲(chǔ)數(shù)據(jù)，因此可以大大節(jié)省存儲(chǔ)空

間。

6.

基于外部數(shù)據(jù)庫；選擇使用Redis或者HBase存儲(chǔ)數(shù)據(jù)，我們只需要

設(shè)計(jì)好存儲(chǔ)的Key即可，不需要關(guān)心Flink任務(wù)重啟造成的狀態(tài)喪失問

題。

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

構(gòu)建抽象語法樹的事情交給了Calcite去做。SQLquery會(huì)經(jīng)過Calcite

解析器轉(zhuǎn)變成SQL節(jié)點(diǎn)樹，通過驗(yàn)證后構(gòu)建成Calcite的抽象語法樹（也

就是圖中的LogicalPlan）。另一邊，TableAPI上的調(diào)用會(huì)構(gòu)建成Table

API的抽象語法樹，并通過Calcite提供的RelBuilder轉(zhuǎn)變成Calcite的

抽象語法樹。然后依次被轉(zhuǎn)換成邏輯執(zhí)行計(jì)劃和物理執(zhí)行計(jì)劃，在提

交任務(wù)后會(huì)分發(fā)到各個(gè)TaskManager■中運(yùn)行，在運(yùn)行時(shí)會(huì)使用Janino

編譯器編譯代碼后運(yùn)行。

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

1.0DS層采用什么壓縮方式和存儲(chǔ)格式?

壓縮采用Snappy,存儲(chǔ)采用orc,壓縮比是100g數(shù)據(jù)壓縮完10g左右。

2.DWD層做了哪些事？

1.數(shù)據(jù)清洗?空值去除

比方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的本地磁盤上。

Q川共享存儲(chǔ)的基本思想來自于Paxos算法，采用多個(gè)稱為

JournalNode的節(jié)點(diǎn)組成的JournalNode集群來存儲(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)腦裂問題嗎？怎么解決腦

裂假設(shè)NameNode1當(dāng)前為Active狀態(tài)，NameNode2

當(dāng)前為Standby狀態(tài)。如果某一時(shí)刻N(yùn)ameNode1對(duì)過濾核心字

段無意義的數(shù)據(jù)，比方訂單表中訂單id為null,

支付表中支付id為空對(duì)手機(jī)號(hào)、身份證號(hào)等敏感數(shù)據(jù)脫敏

對(duì)業(yè)務(wù)數(shù)據(jù)傳過來的表進(jìn)行維度退化和降維。

?將用戶行為寬表和業(yè)務(wù)表進(jìn)行數(shù)據(jù)一致性處理清洗的手段

?Sqkmr>rdd>kettle>Python（工程中采用sql進(jìn)行清除）

3.DWS層做了哪些事？

1.DWS層有3?5張寬表（處理100-200個(gè)指標(biāo)70%以上的需求）

具體寬表名稱：用戶行為寬表，用戶購買商品明細(xì)行為寬表，商品寬表，

購物車寬表，物流寬表、登錄注冊(cè)、售后等。

1.哪個(gè)寬表最寬？大概有多少個(gè)字段？最寬的是用戶行為寬

表。大概有60-100個(gè)字段

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

保證在數(shù)據(jù)采集的時(shí)候不喪失數(shù)據(jù)，這個(gè)尤為重要，如果在數(shù)據(jù)采集的

時(shí)候就已經(jīng)不準(zhǔn)確，后面很難到達(dá)期望值

3.

在數(shù)據(jù)處理的時(shí)候不喪失數(shù)據(jù)，例如sparkstreaming處理

kafka數(shù)據(jù)的時(shí)候，要保證數(shù)據(jù)不喪失，這個(gè)尤為重要4.

5.

前兩步中，如果無法保證數(shù)據(jù)的完整性，那么就要通過離線計(jì)算進(jìn)

行數(shù)據(jù)的校對(duì)，這樣才能保證我們能夠得到期望值

6.

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

數(shù)倉建設(shè)中，最重要的是數(shù)據(jù)準(zhǔn)確性,

數(shù)據(jù)的真正價(jià)值在于數(shù)據(jù)驅(qū)動(dòng)決策，通

過數(shù)據(jù)指導(dǎo)運(yùn)營，在一個(gè)不準(zhǔn)確的數(shù)據(jù)

驅(qū)動(dòng)下，得到的一定是錯(cuò)誤的數(shù)據(jù)分

析，影響的是公司的業(yè)務(wù)開展決策，最

終導(dǎo)致公司的策略調(diào)控失敗。

3.數(shù)據(jù)倉庫建模怎么做的數(shù)倉建設(shè)中最

常用模型-Kimball維度建模詳解

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

單表數(shù)據(jù)量監(jiān)控

一張表的記錄數(shù)在一個(gè)的范圍內(nèi)，或者上下浮動(dòng)不會(huì)超過某個(gè)閾值

SQL結(jié)果：var數(shù)據(jù)量=selectcount（*）from表where時(shí)間等

過濾條件

報(bào)警觸發(fā)條件設(shè)置；如果數(shù)據(jù)量不在［數(shù)值下限，數(shù)值上限］,那

么觸發(fā)報(bào)警

同比增加：如果（（本周的數(shù)據(jù)量-上周的數(shù)據(jù)量）/上周的數(shù)據(jù)量

*100）不在［比例下線，比例上限］,那么觸發(fā)報(bào)警

環(huán)比增加：如果（（今天的數(shù)據(jù)量-昨天的數(shù)據(jù)量）/昨天的數(shù)據(jù)量

*100）不在［比例下線,比例上限］,那么觸發(fā)報(bào)警

報(bào)警觸發(fā)條件設(shè)置一定要有。如果沒有配置的閾值，不能做監(jiān)控日

活一、周活、月活、留存（日周月）、轉(zhuǎn)化率（日、

周、月）GMV（日、周、月）復(fù)購率（日周月）

單表空值檢測(cè)

某個(gè)字段為空的記錄數(shù)在一個(gè)范圍內(nèi)，或者占總量的百分比在某個(gè)

閾值范圍內(nèi)

目標(biāo)字段：選擇要監(jiān)控的字段，不能選〃無〃

1.

SQL結(jié)果:var異常數(shù)據(jù)量=selectcount（*）from表where目標(biāo)字段

isnull

單次檢測(cè)：如果（異常數(shù)據(jù)量）不在［數(shù)值下限，數(shù)值上限］，那么

觸發(fā)報(bào)警

單表重復(fù)值檢測(cè)

一個(gè)或多個(gè)字段是否滿足某些規(guī)那么

目標(biāo)字段：第一步先正常統(tǒng)計(jì)條數(shù)；selectcount（*）form表；

第二步，去重統(tǒng)計(jì);selectcount（*）from表groupby某個(gè)字

段

第一步的值和第二步的值做減法，看是否在上下線閥值之內(nèi)

單次檢測(cè)：如果（異常數(shù)據(jù)量）不在［數(shù)值下限，數(shù)值上限］，那么

觸發(fā)報(bào)警8.

跨表數(shù)據(jù)量比照

主要針對(duì)同步流程，監(jiān)控兩張表的數(shù)據(jù)量是否一致1.

SQL結(jié)果：count（本表）-count（關(guān)聯(lián)表）2.

3.

閾值配置與〃空值檢測(cè)〃相同4.

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

數(shù)據(jù)商業(yè)分析的目標(biāo)是利用大數(shù)據(jù)為所有職場(chǎng)人員做出迅捷，高質(zhì)，

高效的決策提供可規(guī)模化的解決方案。商業(yè)分析是創(chuàng)造價(jià)值的數(shù)據(jù)

科學(xué)。

數(shù)據(jù)商業(yè)分析中會(huì)存在很多判斷：

1.觀察數(shù)據(jù)當(dāng)前發(fā)生了什么？

比方想知道線上渠道A、B各自帶來了多少流量，新上線的產(chǎn)品有

多少用戶喜歡，新注冊(cè)流中注冊(cè)的人數(shù)有多少。這些都需要通過數(shù)

據(jù)來展示結(jié)果。

1.理解為什么發(fā)生？

我們需要知道渠道A為什么比渠道B好，這些是要通過數(shù)據(jù)去發(fā)現(xiàn)

的。也許某個(gè)關(guān)鍵字帶來的流量轉(zhuǎn)化率比其他都要低，這時(shí)可以通

過信息、知識(shí)、數(shù)據(jù)沉淀出發(fā)生的原因是什么。

1.預(yù)測(cè)未來會(huì)發(fā)生什么？

在對(duì)渠道A、B有了判斷之后，根據(jù)以往的知識(shí)預(yù)測(cè)未來會(huì)發(fā)生什

么。在投放渠道C、D的時(shí)候，猜想渠道C比渠道D好，當(dāng)上線新的

注冊(cè)流、新的優(yōu)化，可以知道哪一個(gè)節(jié)點(diǎn)比較容易出問題，這些都

是通過數(shù)據(jù)進(jìn)行預(yù)測(cè)的過程。

1.商業(yè)決策

所有工作中最有意義的還是商業(yè)決策，通過數(shù)據(jù)來判斷應(yīng)該做什么。

這是商業(yè)分析最終的目的。

算法

大數(shù)據(jù)面試中考察的算法相對(duì)容易一些，?？嫉挠信判蛩惴?，查找

算法，二義樹等，卜面講解一些最容易考的算法。

1.排序算法

十種常見排序算法可以分為兩大類：

比擬類排序：通過比擬來決定元素間的相對(duì)次序，由于其時(shí)間復(fù)雜

度不能突破O(nlogn),因此也稱為非線性時(shí)間比擬類排序。

非比擬類排序：不通過比擬來決定元素間的相對(duì)次序，它可

以突破基于比擬排序的時(shí)間下界，以線性時(shí)間運(yùn)行，因此也稱為線

性時(shí)間非比擬類排序。

算法復(fù)雜度：

相關(guān)概念：

穩(wěn)定：如果a原本在b前面，而a二b,排序之后a仍然在b的前面。

不穩(wěn)定：如果a原本在b的前面，而a二b,排序之后a可能會(huì)出現(xiàn)

在b的后面。

時(shí)間復(fù)雜度：對(duì)排序數(shù)據(jù)的總的操作次數(shù)。反映當(dāng)n變化時(shí)，操作次

數(shù)呈現(xiàn)什么規(guī)律。

空間復(fù)雜度：是指算法在計(jì)算機(jī)內(nèi)執(zhí)行時(shí)所需存儲(chǔ)空間的度量，它

也是數(shù)據(jù)規(guī)模n的函數(shù)。

下面講解大數(shù)據(jù)中最?？嫉膬煞N：快排和歸并

1）快速排序

快速排序的基本思想：通過一趟排序?qū)⒋庞涗浄指舫瑟?dú)立的兩局

部，其中一局部記錄的關(guān)鍵字均比另一局部的關(guān)鍵字小，那么可分

別對(duì)這兩局部記錄繼續(xù)進(jìn)行排序，以到達(dá)整個(gè)序列有序。

算法描述

快速排序使用分治法來把一個(gè)串（list）分為兩個(gè)子串（sub-lists）o

具體算法描述如下：

從數(shù)列中挑出一個(gè)元素，稱為〃基準(zhǔn)〃（pivot）;

重新排序數(shù)列，所有元素比基準(zhǔn)值小的擺放在基準(zhǔn)前面，所有元素

比基準(zhǔn)值大的擺在基準(zhǔn)的后面(相同的數(shù)可以到任一邊)。在這個(gè)分

區(qū)退出之后，該基準(zhǔn)就處于數(shù)列的中間位置。這個(gè)稱為分區(qū)(partition)

操作；

遞歸地(recursive)把小于基準(zhǔn)值元素的子數(shù)列和大于基準(zhǔn)值元素的

子數(shù)列排序。

代碼實(shí)現(xiàn)：

functionquickSorl(air,lefl,righl)[len=

left二typeofleft!='numbci,？0:left,right=typeofright!='number'?len-1:right;|

if(left<right){

artitionlndex=partition(arr,left,right);uickSort(arr,left,partitionindex-1);

IuickSort(arrj)artitionlndex+1,right);returnarr;

Jvarpivotleft,

functionpartition(air,leftjight)(

varpivol=left,"設(shè)定基準(zhǔn)值5V3)

for(vari=index;iv=right;i++)1

s\vap(airi,

iTTIirSwza

fo「(vari二index;iv=right;i++

s\vap(airi,

swap(arr,pivot,index-MH\ai-temp=2曬;人\1arr|i|=

應(yīng)的ZKFailoverController進(jìn)程發(fā)生了“假死”現(xiàn)象,那么

Zookeeper服務(wù)端會(huì)認(rèn)為NameNodel掛掉了，根據(jù)前面的

主備切換邏輯，NameNode2會(huì)替代NameNodel進(jìn)入

Active狀態(tài)。但是此時(shí)NameNodel可能仍然處于Active狀

態(tài)正常運(yùn)行，這樣NameNodel和NameNode2都處于

Active狀態(tài)，都可以對(duì)外提供服務(wù)。這種情況稱為腦裂。

腦裂對(duì)于NameNode這類對(duì)數(shù)據(jù)一致性要求非常高的系統(tǒng)來說是

災(zāi)難性的，數(shù)據(jù)會(huì)發(fā)生錯(cuò)亂且無法恢復(fù)。zookeeper社區(qū)對(duì)這種問

題的解決方法叫做fencing,中文翻譯為隔離，也就是想方法把舊的

ActiveNameNode隔離起來，使它不能正常對(duì)外提供服務(wù)。

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

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

接口的transitionToStandby方法，看能不能把它轉(zhuǎn)換為Standby

狀態(tài)。

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

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

施,通常會(huì)選擇sshfence：

arr[j]二tem

2)歸并排序

歸并排序是建立在歸并操作上的一種有效的排序算法。該算法是采

用分治法(DivideandConquer)的一個(gè)非常典型的應(yīng)用。將已有序

的子序列合并，得到完全有序的序列；即先使每個(gè)子序列有序，再

使子序列段間有序。假設(shè)將兩個(gè)有序表合并成一個(gè)有序表，稱為2-

路歸并。

算法描述

把長度為n的輸入序列分成兩個(gè)長度為n/2的子序列；

對(duì)這兩個(gè)子序列分別采用歸并排序；

將兩個(gè)排序好的子序列合并成一個(gè)最終的排序序列。

代碼實(shí)現(xiàn)：

functionmcrgeSort(air){varlen=arr.lcngth;!

if(len<2)reiurnarr;

middle=MMhJour(len/leftmslicc(0

righi二4iT.srcturnmerge(mergcSort(left),mcrgcSort(right));

rcsiilt.push(lcf[.shin()):……”7

result.push(left.shift());whilc(right.length)

resuk.push(right.shif[());

returnresult;

2.查找算法

七大查找算法：L順序查找、2.二分查找、3,插值查找、4.斐

波那契查找、5.樹表查找、6.分塊查找、7.哈希查找

這些杳找算法中：分杳找是最容易考察的，下面講解二分杳找算

法。

1)二分查找

二分查找也稱折半查找(BinarySearch),它是一種效率較

高的查找方法。但是，折半查找要求線性表必須采用順序存

儲(chǔ)結(jié)構(gòu)，而且表中元素按關(guān)鍵字有序排列，注意必須要是有

序排列o

代碼實(shí)現(xiàn)：

1.使用遞歸

retum找到的位置口3o\AcstaticintrecursionBinarySearch(intn

airjntkey,intlow,inthigh){

if(key<airRow]||key>arr[high|||low>high){

return

intmiddle=(low+high)/2;

returnrecursionBinarySearch(arr,key,low,middle-I

.?if(arr[middle]<kcy){

returnrecursionBinarySearch(arr,key,middle+1,high);

)clse(

1.

returnmiddle;

*不使用遞歸的二分查熱

1.不使用遞歸實(shí)現(xiàn)（while循環(huán)）

*不使用遞歸的二分查熱

Nitle:commonBinarvSeardi

ublicstaticin〔commonBinarySearch(int

high二aiT.Icny由一:

i1(key<aglow]||key>anlhigh]IIlow〉high){MB」

〃比關(guān)鍵字大那么關(guān)鍵字在左區(qū)域

"比關(guān)鍵字小那么關(guān)鍵字在右區(qū)域low二middle+IHUf'J：廉

return-1:仍然沒有找到,那么返回-1

定義；二叉樹，是一種特殊的樹，二叉樹的任意一個(gè)節(jié)點(diǎn)的度都不大

于2,不包含度的節(jié)點(diǎn)稱之為葉子。

遍歷方式：二叉樹的遍歷方式有三種，中序遍歷，先序遍歷，后序遍

歷。

將一個(gè)數(shù)組中的數(shù)以二叉樹的存儲(chǔ)結(jié)構(gòu)存儲(chǔ)，并遍歷打?。捍a實(shí)現(xiàn):

importjava.util.ArrayLisliimport|binlree

publicbintrcc

^^^^bintrceright/Jpublicbinlree

pritalcObjectdata/B

publicLisivbintree>datas;|

ublicbintree(bintreeleft,bintreeght.Objectdata)iaIH

publicbintree(Objectdata)[IZH)

publicbintree0(□

datasm心AiTayList<birMrcc>(

binIrcc(o))

〃第一個(gè)數(shù)為根節(jié)點(diǎn)

root二datas.get(O)〃〃‘立

ti=0;i<objsjength/2;i++){Z.按//

if(i*2+2<datas.size0){〃防止陋R矽時(shí)依八版的datas.geKi).right=datas.get(i*2+2);

〃無序遞歷publicvoidpreorder(bintreeroot)

if(root!=null){

System.out.println(root.data);

preorder(root.right);I)i

publicvoidinorder(bint「eeroot){linordcr(rooL1cft)

System,out.Drinlln(ioo【.data);in()i'dcr(root.right

publicvoidafterorder(bintreeroot)<System.out.Drintln(root.data);aflerorder任ooleJ);"AAB;il-

lcro[-clct-(i-oc)Lriglil,):AAAH

voidmain(Strine||arRS){■bintreebintree二iewbintree()「AAB

Object口a=[245,7,l,a2,32.5L22);

biniree.preorder(bintree.rool);

sshfence：通過SSH登錄到目標(biāo)機(jī)器上,執(zhí)行命令fuser

將對(duì)應(yīng)的進(jìn)程殺死；

shellfence：執(zhí)行一個(gè)用戶自定義的shell腳本來將對(duì)應(yīng)的

進(jìn)程隔離。

8.小文件過多會(huì)有什么危害，如何防止Hadoop上大量

HDFS元數(shù)據(jù)信息存儲(chǔ)在NameNode內(nèi)存中，因此過多的

小文件必定會(huì)壓垮NameNode的內(nèi)存。

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

占用一個(gè)block,那么NameNode大約需要2G空間。

如果存儲(chǔ)1億個(gè)文件，那么NameNode需要20G空間。

顯而易見的解決這個(gè)問題的方法就是合并小文件，可以選擇在客戶端

上傳時(shí)執(zhí)行一定的策略先合并，或者是使用Hadoop的

CombineFilelnputFormat\<K,V\>實(shí)現(xiàn)小文件的合并。

9.請(qǐng)說下HDFS的組織架構(gòu)Client：客戶端

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

Block,然后進(jìn)行存儲(chǔ)與NameNode交互，獲取文件的位置信息

與DataNode交互，讀取或者寫入數(shù)據(jù)Client提供一些命令來管理

HDFS,比方啟動(dòng)關(guān)閉HDFS、訪問

HDFS目錄及內(nèi)容等NameNode：名稱節(jié)點(diǎn)，也稱主節(jié)點(diǎn)，存儲(chǔ)數(shù)據(jù)

的元數(shù)據(jù)信息，不存儲(chǔ)具體的數(shù)據(jù)

管理HDFS的名稱空間管理數(shù)據(jù)塊（Block）映射信息

配置副本策略

處理客戶端讀

寫請(qǐng)求

DataNode：數(shù)據(jù)節(jié)點(diǎn)，也稱從節(jié)點(diǎn)。NameNodeF達(dá)命

令，DataNode執(zhí)行實(shí)際的操作

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

行數(shù)據(jù)塊的讀/寫操

作

SecondaryNameNode：并非NameNode的熱備。當(dāng)

NameNode掛掉的時(shí)候，它并不能馬上替換NameNode并提

供服務(wù)

8.

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

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

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

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

簡單概述：

inputFile通過split被切割為多個(gè)split文件，通過Record按行讀

取內(nèi)容給map（自己寫的處理邏輯的方法），數(shù)據(jù)被map處理完之

后交給OutputCollect收集器，對(duì)其結(jié)果key進(jìn)行分區(qū)（默認(rèn)使用

的hashPartitioner）,然后寫入buffer,每個(gè)m叩task都有一個(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ì)步驟：

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

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

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

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

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

據(jù)，返回〈key,value），Key表示每行首字符偏移值，Value表示

這一行文本內(nèi)容。

讀取block返回Vkey,value>,進(jìn)入用戶自己繼承的Mapper類

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

一次。

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

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

認(rèn)使用HashPartitionero9.

接下來，會(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ù)組。

10.

11.

當(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é)做的排序。

12.

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

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

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

進(jìn)行Merge合并，因