柚子快報激活碼778899分享：大數(shù)據(jù) Hadoop學(xué)習(xí)總結(jié)

http://yzkb.51969.com/

HDFS YARN MapReduce關(guān)系

HDFS （分布式文件系統(tǒng)）

優(yōu)缺點(diǎn)

優(yōu)點(diǎn)

1. 高容錯性：副本丟失，可以自動回復(fù)。

2. 適合處理大數(shù)據(jù)

3. 可以構(gòu)建在廉價的機(jī)器上，通過對多副本機(jī)制，提高可靠性

缺點(diǎn)

1. 不適合低延時數(shù)據(jù)訪問，比如毫秒級的存儲數(shù)據(jù)，做不到

2. 無法高效的對大量小文件進(jìn)行存儲： 存儲大量小文件，會占用NameNode大量的內(nèi)存來存儲文件目錄和塊信息。NameNode內(nèi)存有限。小文件存儲的尋址時間會超過讀取時間。

3. 不支持并發(fā)寫入，文件隨機(jī)修改。

a. 一個文件只能由一個寫，不允許多個線程同時寫。

b. 僅支持?jǐn)?shù)據(jù)append，不支持文件的隨機(jī)修改。

組成

NameNode(nn)

存儲文件的元數(shù)據(jù)，如文件名，文件目錄結(jié)構(gòu)，文件屬性（生成時間 ，副本數(shù)，文件權(quán)限），以及每個文件的塊列表和塊所在的DataNode等。

1. Fsimage文件：HDFS文件系統(tǒng)元數(shù)據(jù)的一個永久性檢查點(diǎn)，其中包含了HDFS文件系統(tǒng)的所有目錄和文件inode的序列化信息。

2. Edits文件：存放HDFS文件系統(tǒng)的所有更新操作的路徑，文件系統(tǒng)客戶端執(zhí)行的所有寫操作首先會被記錄到此。

3. seen_txid文件保存了一個數(shù)字，就是最后一個edits_的數(shù)字。最新的edits文件。

DataNode(dn)

在本地文件系統(tǒng)存儲文件塊數(shù)據(jù)，以及塊數(shù)據(jù)的校驗(yàn)和。

工作機(jī)制

DataNode數(shù)據(jù)的完整性

1. 當(dāng)DataNode讀取Block時候，會計(jì)算CheckSum.

2. 如果計(jì)算后的CheckSum和Block創(chuàng)建的時候值不一樣，說明Block已經(jīng)損壞。

3. Client回去讀取其他DataNode上的Block

4. 常見的校驗(yàn)算法：crc(32) ,md5(128),shal(160)

5. DataNode在其文件創(chuàng)建后周期性驗(yàn)證CheckSum.

Secondary NameNode(2nn)

每隔一段時間對NameNode元數(shù)據(jù)備份

工作流程

引入2NN的原因

1. NameNode中的元數(shù)據(jù)需要放到內(nèi)存中，這樣效率高，但是斷電后，元數(shù)據(jù)丟失。因此產(chǎn)生在磁盤中備份元數(shù)據(jù)的FsImage。

2. 引入Edits文件（只進(jìn)行追加操作，效率很高）。每當(dāng)元數(shù)據(jù)有更新或者添加元數(shù)據(jù)時，修改內(nèi)存中的元數(shù)據(jù)并追加到Edits中。

3. 長時間添加數(shù)據(jù)到Edits中，會導(dǎo)致該文件數(shù)據(jù)過大，效率降低，而且一旦斷電，恢復(fù)元數(shù)據(jù)需要的時間過長。因此需要定期進(jìn)行FsImage和Edits的合并，如果這個操作由NameNode節(jié)點(diǎn)完成，又會效率過低。因此，引入一個新的節(jié)點(diǎn)SecondaryNamenode，專門用于FsImage和Edits的合并。

其中edits_oo1是拉取之前的操作edits_inprogress_002是拉取之后進(jìn)行的操作，因此從2NN更新完以后到NN上的數(shù)據(jù)結(jié)合002是最新的數(shù)據(jù)

讀流程

（1）客戶端通過DistributedFileSystem向NameNode請求下載文件，NameNode通過查詢元數(shù)據(jù)，找到文件塊所在的DataNode地址。

（2）挑選一臺DataNode（就近原則，然后隨機(jī)）服務(wù)器，請求讀取數(shù)據(jù)。

（3）DataNode開始傳輸數(shù)據(jù)給客戶端（從磁盤里面讀取數(shù)據(jù)輸入流，以Packet為單位來做校驗(yàn)）。

（4）客戶端以Packet為單位接收，先在本地緩存，然后寫入目標(biāo)文件。

寫流程

（1）客戶端通過Distributed FileSystem模塊向NameNode請求上傳文件，NameNode檢查目標(biāo)文件是否已存在，父目錄是否存在。

（2）NameNode返回是否可以上傳。

（3）客戶端請求第一個 Block上傳到哪幾個DataNode服務(wù)器上。

（4）NameNode返回3個DataNode節(jié)點(diǎn)，分別為dn1、dn2、dn3。

（5）客戶端通過FSDataOutputStream模塊請求dn1上傳數(shù)據(jù)，dn1收到請求會繼續(xù)調(diào)用dn2，然后dn2調(diào)用dn3，將這個通信管道建立完成。

（6）dn1、dn2、dn3逐級應(yīng)答客戶端。

（7）客戶端開始往dn1上傳第一個Block（先從磁盤讀取數(shù)據(jù)放到一個本地內(nèi)存緩存），以Packet為單位，dn1收到一個Packet就會傳給dn2，dn2傳給dn3；dn1每傳一個packet會放入一個應(yīng)答隊(duì)列等待應(yīng)答。

