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

客戶端讀取完DataNode上的塊之后會(huì)進(jìn)行checksum驗(yàn)證，也就是把客戶端讀取到本地的塊與HDFS上的原始?jí)K進(jìn)行校驗(yàn)缤弦，如果發(fā)現(xiàn)校驗(yàn)結(jié)果不一致茄蚯，客戶端會(huì)通知NameNode镜硕，然后再從下一個(gè)擁有該block副本的DataNode繼續(xù)讀茂浮。

2. 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作下線處理住练，不再讓它參與文件上傳與下載。

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

NameNode數(shù)據(jù)存儲(chǔ)在內(nèi)存和本地磁盤愁拭，本地磁盤數(shù)據(jù)存儲(chǔ)在fsimage鏡像文件和edits編輯日志文件。

首次啟動(dòng)NameNode：

格式化文件系統(tǒng)亏吝，為了生成fsimage鏡像文件岭埠；
啟動(dòng)NameNode：
讀取fsimage文件，將文件內(nèi)容加載進(jìn)內(nèi)存
等待DataNade注冊(cè)與發(fā)送block report
啟動(dòng)DataNode：
向NameNode注冊(cè)
發(fā)送block report
檢查fsimage中記錄的塊的數(shù)量和block report中的塊的總數(shù)是否相同
對(duì)文件系統(tǒng)進(jìn)行操作（創(chuàng)建目錄蔚鸥，上傳文件惜论，刪除文件等）：
此時(shí)內(nèi)存中已經(jīng)有文件系統(tǒng)改變的信息，但是磁盤中沒有文件系統(tǒng)改變的信息止喷，此時(shí)會(huì)將這些改變信息寫入edits文件中馆类，edits文件中存儲(chǔ)的是文件系統(tǒng)元數(shù)據(jù)改變的信息。

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

讀取fsimage和edits文件弹谁；
將fsimage和edits文件合并成新的fsimage文件乾巧；
創(chuàng)建新的edits文件，內(nèi)容開始為空预愤；
啟動(dòng)DataNode沟于。

4. Secondary NameNode了解嗎，它的工作機(jī)制是怎樣的

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

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

Secondary NameNode詢問NameNode是否需要checkpoint旷太。直接帶回NameNode是否檢查結(jié)果；
Secondary NameNode請(qǐng)求執(zhí)行checkpoint销睁；
NameNode滾動(dòng)正在寫的edits日志供璧；
將滾動(dòng)前的編輯日志和鏡像文件拷貝到Secondary NameNode；
Secondary NameNode加載編輯日志和鏡像文件到內(nèi)存冻记，并合并睡毒；
生成新的鏡像文件fsimage.chkpoint；
拷貝fsimage.chkpoint到NameNode檩赢；
NameNode將fsimage.chkpoint重新命名成fsimage吕嘀；
所以如果NameNode中的元數(shù)據(jù)丟失违寞，是可以從Secondary NameNode恢復(fù)一部分元數(shù)據(jù)信息的，但不是全部偶房，因?yàn)镹ameNode正在寫的edits日志還沒有拷貝到Secondary NameNode趁曼，這部分恢復(fù)不了。

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

這個(gè)問題就要說NameNode的高可用了挡闰，即 NameNode HA。

一個(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è)置為Active壶愤。

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

