Hadoop大數(shù)據(jù)基礎(chǔ)與應(yīng)用(習(xí)題答案)

第1章Hadoop技術(shù)概述

l.Hadoop2.0包含哪些核心組件？

MapReduce、HDFS、YARN

2.Hadoop包含哪些優(yōu)勢？

方便、彈性、健壯、簡單

3.Hadoop有哪些應(yīng)用領(lǐng)域？

運營商、電子商務(wù)、在線旅游、欺詐檢測、醫(yī)療保健、能源開采、金融、直播、在線教育等

等

4.Hadoop有幾種運行模式？

單機模式、偽分布模式、完全分布式模式

5.Hadoop偽分布集群包含哪些守護進程？

DataNode、NodeManager、ResourceManager>SecondaryNameNode^NameNode

第2章Hadoop分布式文件系統(tǒng)(HDFS)

1.簡述HDFS的設(shè)計理念？

HDFS的設(shè)計理念來源于非常樸素的思想：即當(dāng)數(shù)據(jù)文件的大小超過單臺計算機的存儲能力

時，就有必要將數(shù)據(jù)文件切分并存儲到由若干臺計算機組成的集群中，這些計算機通過網(wǎng)絡(luò)

進行連接，而IIDF5作為一個抽象層架構(gòu)在集群網(wǎng)絡(luò)之上，對外提供統(tǒng)一的文件管理功能，

對于用戶來說就感覺像在操作一臺計算機一樣，根本感受不到HDFS底層的多臺計算機，

而且HDFS還能夠很好地容忍節(jié)點故障且不丟失任何數(shù)據(jù)。

2.簡述FSImage和EditLog的合并過程？

FSImage和EditLog合并的詳細步驟如下所示。

(1)SecondaryNameNode(即從元數(shù)據(jù)節(jié)點)引導(dǎo)NameNode(即元數(shù)據(jù)節(jié)點)滾動更新

EditLog,并開始將新的EditLog寫進edits.newo

(2)SecondaryNameNode將NameNode的FSImage(fsimage)和EditLog【edits)復(fù)制至lj本地的檢

查點目錄。

(3)SecondaryNameNode將FSImage(fsimage)導(dǎo)入內(nèi)存,并回放EditLog(edits),將其合并到

FSImage(fsimage.ckpt),并將新的FSImage(fsimage.ckpt)壓縮后寫入磁盤。

(4)SecondaryNameNode將新的FSImage(fsimage.ckpt)傳回NameNode。

(5)NameNode在接收新的FSImage(fsimage.ckpt)后，將fsimage.ckpt替換為fsimage,然后

直接加載和啟用該文件。

(6)NameNodeEditLog(BPedits.new)^^g^9EditLog(BPedits)o默認情況下，該過程

1小時發(fā)生一次，或省當(dāng)EdltLog達到默認值(如64MB)也會觸發(fā)，具體控制參數(shù)可以通過配

置文件進行修改。

3.簡述HDFS的數(shù)據(jù)讀寫流程？

HDFS讀取數(shù)據(jù)流程主要包括以下幾個步驟。

1.客戶端通過調(diào)用FileSystem對象的open。方法來打開希望讀取的文件，對于HDFS來說,

這個對象是DistributedFileSystem的一個實例。

數(shù)據(jù)節(jié)點數(shù)據(jù)節(jié)點數(shù)據(jù)節(jié)點

圖2-4客戶端讀取HDFS中的數(shù)據(jù)

2.DistributedFileSystem通過RPC獲得文件的第■批塊的位置信息(Lccations),同一個塊按

照重復(fù)數(shù)會返回多個位置信息，這些位置信息按照Hadoop拓撲結(jié)構(gòu)排序，距離客戶端近的

排在前面。

3.前兩步會返回一個文件系統(tǒng)數(shù)據(jù)輸入流(FSDatalnputStream)對象，該對象會被封裝為分

布式文件系統(tǒng)輸入流(DFSInputStream)對象，DFSInputStream可以方便地管理DataNode

和NameNode數(shù)據(jù)流?？蛻舳苏{(diào)用read。方法，DFSInputStream會找出離客戶端最近的

DataNode并連接。

4.數(shù)據(jù)從DataNode源源不斷地流向客戶端。

5.如果第一個塊的數(shù)據(jù)讀完了，就會關(guān)閉指向第一個塊的DataNode的連接，接著讀取下一

個塊。這些操作對客戶端來說是透明的，從客戶端的角度來看只是在讀一個持續(xù)不斷的數(shù)據(jù)

流。

6.如果第一批塊全部讀完了，DFSInputStream就會去NameNode拿下一批塊的位置信息，然

后繼續(xù)讀。如果所有的塊都讀完了，這時就會關(guān)閉所有的流。

HDFS的寫入數(shù)據(jù)流程主要包括以下幾個步驟。

1.客戶端通過調(diào)用DistributedFileSystem的create。方法創(chuàng)建新文件。

數(shù)據(jù)節(jié)點數(shù)據(jù)節(jié)點數(shù)據(jù)節(jié)點

圖2-5HDFS的寫數(shù)據(jù)流程

2.DistributedFileSystem通過RPC調(diào)用NameNode去創(chuàng)建一個沒有塊關(guān)聯(lián)的新文件。在文件

創(chuàng)建之前，NameNode會做各種校驗，比如文件是否存在，客戶端有無權(quán)限去創(chuàng)建等。如

果校驗通過，NameNode就會創(chuàng)建新文件，否則就會拋出I/O異常。

3.前兩步結(jié)束后，會返回文件系統(tǒng)數(shù)據(jù)輸出流（FSDataOutputStream）的對象，與讀文件的

時候相似，F(xiàn)SDataOutputStream被封裝成分布式文件系統(tǒng)數(shù)據(jù)輸出流（DFSOutputStream）,

DFSOutputStream可以協(xié)調(diào)NameNode和DataNode?？蛻舳碎_始寫數(shù)據(jù)到DFSOutputStream?

DFSOutputStream會把數(shù)據(jù)切成一個個小的數(shù)據(jù)包（packet）,然后排成數(shù)據(jù)隊列（dataquene）,

4.接下來，數(shù)據(jù)隊列中的數(shù)據(jù)包首先傳輸?shù)綌?shù)據(jù)管道（多個數(shù)據(jù)節(jié)點組成數(shù)據(jù)管道）中的第

