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ù)文件的大小進行切分，默認128M一塊，切分完成之后給NameNode發(fā)送請求第一個block塊上傳到哪些服務(wù)器上；

3. NameNode收到請求之后，根據(jù)網(wǎng)絡(luò)拓撲和機架感知以及副本機制進行文件分配，返回可用的DataNode的地址；

注：Hadoop在設(shè)計時考慮到數(shù)據(jù)的安全與高效, 數(shù)據(jù)文件默認在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ā)送給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. 當一個block傳輸完成之后, Client再次請求NameNode上傳第二個block，NameNode重新選擇三臺DataNode給Client。

HDFS讀流程：

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

2. NameNode收到請求之后會檢查用戶權(quán)限以及是否有這個文件，如果都符合，則會視情況返回部分或全部的block列表，對于每個block，NameNode都會返回含有該block副本的DataNode地址；這些返回的DataNode地址，會按照集群拓撲結(jié)構(gòu)得出DataNode與客戶端的距離，然后進行排序，排序兩個規(guī)則：網(wǎng)絡(luò)拓撲結(jié)構(gòu)中距離 Client 近的排靠前；心跳機制中超時匯報的DataNode狀態(tài)為STALE，這樣的排靠后；

3. Client選取排序靠前的DataNode來讀取block，如果客戶端本身就是DataNode,那么將從本地直接獲取數(shù)據(jù)(短路讀取特性)；

4. 底層上本質(zhì)是建立Socket Stream（FSDataInputStream），重復(fù)的調(diào)用父類DataInputStream的read方法，直到這個塊上的數(shù)據(jù)讀取完畢；

5. 當讀完列表的block后，若文件讀取還沒有結(jié)束，客戶端會繼續(xù)向NameNode 獲取下一批的block列表；

6. 讀取完一個block都會進行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é)果不一致，客戶端會通知NameNode，然后再從下一個擁有該block副本的DataNode繼續(xù)讀。

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

客戶端上傳文件時與DataNode建立pipeline管道，管道的正方向是客戶端向DataNode發(fā)送的數(shù)據(jù)包，管道反向是DataNode向客戶端發(fā)送ack確認，也就是正確接收到數(shù)據(jù)包之后發(fā)送一個已確認接收到的應(yīng)答。

當DataNode突然掛掉了，客戶端接收不到這個DataNode發(fā)送的ack確認，客戶端會通知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ā)送block report

3. 啟動DataNode：

• 向NameNode注冊

• 發(fā)送block report

• 檢查fsimage中記錄的塊的數(shù)量和block report中的塊的總數(shù)是否相同

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