可以進(jìn)行解釋下：
NameNode 共享存儲(chǔ)方案有很多，比如Linux HA, VMware FT, QJM等征椒，目前社區(qū)已經(jīng)把由Clouderea公司實(shí)現(xiàn)的基于QJM（Quorum Journal Manager）的方案合并到HDFS的trunk之中并且作為默認(rèn)的共享存儲(chǔ)實(shí)現(xiàn)娇哆。
基于QJM的共享存儲(chǔ)系統(tǒng)主要用于保存EditLog，并不保存FSImage文件勃救。FSImage文件還是在NameNode的本地磁盤上碍讨。
QJM共享存儲(chǔ)的基本思想來自于Paxos算法，采用多個(gè)稱為JournalNode的節(jié)點(diǎn)組成的JournalNode集群來存儲(chǔ)EditLog蒙秒。每個(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. 在NameNode HA中，會(huì)出現(xiàn)腦裂問題嗎摹量？怎么解決腦裂

假設(shè) NameNode1 當(dāng)前為 Active 狀態(tài)涤伐，NameNode2 當(dāng)前為 Standby 狀態(tài)。如果某一時(shí)刻 NameNode1 對(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ù)当凡。這種情況稱為腦裂掌动。

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

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

首先嘗試調(diào)用這個(gè)舊 Active NameNode 的 HAServiceProtocol RPC 接口的 transitionToStandby 方法佛掖，看能不能把它轉(zhuǎn)換為 Standby 狀態(tài)。
如果 transitionToStandby 方法調(diào)用失敗涌庭，那么就執(zhí)行 Hadoop 配置文件之中預(yù)定義的隔離措施芥被，Hadoop 目前主要提供兩種隔離措施，通常會(huì)選擇 sshfence：
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的CombineFileInputFormat<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)遇骑。NameNode下達(dá)命令，DataNode執(zhí)行實(shí)際的操作
* 存儲(chǔ)實(shí)際的數(shù)據(jù)塊
* 執(zhí)行數(shù)據(jù)塊的讀/寫操作

Secondary NameNode：并非NameNode的熱備揖曾。當(dāng)NameNode掛掉的時(shí)候落萎，它并不能馬上替換NameNode并提供服務(wù)
* 輔助NameNode，分擔(dān)其工作量
* 定期合并Fsimage和Edits炭剪，并推送給NameNode
* 在緊急情況下练链，可輔助恢復(fù)NameNode

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

簡單概述：

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

詳細(xì)步驟：

讀取數(shù)據(jù)組件 InputFormat (默認(rèn) TextInputFormat) 會(huì)通過 getSplits 方法對(duì)輸入目錄中的文件進(jìn)行邏輯切片規(guī)劃得到 block擎厢，有多少個(gè) block就對(duì)應(yīng)啟動(dòng)多少個(gè) MapTask。
將輸入文件切分為 block 之后晾剖，由 RecordReader 對(duì)象 (默認(rèn)是LineRecordReader) 進(jìn)行讀取锉矢，以 \n 作為分隔符, 讀取一行數(shù)據(jù), 返回 <key，value>齿尽， Key 表示每行首字符偏移值沽损，Value 表示這一行文本內(nèi)容。
讀取 block 返回 <key,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)使用 HashPartitioner缝左。
接下來亿遂，會(huì)將數(shù)據(jù)寫入內(nèi)存，內(nèi)存中這片區(qū)域叫做環(huán)形緩沖區(qū)(默認(rèn)100M)渺杉，緩沖區(qū)的作用是 批量收集 Mapper 結(jié)果蛇数，減少磁盤 IO 的影響。我們的 Key/Value 對(duì)以及 Partition 的結(jié)果都會(huì)被寫入緩沖區(qū)是越。當(dāng)然耳舅，寫入之前，Key 與 Value 值都會(huì)被序列化成字節(jié)數(shù)組倚评。
當(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é)做的排序目锭。
合并溢寫文件昏滴，每次溢寫會(huì)在磁盤上生成一個(gè)臨時(shí)文件 (寫之前判斷是否有 Combiner)昼窗，如果 Mapper 的輸出結(jié)果真的很大，有多次這樣的溢寫發(fā)生敷燎，磁盤上相應(yīng)的就會(huì)有多個(gè)臨時(shí)文件存在。當(dāng)整個(gè)數(shù)據(jù)處理結(jié)束之后開始對(duì)磁盤中的臨時(shí)文件進(jìn)行 Merge 合并箩言，因?yàn)樽罱K的文件只有一個(gè)寫入磁盤硬贯，并且為這個(gè)文件提供了一個(gè)索引文件，以記錄每個(gè)reduce對(duì)應(yīng)數(shù)據(jù)的偏移量陨收。