一個DataNode中（寫數(shù)據(jù)包），第一個DataNode又把數(shù)據(jù)包發(fā)送到第二個DataNode中，

依次類推。

5.DFSOutputStream還維護著一個響應(yīng)隊列（ackquene）,這個隊列也是由數(shù)據(jù)包組成，用于

等待DataNode收到數(shù)據(jù)后返回響應(yīng)數(shù)據(jù)包，當(dāng)數(shù)據(jù)管道中的所有DataNode都表示已經(jīng)收

到響應(yīng)信息的時候，這時ackquene才會把對應(yīng)的數(shù)據(jù)包移除掉。

6.客戶端寫數(shù)據(jù)完成后，會調(diào)用close。方法關(guān)閉寫入流。

7.客戶端通知NameNode把文件標記為已完成，然后NameNode把文件寫成功的結(jié)果反饋給

客戶端。此時就表示客戶端已完成了整個HDFS的寫數(shù)據(jù)流程。

4.簡述HDFS的副本存儲策略？

新版本的副本存放策略的基本思想如下。

副本1存放在Client所在的節(jié)點上（假設(shè)Client不在集群的范圍內(nèi)，則第一個副本存儲節(jié)點

是隨機選取的，當(dāng)然系統(tǒng)會嘗試不選擇那些太滿或者太忙的節(jié)點）。

副本2存放在與第一個節(jié)點不同機架中的一個節(jié)點中（隨機選擇）。

副本3和副本2在同一個機架，隨機放在不同的節(jié)點中。

假設(shè)還有很多其他的副本，那么剩余的副本就隨機放在集群的各個節(jié)點中。

5.簡述HDFS的高可用原理？

HDFS集群中通常由2臺獨立的機器來配置NameNode角色，無論在任何時候，集群中只能

有一個NameNode是Active狀態(tài)，而另一個NameNode是Standby狀態(tài)。Active狀態(tài)的

NameNode作為主節(jié)點負責(zé)集群中所有客戶端操作，Standby狀態(tài)的NameNode僅僅扮演一

個備川節(jié)點的角色，以便于在ActiveNameNode掛掉時能第一時間接替它的工作成為主節(jié)點,

從而使得NameNode達到一個熱備份的效果。

為了讓主備NameNode的元數(shù)據(jù)保持一致,它們之間的數(shù)據(jù)同步通過JournalNode集群完成。

當(dāng)任何修改操作在主NameNode上執(zhí)行時，它會將EditLog寫到半數(shù)以上的JournalNode節(jié)

點中。當(dāng)備用NameNode監(jiān)測到JournalNode集群中的EditLog發(fā)生變化時，它會讀取

JournalNode集群中的EditLog,然后同步到FSImage中。當(dāng)發(fā)生故障造成主NameNode宕機

后，備用NameNode在選舉成為主NameNode之前會同步JournalNode集群中所有的EditLog,

這樣就能保證主備NameNode的FSImage一致。新的ActiveNameNode會無縫接替主節(jié)點的

職責(zé)，維護來自客戶端的請求并接受來自DataNode匯報的塊信息，從而使得NameNode達

到高可用的目的。

為了實現(xiàn)主備NameNode故障自動切換，通過ZKFC對NameNode的主各切換進行總體控制。

每臺運行NameNode的機器上都會運行一個ZKFC進程，ZKFC會定期檢測NameNode的健康

狀況。當(dāng)ZKFC檢測到當(dāng)前主NameNode發(fā)生故障時，會借助Zookeepe^集群實現(xiàn)主備選舉，

并自動將備用NameNode切換為Active狀態(tài)，從而接替主節(jié)點的工作對外提供服務(wù)。

第3章Hadoop資源管理系統(tǒng)(YARN)

1.簡述YARN解決了哪些問題?

YARN解決了M叩Reducel.O擴展性差、資源利用率低、通用性差、單點故障問題。

2.簡述YARN的基本架構(gòu)與工作原理？

YARN主要是由資源管理器(ResourceManager),節(jié)點管理器(NodeManager)、應(yīng)用程序管

理器(ApplicationMaster)和相應(yīng)的容器(Container)構(gòu)成的。

YARN的詳細工作原理如下所示。

(1)客戶端(Client)向ResourceManager提交一■個作業(yè)，作業(yè)包括ApplicationMaster程序、

啟動ApplicationMaster的程序和用戶程序(如MapReduce)。

(2)ResourceManager會為該應(yīng)用程序分配一個Container,它首先會跟NodeManager進行

通信，要求它在這個容器中啟動應(yīng)用程序的ApplicationMaster,