（8）當(dāng)一個Block傳輸完成之后，客戶端再次請求NameNode上傳第二個Block的服務(wù)器。（重復(fù)執(zhí)行3-7步）

YARN（資源調(diào)度器）

組成

1. ResourceManager(RM) 主要作用(整個集群資源（cpu,內(nèi)存）老大)

a. 處理客戶端請求

b.監(jiān)控NodeManager

c.啟動或監(jiān)控ApplicationMaster

d.資源的分配和調(diào)度

2. NodeManager（NM)主要作用（單個節(jié)點(diǎn)服務(wù)器資源的老大）

a. 管理單個節(jié)點(diǎn)上的資源

b.處理來自ResourceManager的命令

c.處理來自ApplicationMaster的命令

3. ApplicationMaster（AM) 作用（單個任務(wù)運(yùn)行的老大）

a. 為應(yīng)用程序申請資源并分配給內(nèi)部的任務(wù)

b. 任務(wù)的監(jiān)控與容錯

4. Container（相當(dāng)于一臺獨(dú)立的服務(wù)器）

YARN中的資源抽象，封裝了某個節(jié)點(diǎn)上的多維度資源，如內(nèi)存，CPU，磁盤，網(wǎng)絡(luò)等。

工作機(jī)制

（1）MR程序提交到客戶端所在的節(jié)點(diǎn)。

（2）YarnRunner向ResourceManager申請一個Application。

（3）RM將該應(yīng)用程序的資源路徑返回給YarnRunner。

（4）該程序?qū)⑦\(yùn)行所需資源提交到HDFS上。

（5）程序資源提交完畢后，申請運(yùn)行mrAppMaster。

（6）RM將用戶的請求初始化成一個Task。

（7）其中一個NodeManager領(lǐng)取到Task任務(wù)。

（8）該NodeManager創(chuàng)建容器Container，并產(chǎn)生MRAppmaster。

（9）Container從HDFS上拷貝資源到本地。

（10）MRAppmaster向RM 申請運(yùn)行MapTask資源。

（11）RM將運(yùn)行MapTask任務(wù)分配給另外兩個NodeManager，另兩個NodeManager分別領(lǐng)取任務(wù)并創(chuàng)建容器。

（12）MR向兩個接收到任務(wù)的NodeManager發(fā)送程序啟動腳本，這兩個NodeManager分別啟動MapTask，MapTask對數(shù)據(jù)分區(qū)排序。

（13）MrAppMaster等待所有MapTask運(yùn)行完畢后，向RM申請容器，運(yùn)行ReduceTask。

（14）ReduceTask向MapTask獲取相應(yīng)分區(qū)的數(shù)據(jù)。

（15）程序運(yùn)行完畢后，MR會向RM申請注銷自己。

三種調(diào)度器的

先進(jìn)先出調(diào)度器（FIFO）

單隊(duì)列，根據(jù)提交作業(yè)的先后順序，先來先服務(wù)。

容量調(diào)度器（Apache hadoop 默認(rèn)）

特點(diǎn)

1. 多隊(duì)列：每個隊(duì)列可以配置一定的資源量，每個隊(duì)列采用FIFO調(diào)度策略。

2. 容量保證：管理員可為每個隊(duì)列設(shè)置資源最低保證和資源使用上限。

3. 靈活性：如果一個隊(duì)列中資源有剩余，可以暫時共享給需要資源的隊(duì)列，一旦該隊(duì)列由新的應(yīng)用提交，則其他隊(duì)列要?dú)w還。

4. 多租戶：

支持多用戶共享集群（如上圖的SS和CLS用戶）和多應(yīng)用程序同時運(yùn)行。

對同一用戶提交的作業(yè)所占資源量進(jìn)行限定。

容量分配算法

1. 隊(duì)列資源分配

從root開始，使用深度優(yōu)先算法，優(yōu)先選擇資源占用率最低的隊(duì)列分配資源。

2. 作業(yè)資源分配

默認(rèn)按照提交作業(yè)的優(yōu)先級和提交時間順序分配資源

3. 容器資源分配

按照容器的優(yōu)先級分配資源，如果優(yōu)先級相同，按照數(shù)據(jù)本地行原則：

a.任務(wù)和數(shù)據(jù)在同一節(jié)點(diǎn)上

b.任務(wù)和數(shù)據(jù)在同一機(jī)架上

c.任務(wù)和數(shù)據(jù)不再同一節(jié)點(diǎn)也不在同一機(jī)架上

公平調(diào)度器（CDH默認(rèn)）

特點(diǎn)

同容量調(diào)度器一樣。

與容量調(diào)度器的不同點(diǎn)

1. 核心調(diào)度策略不同

容量：優(yōu)先選擇資源利用率低的隊(duì)列

公平：優(yōu)先選擇對資源的缺額比例大的

2. 每個隊(duì)列可以單獨(dú)設(shè)置資源分配方式

缺額

1. 公平調(diào)度器設(shè)計(jì)的目標(biāo)是：在時間尺度上，所有作業(yè)獲得公平的資源。某一時刻的一個作業(yè)應(yīng)獲取資源和實(shí)際獲取資源的差距叫缺額。

2. 調(diào)度器會優(yōu)先為缺額大的作業(yè)分配資源

隊(duì)列資源分配方式

Fair策略 （默認(rèn)）

柚子快報激活碼778899分享：大數(shù)據(jù) Hadoop學(xué)習(xí)總結(jié)

http://yzkb.51969.com/

參考文章