11. 請(qǐng)說下MR中Reduce Task的工作機(jī)制

簡單描述：

Reduce 大致分為 copy饭豹、sort、reduce 三個(gè)階段务漩，重點(diǎn)在前兩個(gè)階段拄衰。

copy 階段包含一個(gè) eventFetcher 來獲取已完成的 map 列表，由 Fetcher 線程去 copy 數(shù)據(jù)饵骨，在此過程中會(huì)啟動(dòng)兩個(gè) merge 線程翘悉，分別為 inMemoryMerger 和 onDiskMerger，分別將內(nèi)存中的數(shù)據(jù) merge 到磁盤和將磁盤中的數(shù)據(jù)進(jìn)行 merge居触。待數(shù)據(jù) copy 完成之后妖混，copy 階段就完成了老赤。

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

詳細(xì)步驟：

Copy階段：簡單地拉取數(shù)據(jù)开财。Reduce進(jìn)程啟動(dòng)一些數(shù)據(jù)copy線程(Fetcher)，通過HTTP方式請(qǐng)求maptask獲取屬于自己的文件（map task 的分區(qū)會(huì)標(biāo)識(shí)每個(gè)map task屬于哪個(gè)reduce task 误褪，默認(rèn)reduce task的標(biāo)識(shí)從0開始）责鳍。
Merge階段：在遠(yuǎn)程拷貝數(shù)據(jù)的同時(shí)，ReduceTask啟動(dòng)了兩個(gè)后臺(tái)線程對(duì)內(nèi)存和磁盤上的文件進(jìn)行合并振坚，以防止內(nèi)存使用過多或磁盤上文件過多薇搁。merge有三種形式：內(nèi)存到內(nèi)存；內(nèi)存到磁盤渡八；磁盤到磁盤啃洋。默認(rèn)情況下第一種形式不啟用。當(dāng)內(nèi)存中的數(shù)據(jù)量到達(dá)一定閾值屎鳍，就直接啟動(dòng)內(nèi)存到磁盤的merge宏娄。與map端類似，這也是溢寫的過程逮壁，這個(gè)過程中如果你設(shè)置有Combiner孵坚，也是會(huì)啟用的，然后在磁盤中生成了眾多的溢寫文件窥淆。內(nèi)存到磁盤的merge方式一直在運(yùn)行卖宠，直到?jīng)]有map端的數(shù)據(jù)時(shí)才結(jié)束，然后啟動(dòng)第三種磁盤到磁盤的merge方式生成最終的文件忧饭。
合并排序：把分散的數(shù)據(jù)合并成一個(gè)大的數(shù)據(jù)后扛伍，還會(huì)再對(duì)合并后的數(shù)據(jù)排序。
對(duì)排序后的鍵值對(duì)調(diào)用reduce方法：鍵相等的鍵值對(duì)調(diào)用一次reduce方法词裤，每次調(diào)用會(huì)產(chǎn)生零個(gè)或者多個(gè)鍵值對(duì)刺洒，最后把這些輸出的鍵值對(duì)寫入到HDFS文件中。

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

shuffle階段分為四個(gè)步驟：依次為：分區(qū)吼砂，排序逆航，規(guī)約，分組渔肩，其中前三個(gè)步驟在map階段完成因俐，最后一個(gè)步驟在reduce階段完成。

shuffle 是 Mapreduce 的核心，它分布在 Mapreduce 的 map 階段和 reduce 階段女揭。一般把從 Map 產(chǎn)生輸出開始到 Reduce 取得數(shù)據(jù)作為輸入之前的過程稱作 shuffle蚤假。

• 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)行一次合并操作逢享，以確保一個(gè) MapTask 最終只產(chǎn)生一個(gè)中間數(shù)據(jù)文件。
• 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)開啟兩個(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í)行效率柏锄，原則上說，緩沖區(qū)越大复亏，磁盤io的次數(shù)越少趾娃，執(zhí)行速度就越快。
緩沖區(qū)的大小可以通過參數(shù)調(diào)整, 參數(shù)：mapreduce.task.io.sort.mb 默認(rèn)100M

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