(3)ApplicationMaster一旦啟動以后,它首先會向ResourceManager注冊,這樣用戶可以

直接通過ResourceManager看看應(yīng)用程序的運行狀態(tài)，然后它將為各個任務(wù)申請資源并監(jiān)控

它們的運行狀態(tài)，直到任務(wù)運行結(jié)束。它會以輪詢的方式通過RPC協(xié)議向ResourceManager

申請和領(lǐng)取資源，一旦ApplicationMaster申請到資源，它會與NodeManager進行通信，要

求它啟動并運行任務(wù)。

(4)各個任務(wù)通過RPC協(xié)議向ApplicationMaster匯報自己的狀態(tài)和進度，這樣會讓

ApplicationMaster隨時掌握各個任務(wù)的運行狀態(tài)，一旦任務(wù)運行失敗，ApplicationMaster就

會重啟該任務(wù)，重新申請資源。應(yīng)用程序運行完成后，ApplicationMaster就會向

ResourceManager注銷并關(guān)閉。在應(yīng)用程序整個運行過程中，可以通過RPC協(xié)議向

ApplicationMaster查詢應(yīng)用程序當(dāng)前的運行狀態(tài)，當(dāng)然在YARN的Web界面也可?以看到整個

作業(yè)的運行狀態(tài)。

3.簡述YARN是如何實現(xiàn)容錯的？

YARN通過以下幾個方面來保障容錯性。

l.ResourceManager的容錯性保障

ResourceManager存在單點故障，但是可以通過配置實現(xiàn)ResourceManager的HA(高可用),

當(dāng)主節(jié)點出現(xiàn)故障時，可以切換到備用節(jié)點繼續(xù)對外提供服務(wù)。

2.NodeManager的容錯性保障

NodeManager失敗之后，ResourceManager會將失敗的任務(wù)通知對應(yīng)的ApplicationMaster,

由ApplicationMaster來決定如何去處理失敗的任務(wù)。

3.ApplicationMaster的容錯性保障

ApplicationMaster失敗后，由ResourceManager負責(zé)重啟即可。

其中，ApplicationMaster需要處理內(nèi)部任務(wù)的容錯問題。ResourceManager會保存己經(jīng)運行

的任務(wù)，重啟后無須重新運行。

4.簡述YARN的高可用原理？

ResourceManagerHA由一對Active,Standby結(jié)點構(gòu)成，ResourceManager它有個基于

Zookeeper的選舉算法，來決定哪個ResourceManager是active狀態(tài)，

哪個ResourceManager處于Standby狀態(tài)。

ZKFC是ResourceManager進程的一個服務(wù)，非獨立存在，跟HDFS中的不太一樣，而

HDFS中zkfc作為一個獨立的進程存在

(a)監(jiān)控ResourceManager的健康狀態(tài)

(b)向ZK定期發(fā)送心跳。

ResourceManager是通過RMStateStore存儲內(nèi)部數(shù)據(jù)和主要應(yīng)用的數(shù)據(jù)及標記，目前支

持的可替代的RMStateStore實現(xiàn)有：

(a)基于內(nèi)存的MemoryRMStateStore,

(b)基于文件系統(tǒng)的FileSys:emRMStateStore,

(c)基于zookeeper的ZKRMStateStore。

兩個ResourceManager的數(shù)據(jù)共享通過RMStateStore來實現(xiàn)，保持信息狀態(tài)的一致

當(dāng)Active狀態(tài)ResourceManager關(guān)掠了，它會將另外一個ResourceManager狀態(tài)變?yōu)?/p>

Active,并提供服務(wù)。ResourceManagerHA的架構(gòu)模式同NameNodeHA的架構(gòu)模式基本一

致。

5.簡述YARN的各種調(diào)度器原理及使用場景？

先進先出調(diào)度器：將應(yīng)用放置在一個隊列中，然后按照提交的順序(先進先出)運行應(yīng)用。

首先為隊列中第一個應(yīng)用的請求分配資源，第一個應(yīng)用的請求被滿足后再依次為隊列中下一

個應(yīng)用服務(wù)。

容量調(diào)度器：不會通過強行中止來搶占容器(container),因此，如果一個隊列一開始資源

夠用，然后隨著需求增長，資源開始不夠用時，那么這個隊列就只能等著其他隊列釋放容器

資源。緩解這種情況的方法是，為隊列設(shè)置一個最大容量限制，這樣這個隊列就不會過多侵

占其他隊列的容量了。當(dāng)然，這樣做是以犧牲隊列彈性為代價的，因此需要在不斷嘗試和失

敗中找到一個合理的折中。

公平調(diào)度器：假設(shè)有兩個用戶A和B,分別擁有自己的隊列queueA和queueB。A啟動一

個作業(yè)jobl,在B沒有需求時A會分配到全部可用資源；當(dāng)A的作業(yè)仍在運行時B啟動一

個作業(yè)job2,一段時間后，按照我們先前看到的方式，每個作業(yè)都用到了一半的集群資源。

這時，如果B啟動第二個作業(yè)job3且其他作業(yè)仍在運行，那么job3和job2共享資源，因此

B的每個作業(yè)將占用四分之一的集群資源，而A仍繼續(xù)占用一半的集群資源。最終的結(jié)果就

是資源在用戶之間實現(xiàn)了公平共享。

總的來說，如果應(yīng)用場景需要先提交的Job先執(zhí)行，那么就使用FIFOScheduler；如果所有