• 此時內(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. Secondary NameNode了解嗎，它的工作機制是怎樣的

Secondary NameNode是合并NameNode的edit logs到fsimage文件中；

它的具體工作機制：

1. Secondary NameNode詢問NameNode是否需要checkpoint。直接帶回NameNode是否檢查結(jié)果；

2. Secondary NameNode請求執(zhí)行checkpoint；

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

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

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

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

7. 拷貝fsimage.chkpoint到NameNode；

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

所以如果NameNode中的元數(shù)據(jù)丟失，是可以從Secondary NameNode恢復(fù)一部分元數(shù)據(jù)信息的，但不是全部，因為NameNode正在寫的edits日志還沒有拷貝到Secondary NameNode，這部分恢復(fù)不了。

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

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

一個NameNode有單點故障的問題，那就配置雙NameNode，配置有兩個關(guān)鍵點，一是必須要保證這兩個NameNode的元數(shù)據(jù)信息必須要同步的，二是一個NameNode掛掉之后另一個要立馬補上。

1. 元數(shù)據(jù)信息同步在 HA 方案中采用的是“共享存儲”。每次寫文件時，需要將日志同步寫入共享存儲，這個步驟成功才能認定寫文件成功。然后備份節(jié)點定期從共享存儲同步日志，以便進行主備切換。

2. 監(jiān)控NameNode狀態(tài)采用zookeeper，兩個NameNode節(jié)點的狀態(tài)存放在zookeeper中，另外兩個NameNode節(jié)點分別有一個進程監(jiān)控程序，實施讀取zookeeper中有NameNode的狀態(tài)，來判斷當前的NameNode是不是已經(jīng)down機。如果Standby的NameNode節(jié)點的ZKFC發(fā)現(xiàn)主節(jié)點已經(jīng)掛掉，那么就會強制給原本的Active NameNode節(jié)點發(fā)送強制關(guān)閉請求，之后將備用的NameNode設(shè)置為Active。

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

可以進行解釋下：NameNode 共享存儲方案有很多，比如Linux HA, VMware FT, QJM等，目前社區(qū)已經(jīng)把由Clouderea公司實現(xiàn)的基于QJM（Quorum Journal Manager）的方案合并到HDFS的trunk之中并且作為默認的共享存儲實現(xiàn)。

基于QJM的共享存儲系統(tǒng)主要用于保存EditLog，并不保存FSImage文件。FSImage文件還是在NameNode的本地磁盤上。

QJM共享存儲的基本思想來自于Paxos算法，采用多個稱為JournalNode的節(jié)點組成的JournalNode集群來存儲EditLog。每個JournalNode保存同樣的EditLog副本。每次NameNode寫EditLog的時候，除了向本地磁盤寫入 EditLog 之外，也會并行地向JournalNode集群之中的每一個JournalNode發(fā)送寫請求，只要大多數(shù)的JournalNode節(jié)點返回成功就認為向JournalNode集群寫入EditLog成功。如果有2N+1臺JournalNode，那么根據(jù)大多數(shù)的原則，最多可以容忍有N臺JournalNode節(jié)點掛掉。

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

腦裂：假設(shè) NameNode1 當前為 Active 狀態(tài)，NameNode2 當前為 Standby 狀態(tài)。如果某一時刻 NameNode1 對應(yīng)的 ZKFailoverController 進程發(fā)生了“假死”現(xiàn)象，那么 Zookeeper 服務(wù)端會認為 NameNode1 掛掉了，根據(jù)前面的主備切換邏輯，NameNode2 會替代 NameNode1 進入 Active 狀態(tài)。但是此時 NameNode1 可能仍然處于 Active 狀態(tài)正常運行，這樣 NameNode1 和 NameNode2 都處于 Active 狀態(tài)，都可以對外提供服務(wù)。這種情況稱為腦裂。

腦裂對于NameNode這類對數(shù)據(jù)一致性要求非常高的系統(tǒng)來說是災(zāi)難性的，數(shù)據(jù)會發(fā)生錯亂且無法恢復(fù)。zookeeper社區(qū)對這種問題的解決方法叫做 fencing，中文翻譯為隔離，也就是想辦法把舊的 Active NameNode 隔離起來，使它不能正常對外提供服務(wù)。

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

1. 首先嘗試調(diào)用這個舊 Active NameNode 的 HAServiceProtocol RPC 接口的 transitionToStandby 方法，看能不能把它轉(zhuǎn)換為 Standby 狀態(tài)。

2. 如果 transitionToStandby 方法調(diào)用失敗，那么就執(zhí)行 Hadoop 配置文件之中預(yù)定義的隔離措施，Hadoop 目前主要提供兩種隔離措施，通常會選擇 sshfence：

• sshfence：通過 SSH 登錄到目標機器上，執(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ù)

• 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下達命令，DataNode執(zhí)行實際的操作

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

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

4. Secondary NameNode：并非NameNode的熱備。當NameNode掛掉的時候，它并不能馬上替換NameNode并提供服務(wù)

• 輔助NameNode，分擔其工作量

• 定期合并Fsimage和Edits，并推送給NameNode

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

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

簡單概述：

inputFile通過split被切割為多個split文件，通過Record按行讀取內(nèi)容給map（自己寫的處理邏輯的方法） ，數(shù)據(jù)被map處理完之后交給OutputCollect收集器，對其結(jié)果key進行分區(qū)（默認使用的hashPartitioner），然后寫入buffer，每個map task 都有一個內(nèi)存緩沖區(qū)（環(huán)形緩沖區(qū)），存放著map的輸出結(jié)果，當緩沖區(qū)快滿的時候需要將緩沖區(qū)的數(shù)據(jù)以一個臨時文件的方式溢寫到磁盤，當整個map task 結(jié)束后再對磁盤中這個maptask產(chǎn)生的所有臨時文件做合并，生成最終的正式輸出文件，然后等待reduce task的拉取。

詳細步驟：

1. 讀取數(shù)據(jù)組件 InputFormat (默認 TextInputFormat) 會通過 getSplits 方法對輸入目錄中的文件進行邏輯切片規(guī)劃得到 block，有多少個 block就對應(yīng)啟動多少個 MapTask。

2. 將輸入文件切分為 block 之后，由 RecordReader 對象 (默認是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ū)處理，默認使用 HashPartitioner。

5. 接下來，會將數(shù)據(jù)寫入內(nèi)存，內(nèi)存中這片區(qū)域叫做環(huán)形緩沖區(qū)(默認100M)，緩沖區(qū)的作用是 批量收集 Mapper 結(jié)果，減少磁盤 IO 的影響。我們的 Key/Value 對以及 Partition 的結(jié)果都會被寫入緩沖區(qū)。當然，寫入之前，Key 與 Value 值都會被序列化成字節(jié)數(shù)組。

6. 當環(huán)形緩沖區(qū)的數(shù)據(jù)達到溢寫比列(默認0.8)，也就是80M時，溢寫線程啟動，需要對這 80MB 空間內(nèi)的 Key 做排序 (Sort)。排序是 MapReduce 模型默認的行為，這里的排序也是對序列化的字節(jié)做的排序。

7. 合并溢寫文件，每次溢寫會在磁盤上生成一個臨時文件 (寫之前判斷是否有 Combiner)，如果 Mapper 的輸出結(jié)果真的很大，有多次這樣的溢寫發(fā)生，磁盤上相應(yīng)的就會有多個臨時文件存在。當整個數(shù)據(jù)處理結(jié)束之后開始對磁盤中的臨時文件進行 Merge 合并，因為最終的文件只有一個寫入磁盤，并且為這個文件提供了一個索引文件，以記錄每個reduce對應(yīng)數(shù)據(jù)的偏移量。

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

簡單描述：

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

copy 階段包含一個 eventFetcher 來獲取已完成的 map 列表，由 Fetcher 線程去 copy 數(shù)據(jù)，在此過程中會啟動兩個 merge 線程，分別為 inMemoryMerger 和 onDiskMerger，分別將內(nèi)存中的數(shù)據(jù) merge 到磁盤和將磁盤中的數(shù)據(jù)進行 merge。待數(shù)據(jù) copy 完成之后，copy 階段就完成了。

開始進行 sort 階段，sort 階段主要是執(zhí)行 finalMerge 操作，純粹的 sort 階段，完成之后就是 reduce 階段，調(diào)用用戶定義的 reduce 函數(shù)進行處理。

詳細步驟：

1. Copy階段：簡單地拉取數(shù)據(jù)。Reduce進程啟動一些數(shù)據(jù)copy線程(Fetcher)，通過HTTP方式請求maptask獲取屬于自己的文件（map task 的分區(qū)會標識每個map task屬于哪個reduce task ，默認reduce task的標識從0開始）。

2. Merge階段：在遠程拷貝數(shù)據(jù)的同時，ReduceTask啟動了兩個后臺線程對內(nèi)存和磁盤上的文件進行合并，以防止內(nèi)存使用過多或磁盤上文件過多。

   merge有三種形式：內(nèi)存到內(nèi)存；內(nèi)存到磁盤；磁盤到磁盤。默認情況下第一種形式不啟用。當內(nèi)存中的數(shù)據(jù)量到達一定閾值，就直接啟動內(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ù)作為輸入之前的過程稱作 shuffle。

1. Collect階段：將 MapTask 的結(jié)果輸出到默認大小為 100M 的環(huán)形緩沖區(qū)，保存的是 key/value，Partition 分區(qū)信息等。

2. Spill階段：當內(nèi)存中的數(shù)據(jù)量達到一定的閥值的時候，就會將數(shù)據(jù)寫入本地磁盤，在將數(shù)據(jù)寫入磁盤之前需要對數(shù)據(jù)進行一次排序的操作，如果配置了 combiner，還會將有相同分區(qū)號和 key 的數(shù)據(jù)進行排序。

3. MapTask階段的Merge：把所有溢出的臨時文件進行一次合并操作，以確保一個 MapTask 最終只產(chǎn)生一個中間數(shù)據(jù)文件。

4. Copy階段：ReduceTask 啟動 Fetcher 線程到已經(jīng)完成 MapTask 的節(jié)點上復(fù)制一份屬于自己的數(shù)據(jù)，這些數(shù)據(jù)默認會保存在內(nèi)存的緩沖區(qū)中，當內(nèi)存的緩沖區(qū)達到一定的閥值的時候，就會將數(shù)據(jù)寫到磁盤之上。

5. ReduceTask階段的Merge：在 ReduceTask 遠程復(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  默認100M

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

在shuffle階段，可以看到數(shù)據(jù)通過大量的拷貝，從map階段輸出的數(shù)據(jù)，都要通過網(wǎng)絡(luò)拷貝，發(fā)送到reduce階段，這一過程中，涉及到大量的網(wǎng)絡(luò)IO，如果數(shù)據(jù)能夠進行壓縮，那么數(shù)據(jù)的發(fā)送量就會少得多。

hadoop當中支持的壓縮算法：
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è)計思想是將MapReduce V1中的JobTracker拆分為兩個獨立的服務(wù)：ResourceManager和ApplicationMaster。

ResourceManager負責(zé)整個系統(tǒng)的資源管理和分配，ApplicationMaster負責(zé)單個應(yīng)用程序的的管理。

1. ResourceManager：RM是一個全局的資源管理器，負責(zé)整個系統(tǒng)的資源管理和分配，它主要由兩個部分組成：調(diào)度器（Scheduler）和應(yīng)用程序管理器（Application Manager）。

調(diào)度器根據(jù)容量、隊列等限制條件，將系統(tǒng)中的資源分配給正在運行的應(yīng)用程序，在保證容量、公平性和服務(wù)等級的前提下，優(yōu)化集群資源利用率，讓所有的資源都被充分利用應(yīng)用程序管理器負責(zé)管理整個系統(tǒng)中的所有的應(yīng)用程序，包括應(yīng)用程序的提交、與調(diào)度器協(xié)商資源以啟動ApplicationMaster、監(jiān)控ApplicationMaster運行狀態(tài)并在失敗時重啟它。

2. ApplicationMaster：用戶提交的一個應(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中描述的資源。不同于MapReduceV1中槽位slot的資源封裝，Container是一個動態(tài)資源的劃分單位，更能充分利用資源。

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

當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。

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)和進度，以便當任務(wù)失敗時可以重啟任務(wù)。

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

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

在Yarn中有三種調(diào)度器可以選擇：FIFO Scheduler ，Capacity Scheduler，F(xiàn)air Scheduler。

Apache版本的hadoop默認使用的是Capacity  Scheduler調(diào)度方式。CDH版本的默認使用的是Fair Scheduler調(diào)度方式

FIFO Scheduler（先來先服務(wù)）：

FIFO Scheduler把應(yīng)用按提交的順序排成一個隊列，這是一個先進先出隊列，在進行資源分配的時候，先給隊列中最頭上的應(yīng)用進行分配資源，待最頭上的應(yīng)用需求滿足后再給下一個分配，以此類推。

FIFO Scheduler是最簡單也是最容易理解的調(diào)度器，也不需要任何配置，但它并不適用于共享集群。大的應(yīng)用可能會占用所有集群資源，這就導(dǎo)致其它應(yīng)用被阻塞，比如有個大任務(wù)在執(zhí)行，占用了全部的資源，再提交一個小任務(wù)，則此小任務(wù)會一直被阻塞。

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

對于Capacity調(diào)度器，有一個專門的隊列用來運行小任務(wù)，但是為小任務(wù)專門設(shè)置一個隊列會預(yù)先占用一定的集群資源，這就導(dǎo)致大任務(wù)的執(zhí)行時間會落后于使用FIFO調(diào)度器時的時間。

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

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

比如：當?shù)谝粋€大job提交時，只有這一個job在運行，此時它獲得了所有集群資源；當?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ù)及時完成。

--end--

掃描下方二維碼
添加好友，備注【交流】
可私聊交流，也可進資源豐富學(xué)習(xí)群

更文不易，點個“在看”支持一下??