在shuffle階段缔御，可以看到數(shù)據(jù)通過大量的拷貝茫舶，從map階段輸出的數(shù)據(jù)，都要通過網(wǎng)絡(luò)拷貝刹淌，發(fā)送到reduce階段，這一過程中讥耗，涉及到大量的網(wǎng)絡(luò)IO有勾，如果數(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ì)思想是將MapReduce V1中的JobTracker拆分為兩個(gè)獨(dú)立的服務(wù)：ResourceManager和ApplicationMaster。

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

ResourceManager： RM是一個(gè)全局的資源管理器，負(fù)責(zé)整個(gè)系統(tǒng)的資源管理和分配扭倾，它主要由兩個(gè)部分組成：調(diào)度器（Scheduler）和應(yīng)用程序管理器（Application Manager）淀零。
調(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í)重啟它。

ApplicationMaster： 用戶提交的一個(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ù)罢维。
NodeManager： NodeManager是每個(gè)節(jié)點(diǎn)上的資源和任務(wù)管理器淹仑，一方面，它會(huì)定期地向RM匯報(bào)本節(jié)點(diǎn)上的資源使用情況和各個(gè)Container的運(yùn)行狀態(tài)；另一方面匀借，他接收并處理來自AM的Container啟動(dòng)和停止請(qǐng)求颜阐。
Container： Container是YARN中的資源抽象，封裝了各種資源吓肋。一個(gè)應(yīng)用程序會(huì)分配一個(gè)Container凳怨，這個(gè)應(yīng)用程序只能使用這個(gè)Container中描述的資源。不同于MapReduceV1中槽位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é)束兆龙。 具體步驟如下:

用戶向YARN提交一個(gè)應(yīng)用程序杖爽，并指定ApplicationMaster程序、啟動(dòng)ApplicationMaster的命令紫皇、用戶程序慰安。
RM為這個(gè)應(yīng)用程序分配第一個(gè)Container，并與之對(duì)應(yīng)的NM通訊聪铺，要求它在這個(gè)Container中啟動(dòng)應(yīng)用程序ApplicationMaster化焕。
ApplicationMaster向RM注冊(cè)，然后拆分為內(nèi)部各個(gè)子任務(wù)铃剔，為各個(gè)內(nèi)部任務(wù)申請(qǐng)資源撒桨，并監(jiān)控這些任務(wù)的運(yùn)行，直到結(jié)束键兜。
AM采用輪詢的方式向RM申請(qǐng)和領(lǐng)取資源凤类。
RM為AM分配資源，以Container形式返回普气。
AM申請(qǐng)到資源后谜疤，便與之對(duì)應(yīng)的NM通訊，要求NM啟動(dòng)任務(wù)现诀。
NodeManager為任務(wù)設(shè)置好運(yùn)行環(huán)境夷磕，將任務(wù)啟動(dòng)命令寫到一個(gè)腳本中，并通過運(yùn)行這個(gè)腳本啟動(dòng)任務(wù)仔沿。
各個(gè)任務(wù)向AM匯報(bào)自己的狀態(tài)和進(jìn)度坐桩，以便當(dāng)任務(wù)失敗時(shí)可以重啟任務(wù)。
應(yīng)用程序完成后于未，ApplicationMaster向ResourceManager注銷并關(guān)閉自己。

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

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

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

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

FIFO Scheduler把應(yīng)用按提交的順序排成一個(gè)隊(duì)列闷叉，這是一個(gè)先進(jìn)先出隊(duì)列擦俐，在進(jìn)行資源分配的時(shí)候，先給隊(duì)列中最頭上的應(yīng)用進(jìn)行分配資源握侧，待最頭上的應(yīng)用需求滿足后再給下一個(gè)分配蚯瞧，以此類推。

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

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

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

Fair Scheduler（公平調(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)資源洪规。

比如：當(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í)完成很钓。