的Job都有機會獲得到資源，就得使用CapacityScheduler和FairScheduler,CapacityScheduler

不足的地方就是多個隊列資源不能相互搶占，每個隊列會提前分走資源，即使隊列中沒有

Job,所以般情況下都選擇使用FairScheduler；FIFOScheduler?般不會單獨用，公平調(diào)度

支持在某個隊列內(nèi)部選擇FairScheduler還是FIFOScheduler,可以認為FairScheduler是一個

混合的調(diào)度器。

第4章Hadoop分布式計算框架(MapReduce)

1.簡述MapReduce的基本設(shè)計思想？

分而治之、抽象成模型、上升到架構(gòu)

2.簡述MapReduce的優(yōu)缺點？

<i)有點

MapReduce易于編程、良好的擴展性、高容錯性、適合PB級以上數(shù)據(jù)集的離線處理

(2)缺點

不適合實時計算、不適合流式計算、不適合DAG(有向無環(huán)圖)計算

3.簡述MapReduce的shuffle過程？

MapReduce的shuffle過程如下。

(1)map端

map任務(wù)開始輸出中間結(jié)果時，并不是直接寫入磁盤，而是利用緩沖的方式寫入內(nèi)存，并

出于效率的考慮對輸出結(jié)果進行預(yù)排序。

每個map任務(wù)都有一個環(huán)形內(nèi)存緩沖區(qū)，用于存儲任務(wù)輸出結(jié)果。默認情況下，緩沖區(qū)的

大小為100MB,這個值可以通過mapreduce.task.io.sort.mb屬性來設(shè)置。一旦緩沖區(qū)中的數(shù)

據(jù)達到閾值(默認為緩沖區(qū)大小的80%),后臺線程就開始將數(shù)據(jù)刷到磁盤。在數(shù)據(jù)刷寫磁

盤過程中，map任務(wù)的輸出將繼續(xù)寫到緩沖區(qū)，但是如果在此期間緩沖區(qū)被寫滿了，那么

map會被阻塞，直到寫磁盤過程完成為止。

在緩沖區(qū)數(shù)據(jù)刷寫磁盤之前，后臺線程首先會根據(jù)數(shù)據(jù)被發(fā)送到的reducer個數(shù)，將數(shù)據(jù)劃

分成不同的分區(qū)(partition)<.在每個分區(qū)中，后臺線程按照key在內(nèi)存中進行排序，如果此

時有一個combiner函數(shù)，它會在排序后的輸出上運行。運行combiner函數(shù)可以減少寫到磁

盤和傳遞到reducer的數(shù)據(jù)量。

每次內(nèi)存緩沖區(qū)達到溢出閾值，就會刷寫一個溢出文件，當(dāng)map任務(wù)輸出最后一條記錄之

后會有多個溢出文件。在map任務(wù)完成之前，溢出文件被合并成一個已分區(qū)且已排序的輸

出文件。默認如果至少存在3個溢出文件，那么輸出文件寫到磁盤之前會再次運行combinero

如果少于3個溢出文件，那么不會運行combiner,因為map輸出規(guī)模太小不值得調(diào)用

combiner帶來的開銷。在map輸出寫到磁盤的過程中，還可以對輸出數(shù)據(jù)進行壓縮，加快

磁盤寫入速度，節(jié)約磁盤空間，同時也減少了發(fā)送給reducer的數(shù)據(jù)量。

(2)reduce端

map輸出文件位于運行map任務(wù)的NodeManager的本地磁盤，現(xiàn)在NodeManager需要為分

區(qū)文件運行reduce任務(wù)，而且reduce任務(wù)需要集群上若干個map任務(wù)的map輸出作為其

特殊的分區(qū)文件。每個m叩任務(wù)為完成時間可能不同，因此在每個任務(wù)完成時，reduce任

務(wù)就開始復(fù)制其輸出。這就是reduce任務(wù)的復(fù)制階段。默認情況下，reduce任務(wù)有5個復(fù)

制線程，因此可以并行獲取map輸出。

如果map輸出結(jié)果比較小，數(shù)據(jù)會被兔制到reduce任務(wù)的JVM內(nèi)存中，否則，m叩輸出會

被復(fù)制到磁盤中。一旦內(nèi)存緩沖區(qū)達到閾值大小，數(shù)據(jù)合并后會刷寫到磁盤。如果指定了

combiner,在合并期間可以運行combiner,從而減少寫入磁盤的數(shù)據(jù)量。隨著磁盤上的溢出

文件增多，后臺線程會將它們合并為更大的、已排序的文件，這樣可以為后續(xù)的合并節(jié)省時

間。

復(fù)制完所有map輸出后，reduce任務(wù)進入排序階段，這個階段將map輸出進行合并，保持

其順序排序。這個過程是循環(huán)進行的：比如，如果有50個m叩輸出，默認合并因子為10,

那么需要進行5次合并，每次將10個文件合并為一個大文件，因此最后有5個中間文件。

在最后的reduce階段，直接把數(shù)據(jù)輸入reduce函數(shù)，從而節(jié)省了一次磁盤往返過程。因為

最后一次合并，并沒有將這5個中間文件合并成一個已排序的大文件，而是直接合并到

reduce作為數(shù)據(jù)輸入。在reduce階段，對已排序數(shù)據(jù)中的每個key調(diào)用reduce函數(shù)進行處

理，其輸出結(jié)果直接寫出到文件系統(tǒng)，這里一般為HDFS。

4.簡述MapReduce的運行機制？

MapReduce作業(yè)完整的運行過程如下。

(1)提交M叩Reduce作業(yè)

客戶端通過調(diào)用Job對象的waitForCompletion。方法來提交MapReduce作業(yè)。

(2)初始化MapReduce作業(yè)

applicationmaster會對MapReduce作業(yè)進行初始化。

(3)分配任務(wù)

applicationmaster為作業(yè)中的map任務(wù)和reduce任務(wù)向ResourceManager請求容器。

(4)執(zhí)行任務(wù)

ResourceManager的調(diào)度器為任務(wù)分配容器，執(zhí)行map任務(wù)和reduce任務(wù)。

(5)更新進度和狀態(tài)

任務(wù)通過這個接口向自己的applicationmaster報告進度和狀態(tài)。

(6)完成作業(yè)

當(dāng)applicationmaster收到作業(yè)最后一個任務(wù)已完成的通知后，就會將作業(yè)的狀態(tài)設(shè)置為“成

功”。

5.簡述MapReduce作業(yè)容錯機制

在作業(yè)運行過程中，我們需要考慮的容錯實體包括：任務(wù)、applicationmaster^NodeManager

和ResourceManagero

(1)任務(wù)容錯

當(dāng)applicationmaster被告知一個任務(wù)嘗試失敗后，它將重新調(diào)度該任務(wù)的執(zhí)行。

(2)applicationmaster容錯

applicationmaster向ResourceManager發(fā)送周期性的心跳，當(dāng)applicationmaster失敗時，

ResourceManager將檢測到該失敗，并在一個新的容器中重新啟動一個叩plicationmaster實

例。

(3)Nodemanager容錯

對于出現(xiàn)故障的NodeManager節(jié)點，那么曾經(jīng)在其上運行且成功完成的map任務(wù)，如果屬

于未完成的作業(yè)，那么applicationmaster會安排它們重新運行。

(4)ResourceManager容錯

ResourceManager出現(xiàn)故障是比較嚴重的，因為沒有ResourceManager,作業(yè)和任務(wù)容器將

無法啟動。為了實現(xiàn)高可用(HA),有必要以一種active-standby配置模式運行一對

ResourceManagero

第5章Zookeeper分布式協(xié)調(diào)服務(wù)

l.Zookeeper的應(yīng)用場景有哪些?

分布式鎖服務(wù)、配置管理服務(wù)、分布式消息隊列、分布式通知與協(xié)調(diào)服務(wù)等。

2.簡述Zookeeper監(jiān)聽機制？

znode以某種方式發(fā)生變化時，觀察(watcher)機制(觀察機制：一個watcher事件是

一個一次性的觸發(fā)器，當(dāng)被設(shè)置了watcher的znode發(fā)生了改變時，服務(wù)器將這個改變發(fā)送

給設(shè)置了watcher的客戶端，以便通知它們)可以讓客戶端得到通知，可以針對Zookeeper

服務(wù)的操作來設(shè)置觀察，該服務(wù)的其他操作可以觸發(fā)觀察。

在Zookeeper中，引入了wa:cher機制來實現(xiàn)分布式的通知功能,Zookeeper允許客戶

端向服務(wù)端注冊一個watcher監(jiān)視器，當(dāng)服務(wù)端的一些特定事件觸發(fā)了這個watcher監(jiān)視器

之后，就會向指定客戶端發(fā)送一個異步事件通知來實現(xiàn)分布式的通知功能。這種機制稱為注

冊與異步通知機制。

3.Zookeeper包含哪些特性？

最終一致性、可靠性、實時性、等待無關(guān)、原子性、順序性。

4.Zookeeper有幾種部署方式?

單機模式、偽分布式模式、分布式模式

5.簡述Zookeeper工作原理？

Zookeeper的核心就是原子廣播，該原子廣播就是對Zookeeper臭群上所有主機發(fā)送數(shù)

據(jù)包，通過這個機制保證了各個服務(wù)端之間的數(shù)據(jù)同步。那么實現(xiàn)這個機制在Zookeeper中

有一個內(nèi)部協(xié)議，這個協(xié)議有兩種模式，一種是恢復(fù)模式，一種是廣播模式。

當(dāng)服務(wù)剛啟動或者主節(jié)點崩潰后，這個協(xié)議就進入了恢復(fù)模式，當(dāng)主節(jié)點再次被選舉出

來，且大多數(shù)服務(wù)端完成了和主節(jié)點的狀態(tài)同步以后，恢復(fù)模式就結(jié)束了，狀態(tài)同步保證了

主節(jié)點和服務(wù)端具有相同的系統(tǒng)狀態(tài)。一旦主節(jié)點已經(jīng)和多數(shù)的從節(jié)點(也就是服務(wù)端)進

行了狀態(tài)同步后，它就可以開始廣播消息即進入廣播狀態(tài)。

在廣播模式下，服務(wù)端會接受客戶端請求，所有的寫請求都被轉(zhuǎn)發(fā)給主節(jié)點，再由主節(jié)

點發(fā)送廣播給從節(jié)點。當(dāng)半數(shù)以上的從節(jié)點完成數(shù)據(jù)寫請求之后,主節(jié)點才會提交這個更新,

然后客戶端才會收到一個更新成功的響應(yīng)。

第6章Hadoop分布式集群搭建與管理

l.Hadoop包含幾種運行模式？

單機模式、偽分布模式、分布式模式

2.Hadoop集群包含哪些守護進程？其作用是什么？

NameNode：管理文件系統(tǒng)的命名空間，維護著整個文件系統(tǒng)的目錄樹以及目錄樹中的所有

子目錄和文件。

DataNode：在NameNode的指導(dǎo)下完成數(shù)據(jù)的I/O操作。

ZKFailoverController：對NameNode的主備切換進行總體控制。

JournalNode：存儲和管理EditLog日志。

ResourceManager：負責(zé)整個系統(tǒng)的資源管理和調(diào)度。

NodeManager：是整個作業(yè)運行的一個執(zhí)行者，是每個節(jié)點上的資源和任務(wù)管理器。

3.Hadoop集群如何利用Zookeeper實現(xiàn)高可用？

Hadoop集群包含HDFS能群和YARN集群。HDFS中的NameNode存在單點故障，通過

NameNode的主備為了實現(xiàn)高HDFS的高可用，NameNode的主備自動切換又利用了

Zookeeper的鎖機制。YARN中的ResourceManager也是同樣的道理。

4.Hadoop集群各角色的啟動順序？

HDFS集群啟動順序：NameNode—))DataNode—》JournalNode—》ZKFailoverController

YARN集群啟動順序：ResourceManager一》NodeManager

5.如何在Hadoop集群中動態(tài)地增加或刪除節(jié)點?

簡單的說，Hadoop集群擴容只需要新增節(jié)點納入include文件進行管理即可，Hadoop集群

縮容只需要刪除節(jié)點納入exclude文件進行管理即可。

第7章Hive數(shù)據(jù)倉庫工具

1.簡述Hive和關(guān)系型數(shù)據(jù)庫的異同？

Hive和關(guān)系型數(shù)據(jù)庫都有數(shù)據(jù)庫和表的概念，都可以使用SQL來處理數(shù)據(jù)。但是Hive中的

表是邏輯表不是物理表，數(shù)據(jù)存儲在HDFS之上，作業(yè)的運行依賴VARN集群，可以基于

Hadoop集群處理海量數(shù)據(jù)。

2.簡述Hive的運行機制？

Hive的運行機制包含以下幾個步驟：

(1)用戶通過用戶接口連接Hive,發(fā)布HQL。

(2)Hive解析查詢并制定查詢計劃。

(3)Hive將查詢轉(zhuǎn)換成MapReduce作業(yè)。

(4)Hive在Hadoop上執(zhí)行MapReduce作業(yè)。

3.簡述Hive內(nèi)部表和外部表的區(qū)別與使用？

(1)區(qū)別

刪除Hive內(nèi)部表時，表結(jié)構(gòu)和數(shù)據(jù)都會被刪除。刪除Hive外部表時，只刪除表結(jié)構(gòu)，數(shù)據(jù)

不會被刪除。

(2)使用場景

根據(jù)實際工作經(jīng)驗，一般會遵循一個經(jīng)驗法則：如果所有數(shù)據(jù)處理都由Hive來完成，

應(yīng)該選擇使用內(nèi)部表。如果同一個數(shù)據(jù)集需要由Hive和其他工具同時來處理，應(yīng)該選擇使

用外部表。一般的做法是將存放在HDFS中的初始數(shù)據(jù)集使用外部表進行處理，然后使用Hive

的轉(zhuǎn)換操作將數(shù)據(jù)移到Hive的內(nèi)部表。

4.簡述ORDERBY和SORTBY在使用上的區(qū)別和聯(lián)系？

(1)聯(lián)系

orderby和sortby都可以對數(shù)據(jù)進行排序。

(2)區(qū)別

orderby排序出來的數(shù)據(jù)是全局有序的，但是只能有一個partition

sortby排序出來的數(shù)據(jù)是局部有序的，但是全局無序。即partition內(nèi)部是有序的，但是

partition與partition之間的數(shù)據(jù)時沒有順序關(guān)系的。

5.簡述Hive性能調(diào)優(yōu)的常見手段？

FetchTask的優(yōu)化、本地模式執(zhí)行的優(yōu)化、JVM的優(yōu)化、task并行度優(yōu)化等等

第8章HBase分布式數(shù)據(jù)庫

根據(jù)下面給出的表格，用HBaseShell模式設(shè)計Score成績表，并對表進行操作。

Score成績表

score

name

ChreseMathEnglish

Lucy959086

Lily907688

Jack859278

1.查看Score表結(jié)構(gòu)。

#創(chuàng)建表

create'Score','score'

#插入數(shù)據(jù)

put'Score7Lucy7score:Chinese795'

put'Score'/Lucy'/scoreiMath'/gO'

put'Score','Lucy','scoreiEnglish'/Se'

put'Score7Lily'；score:Chinese'；90'

putScore','Lily','score:Math','76，

put'Score'/Lily'/scoreiEnglish'/SS'

put'Score'/Jack'/scoreiChinese'/SS'

put'Score','Jack7score:Math792'

put'Score'；Jack7score:English778'

#查詢表結(jié)構(gòu)

describe'Score'

2.查詢Jack同學(xué)的Chinese成績。

get'Score'JJack'/scoreiChinese'

3.將Lucy同學(xué)的English成績修改為90分。

put'Score'/Lucy'/scoreiEnglish'/OO'

第9章Hadoop生態(tài)圈其他常用開發(fā)技術(shù)

1.如何提高Sqoop導(dǎo)入導(dǎo)出的并發(fā)度?

Sqoop通過參數(shù)-m可以指定作業(yè)的并發(fā)度。

2.Flume如何保證數(shù)據(jù)不丟失？

Flume中的Event在系統(tǒng)流動過程中，通過事務(wù)的方式保證不丟失。Event在Flume節(jié)點存儲

時，可以選擇type的值為file將數(shù)據(jù)持久化磁盤確保數(shù)據(jù)不丟失。

3.Kafka的Partition為什么需要副本？

Kafka中的一個Topic可以包含多個Partition,為了防止Kafka集群節(jié)點宕機或者磁盤損壞，

Partition需要副本機制來實現(xiàn)容錯，確保在硬件故障的情況下數(shù)據(jù)不丟失。

4.簡述Kafka的優(yōu)勢？

Kafka具備高吞吐量、低延遲、持久性、可靠性、容錯性和高并發(fā)的特點和優(yōu)勢。

5.Spark和Flink編程題目

假設(shè)日志數(shù)據(jù)如下所示，格式為：網(wǎng)站ID、訪客ID、訪問時間

sitel,userl/2021-10-2002:12:22

sitel,user2,2021-10-2804:41:23

sitel/user3,2021-10-2011:46:32

sitel,user3/2021-10-2311:02:11

site2,user4,2021-10-2015:25:22

site3,user5,2021-10-2908:32:54

site3,user6,2021-10-2208:08:26

site4,user7,2021-10-2010:35:37

site4,user7,2021-10-2411:54:58

現(xiàn)在要對近7天的日志進行統(tǒng)計，統(tǒng)計結(jié)果格式如下。

Key：(Date(日期),Hour(時段)，Site(網(wǎng)站))。

Value：(PV(訪問次數(shù))，UV(獨立訪問人數(shù)，相同訪客id去重))。

分別使用Spark和Flink編寫執(zhí)行代碼，并將統(tǒng)計結(jié)果保存到HBase數(shù)據(jù)庫。

Spark示例代碼：

packagecom.bigdata

importorg.apache.spark.{SparkConf,SparkContext}

objectSparkTest{

defmain(args:Array[String]):Unit={

〃獲取SparkContext

valconf=newSparkConf().setAppName("SparkTest").setMaster("local[2]")

valsc=newSparkContext(conf)

〃讀取日志文件

valrdd=sc.textFile("G:\\learn\\data\\user.log").map(

t=>{

〃解析數(shù)據(jù)

valarray=t.split("；')

valday=array(2).split("\\s+")(0)

valhour=array(2).split("\\s+")(l).substring(0/2)

(array(O),array⑴,day,hour)

)

)

//.filter(t=>{

//〃過濾出最近7天的數(shù)據(jù)

////TimeUtils.getDiffDay(currentDayzt._3)<7

//})

〃統(tǒng)計pv訪問次數(shù)

valpvRDD=rdd.groupBy(t=>(t._3,t._4,t._l)).map(t=>(t._l/t._2.size))

print(pvRDD.collect().toBuffer)

〃插入HBase省略

〃統(tǒng)計uv獨立訪問人數(shù).先按照用戶去重，然后再聚合統(tǒng)計

valuvRDD

rdd.groupBy(t=>t).map(t=>((t.1.3,t.1.4,t.1.l)zt.2.size)).reduceByKey(+)

print(uvRDD.collect().toBuffer)

〃插入HBase省略

sc.stop();

)

)

Flink示例代碼：

packagecom.bigdata;

importmon.functions.FilterFunction;

importmon.functions.FlatMapFunction;

importmon.functions.MapFunction;

importorg.apache.flink.api.java.DataSet;

importorg.apache.flink.api.java.ExecutionEnvironment;

importorg.apache.flink.api.java.tuple.Tuple2;

importorg.apache.flink.util.Collector;

publicclassFlinkTest{

publicstaticvoidmain(String[)args)throwsException{

〃獲取ExecutionEnvironment

ExecutionEnvironmentbenv=ExecutionEnvironment.getExecutionEnvironment();

〃讀取數(shù)據(jù)

DataSet<String>ds=benv.readTextFile("G:\\learn\\data\\user.log");

〃統(tǒng)計pv訪問次數(shù)

DataSet<Tuple2<String,lnteger?pvDS=ds.map(newMapFunction<String,

Tuple2<StringJnteger?(){

(?Override

publicTuple2<String,lnteger>map(Strings)throwsException{

String[]array=s.split('7')；

Stringday=array[2].split("\\s+")[0];

Stringhour=array[2].split("\\s+")[l].substring(O,2);

,,

returnnewTuple2(day+"@"+hour+"@+array[0]/l)；

)

})

.filter(newFilterFunction<Tuple2<String,lnteger?(){

@Override

publicbooleanfilter(Tuple2<String,lnteger>t)throwsException{

//〃過濾出最近7天的數(shù)據(jù)

////TimeUtils.getDiffDay(currentDay,t._3)<7

returntrue;

)

})

.groupBy(0).surr(l);

pvDS.print();

〃插入HBase省略

System.out.println("-------------------------*');

〃統(tǒng)計uv獨立訪問人數(shù)?先按用戶去重，然后再聚合統(tǒng)計

DataSet<Tuple2<String,lnteger?uvlDS=ds.map(newMapFunction<String,

Tuple2<StringJnteger?(){

(?Override

publicTuple2<String,lnteger>map(Strings)throwsException{

String[]array=s.split("；');

Stringday=array[2].split("\\s+")[O];

Stringhour=array[2].split("\\s+")[lLsubstring(0,2);

returnnewTuple2(array[0]+"@"+array[l]+"@"+day+"@"+hour/l);

)

})

.filter(newFilterFunction<Tuple2<String,lnteger?(){

@Override

publicbooleanfilter(Tuple2<String,lnteger>t)throwsException{

//〃過濾出最近7天的數(shù)據(jù)

////TimeUtils.getDiffDay(currentDay/t._3)<7

returntrue;

)

})

.groupBy(0).surr(l);

DataSet<Tuple2<String,lnteger?uv2DS=uvlDS.flatMapfnew

FlatMapFunction<Tuple2<String,IntegersTuple2<String,lnteger?(){

@Override

publicvoidflatMap(Tuple2<Strlng,lnteger>t,Collector<Tuple2<Strlng,lnteger?

collector)throwsException{

Stringline=t.fO;

String[]array=line.split("@");

collector.collect(new

Tuple2<String,lnteger>(array[2]+"@"+array[3]+,,@,,+array[0],l))；

)

}).groupBy(0).sum(l);

uv2DS.print();

〃插入HBase省略

)

}

第9章Hadoop生態(tài)圈其他常用開發(fā)技術(shù)

1.如何提高Sqoop導(dǎo)入導(dǎo)出的并發(fā)度？

Sqoop通過參數(shù)-m可以指定作業(yè)的并發(fā)度。

2.Flume如何保證數(shù)據(jù)不丟失？

Flume中的Event在系統(tǒng)流動過程中，通過事務(wù)的方式保證不丟失。Event在Flume節(jié)點存儲

時，可以選擇type的值為file將數(shù)據(jù)持久化磁盤確保數(shù)據(jù)不丟失。

3.Kafka的Partition為什么需要副本？

Kafka中的一個Topic可以包含多個Partition,為了防止Kafka集群節(jié)點宕機或者磁盤損壞，

Partition需要副本機制來實現(xiàn)容錯，確保在硬件故障的情況下數(shù)據(jù)不丟失。

4.簡述Kafka的優(yōu)勢？

Kafka具備高吞吐量、低延遲、持久性、可靠性、容錯性和高并發(fā)的特點和優(yōu)勢。

5.Spark和Flink編程題目

假設(shè)日志數(shù)據(jù)如下所示，格式為：網(wǎng)站ID、訪客ID、訪問時間

sitel,userlz2021-10-2002:12:22

sitel,user2,2021-10-2804:41:23

sitel/user3/2021-10-2011:46:32

sitel,user3/2021-10-2311:02:11

site2,user4,2021-10-2015:25:22

site3,user5,2021-10-2908:32:54

site3,user6,2021-10-2208:08:26

site4,user7,2021-10-2010:35:37

Site4,user7,2021-10-2411:54:58

現(xiàn)在要對近7天的日志進行統(tǒng)計，統(tǒng)計結(jié)果格式如下。

Key：(Date(日期)，Hour(時段),Site(網(wǎng)站))。

Value：(PV(訪問次數(shù))，UV(獨立訪問人數(shù)，相同訪客id去重))。

分別使用Spark和Flink編寫執(zhí)行代碼，并將統(tǒng)計結(jié)果保存到HBase數(shù)據(jù)庫。

Spark示例代碼：

packagecom.bigdata

importorg.apache.spark.{SparkConf,SparkContext}

objectSparkTest{

defmain(args:Array[String]):Unit={

〃獲取SparkContext

valconf=newSparkConf().setAppName("SparkTest,,).setMaster("local[2]")

valsc=newSparkContext(conf)

〃讀取口志文件

valrdd=sc.textFile("G:\\learn\\data\\user.log").map(

t=>{

〃解析數(shù)據(jù)

valarray=t.split('7')

valday=array(2).split(',\\s+")(0)

valhour=array(2).split("\\s+")(l).substring(0z2)

(array(O),array(l),day,hour)

)

)

//.filter(t=>{

//〃過濾出最近7天的數(shù)據(jù)

////TimeUtils.getDiffDay(currentDay,t._3)<7

//})

〃統(tǒng)計pv訪問次數(shù)

valpvRDD=rdd.groupBy(t=>(t._3/t._4/t._l)).map(t=>(t._l/t._2.size))

print(pvRDD.collect().toBuffer)

〃插入HBase省略

〃統(tǒng)計uv獨立訪問人數(shù)-先按照用戶去重，然后再聚合統(tǒng)計

valuvRDD

rdd.groupBy(t=>t).map(t=>((t.1.3t1.4,t.1.l),t.2.size)).reduceByKey(+)

print(uvRDD.collect().toBuffer)

〃插入HBase省略

sc.stop();

)

}

Flink示例代碼：

packagecom.bigdata;

importmon.functlons.FllterFunction;

importmon.functions.FlatMapFunction;

importmon.functions.MapFunction;

importorg.apache.flink.api.java.DataSet;

importorg.apache.flink.api.java.ExecutionEnvironment;

importorg.apache.flink.api.java.tuple.Tuple2;

importorg.apache.flink.util.Collector;

publicclassFlinkTest{

publicstaticvoidmain(String[]args)throwsException{

〃獲取ExecutionEnvironment

ExecutionEnvironmentbenv=ExecutionEnvironment.getExecutionEnvironment();

〃讀取數(shù)據(jù)

DataSet<String>ds=benv.readTextFile("G:\\learn\\data\\user.log");

〃統(tǒng)計pv訪問次數(shù)

DataS