1 HDFS簡介 1.1 Hadoop 2.0介紹 Hadoop是Apache的一個分布式系統(tǒng)基礎(chǔ)架構(gòu)，可以為海量數(shù)據(jù)提供存儲和計(jì)算。Hadoop 2.0即第二代Hadoop系統(tǒng)，其框架最核心的設(shè)計(jì)是HDFS、MapReduce和YARN。其中，HDFS為海量數(shù)據(jù)提供存儲，MapReduce用于分布式計(jì)算，YARN用于進(jìn)行資源管理。

Hadoop 1.0和Hadoop 2.0的結(jié)構(gòu)對比：

?

Hadoop 2.0的主要改進(jìn)有：

1、通過YARN實(shí)現(xiàn)資源的調(diào)度與管理，從而使Hadoop 2.0可以運(yùn)行更多種類的計(jì)算框架，如Spark等。

2、實(shí)現(xiàn)了NameNode的HA方案，即同時有2個NameNode（一個Active另一個Standby），如果ActiveNameNode掛掉的話，另一個NameNode會轉(zhuǎn)入Active狀態(tài)提供服務(wù)，保證了整個集群的高可用。

3、實(shí)現(xiàn)了HDFS federation，由于元數(shù)據(jù)放在NameNode的內(nèi)存當(dāng)中，內(nèi)存限制了整個集群的規(guī)模，通過HDFS federation使多個NameNode組成一個聯(lián)邦共同管理DataNode，這樣就可以擴(kuò)大集群規(guī)模。

4、Hadoop RPC序列化擴(kuò)展性好，通過將數(shù)據(jù)類型模塊從RPC中獨(dú)立出來，成為一個獨(dú)立的可插拔模塊。

1.2 HDFS概述 HDFS是一個分布式文件系統(tǒng)，具有高容錯的特點(diǎn)。它可以部署在廉價的通用硬件上，提供高吞吐率的數(shù)據(jù)訪問，適合需要處理海量數(shù)據(jù)集的應(yīng)用程序。

主要特點(diǎn)：

1、支持超大文件：支持TB級的數(shù)據(jù)文件。

2、檢測和快速應(yīng)對硬件故障：HDFS的檢測和冗余機(jī)制很好克服了大量通用硬件平臺上的硬件故障問題。

3、高吞吐量：批量處理數(shù)據(jù)。

4、簡化一致性模型：一次寫入多次讀取的文件處理模型有利于提高吞吐量。

HDFS不適合的場景：低延遲數(shù)據(jù)訪問；大量的小文件；多用戶寫入文件、修改文件。

HDFS的構(gòu)成：NameNode保存著HDFS的名字空間，對于任何對文件系統(tǒng)元數(shù)據(jù)產(chǎn)生修改的操作；DataNode將HDFS數(shù)據(jù)以文件的形式存儲在本地文件系統(tǒng)中，它并不知道有關(guān)HDFS文件的信息。

數(shù)據(jù)塊：數(shù)據(jù)塊是HDFS的文件存儲處理單元，在Hadoop 2.0中默認(rèn)大小為128MB，可根據(jù)業(yè)務(wù)情況進(jìn)行配置。數(shù)據(jù)塊的存在，使得HDFS可以保存比存儲節(jié)點(diǎn)單一磁盤大的文件，而且簡化了存儲管理，方便容錯，有利于數(shù)據(jù)復(fù)制。

1.3 HDFS讀寫流程 讀文件的流程：1、客戶端client使用open函數(shù)打開文件；2、DistributedFileSystem用RPC調(diào)用元數(shù)據(jù)節(jié)點(diǎn)，得到文件的數(shù)據(jù)塊信息；3、對于每一個數(shù)據(jù)塊，元數(shù)據(jù)節(jié)點(diǎn)返回保存數(shù)據(jù)塊的數(shù)據(jù)節(jié)點(diǎn)的地址；4、DistributedFileSystem返回FSDataInputStream給客戶端，用來讀取數(shù)據(jù)；5、客戶端調(diào)用FSDataInputStream的read函數(shù)開始讀取數(shù)據(jù)；6、FSDataInputStream連接保存此文件第一個數(shù)據(jù)塊的最近的數(shù)據(jù)節(jié)點(diǎn)；7、Data從數(shù)據(jù)節(jié)點(diǎn)讀到客戶端；8、當(dāng)此數(shù)據(jù)塊讀取完畢時，FSDataInputStream關(guān)閉和此數(shù)據(jù)節(jié)點(diǎn)的連接，然后連接此文件下一個數(shù)據(jù)塊的最近的數(shù)據(jù)節(jié)點(diǎn)；9、當(dāng)客戶端讀取數(shù)據(jù)完畢時，調(diào)用FSDataInputStream的close函數(shù)；10、在讀取數(shù)據(jù)的過程中，如果客戶端在與數(shù)據(jù)節(jié)點(diǎn)通信出現(xiàn)錯誤，則嘗試連接包含此數(shù)據(jù)塊的下一個數(shù)據(jù)節(jié)點(diǎn)。失敗的數(shù)據(jù)節(jié)點(diǎn)將被記錄，以后不再連接。HDFS的讀文件流程如下圖所示：

?

寫文件的流程：1、客戶端client調(diào)用create函數(shù)創(chuàng)建文件；2、DistributedFileSystem用RPC調(diào)用元數(shù)據(jù)節(jié)點(diǎn)，在文件系統(tǒng)的命名空間中創(chuàng)建一個新的文件；3、元數(shù)據(jù)節(jié)點(diǎn)首先確定文件是否存在，并且客戶端是否有創(chuàng)建文件的權(quán)限，然后創(chuàng)建新文件；4、DistributedFileSystem返回FSDataOutputStream給客戶端用于寫數(shù)據(jù)；5、客戶端開始寫入數(shù)據(jù)，FSDataOutputStream將數(shù)據(jù)分成塊，寫入data queue；6、Data queue由DataStreamer讀取，并通知元數(shù)據(jù)節(jié)點(diǎn)分配數(shù)據(jù)節(jié)點(diǎn)，用來存儲數(shù)據(jù)塊（每塊默認(rèn)復(fù)制3塊），分配的數(shù)據(jù)節(jié)點(diǎn)放在一個pipeline里；7、DataStreamer將數(shù)據(jù)塊寫入pipeline中的第一個數(shù)據(jù)節(jié)點(diǎn)，第一個數(shù)據(jù)節(jié)點(diǎn)將數(shù)據(jù)塊發(fā)送給第二個數(shù)據(jù)節(jié)點(diǎn)，第二個數(shù)據(jù)節(jié)點(diǎn)將數(shù)據(jù)發(fā)送給第三個數(shù)據(jù)節(jié)點(diǎn)；8、FSDataOutputStream為發(fā)出去的數(shù)據(jù)塊保存了ack queue，等待pipeline中的數(shù)據(jù)節(jié)點(diǎn)告知數(shù)據(jù)已經(jīng)寫入成功；9、如果數(shù)據(jù)節(jié)點(diǎn)在寫入的過程中失敗，則進(jìn)行以下幾個操作：一是關(guān)閉pipeline并將ack queue中的數(shù)據(jù)塊放入data queue的開始；二是當(dāng)前數(shù)據(jù)塊在已寫入的數(shù)據(jù)節(jié)點(diǎn)中被元數(shù)據(jù)節(jié)點(diǎn)賦予新的標(biāo)示，錯誤節(jié)點(diǎn)重啟后察覺其數(shù)據(jù)塊過時而被刪除；三是失敗的數(shù)據(jù)節(jié)點(diǎn)從pipeline中移除，另外的數(shù)據(jù)塊則寫入pipeline中的另外兩個數(shù)據(jù)節(jié)點(diǎn)；四是元數(shù)據(jù)節(jié)點(diǎn)被通知此數(shù)據(jù)塊的復(fù)制塊數(shù)不足，從而再創(chuàng)建第三份備份；10、當(dāng)客戶端結(jié)束寫入數(shù)據(jù)，則調(diào)用close函數(shù)將所有的數(shù)據(jù)塊寫入pipeline中的數(shù)據(jù)節(jié)點(diǎn)，并等待ack queue返回成功，最后通知元數(shù)據(jù)節(jié)點(diǎn)寫入完畢。HDFS的寫文件流程如下圖所示：

?

2 YARN原理介紹 2.1 YARN產(chǎn)生背景 Hadoop 1.0的弊端包括：

1、擴(kuò)展性差：JobTracker同時兼?zhèn)淞速Y源管理和作業(yè)控制兩個功能，這是整個系統(tǒng)的最大瓶頸，它嚴(yán)重制約了整個集群的擴(kuò)展性。

2、可靠性差：JobTracker存在單點(diǎn)故障，JobTracker出現(xiàn)問題將導(dǎo)致整個集群不可用。

3、資源利用率低：資源無法在多個任務(wù)間共享或合理分配，導(dǎo)致無法有效利用各種資源。

4、無法支持多種計(jì)算框架：Hadoop 1.0只支持MapReduce這種離線批處理計(jì)算模式，而無法支持內(nèi)存計(jì)算、流式計(jì)算、迭代式計(jì)算等。

正是由于Hadoop 1.0存在以上這些弊端，所以Hadoop 2.0推出了資源管理器YARN，有效解決了上述問題。

2.2 YARN基本架構(gòu) YARN是Hadoop 2.0的資源管理器。它是一個通用的資源管理系統(tǒng)，可為上層應(yīng)用提供統(tǒng)一的資源管理和調(diào)度，它的引入為集群在利用率、資源統(tǒng)一管理和數(shù)據(jù)共享等方面帶來了巨大好處。

YARN的基本設(shè)計(jì)思想是將Hadoop 1.0中的JobTracker拆分成了兩個獨(dú)立的服務(wù)：一個全局的資源管理器ResourceManager和每個應(yīng)用程序特有的ApplicationMaster。其中ResourceManager負(fù)責(zé)整個系統(tǒng)的資源管理和分配，而ApplicationMaster負(fù)責(zé)單個應(yīng)用程序的管理，其基本架構(gòu)如下圖所示：

?

YARN總體上仍然是Master/Slave結(jié)構(gòu)。在整個資源管理框架中，ResourceManager為Master，NodeManager為Slave，并通過HA方案實(shí)現(xiàn)了ResourceManager的高可用。ResourceManager負(fù)責(zé)對各個NodeManager上的資源進(jìn)行統(tǒng)一管理和調(diào)度。當(dāng)用戶提交一個應(yīng)用程序時，需要提供一個用以跟蹤和管理這個程序的ApplicationMaster，它負(fù)責(zé)向ResourceManager申請資源，并要求NodeManger啟動可以占用一定資源的任務(wù)。由于不同的ApplicationMaster被分布到不同的節(jié)點(diǎn)上，因此它們之間不會相互影響。

ResourceManager：它是一個全局的資源管理器，負(fù)責(zé)整個系統(tǒng)的資源管理和分配，主要由調(diào)度器和應(yīng)用程序管理器兩個組件構(gòu)成。

調(diào)度器：根據(jù)容量、隊(duì)列等限制條件，將系統(tǒng)中的資源分配給各個正在運(yùn)行的應(yīng)用程序。調(diào)度器僅根據(jù)應(yīng)用程序的資源需求進(jìn)行資源分配，而資源分配單位用一個抽象概念“資源容器”（簡稱Container）表示，Container是一個動態(tài)資源分配單位，它將內(nèi)存、CPU、磁盤、網(wǎng)絡(luò)等資源封裝在一起，從而限定每個任務(wù)使用的資源量。

應(yīng)用程序管理器：負(fù)責(zé)管理整個系統(tǒng)中所有的應(yīng)用程序，包括應(yīng)用程序提交、與調(diào)度器協(xié)商資源以啟動ApplicationMaster、監(jiān)控ApplicationMaster運(yùn)行狀態(tài)并在失敗時重新啟動它等。

ApplicationMaster：用戶提交的每個應(yīng)用程序均包含1個ApplicationMaster，主要功能包括與ResourceManager調(diào)度器協(xié)商以獲取資源、將得到的任務(wù)進(jìn)一步分配給內(nèi)部的任務(wù)、與NodeManager通信以啟動/停止任務(wù)、監(jiān)控所有任務(wù)運(yùn)行狀態(tài)并在任務(wù)運(yùn)行失敗時重新為任務(wù)申請資源以重啟任務(wù)等。

NodeManager：它是每個節(jié)點(diǎn)上的資源和任務(wù)管理器，它不僅定時向ResourceManager匯報本節(jié)點(diǎn)上的資源使用情況和各個Container的運(yùn)行狀態(tài)，還接收并處理來自ApplicationMaster的Container啟動/停止等各種請求。

Container：它是YARN中的資源抽象，它封裝了某個節(jié)點(diǎn)上的多維度資源，如內(nèi)存、CPU、磁盤、網(wǎng)絡(luò)等，當(dāng)ApplicationMaster向ResourceManager申請資源時，返回的資源便是用Container表示的。YARN會為每個任務(wù)分配一個Container，且該任務(wù)只能使用該Container中描述的資源。

2.3 YARN工作流程 YARN的工作流程如下圖所示：

?

步驟1：用戶向YARN中提交應(yīng)用程序，其中包括用戶程序、ApplicationMaster程序、ApplicationMaster啟動命令等。

步驟2：ResourceManager為應(yīng)用程序分配第一個Container，并與對應(yīng)的NodeManager通信，要求它在這個Container中啟動應(yīng)用程序的ApplicationMaster。

步驟3：ApplicationMaster首先向ResourceManager注冊，這樣用戶可以直接通過ResourceManager查看應(yīng)用程序的運(yùn)行狀態(tài)，然后ApplicationMaster為各個任務(wù)申請資源，并監(jiān)控它們的運(yùn)行狀態(tài)，直到運(yùn)行結(jié)束，即重復(fù)步驟4-7。

步驟4：ApplicationMaster采用輪詢的方式通過RPC協(xié)議向ResourceManager申請和領(lǐng)取資源。

步驟5：一旦ApplicationMaster成功申請到資源，便開始與對應(yīng)的NodeManager通信，要求它啟動任務(wù)。

步驟6：NodeManager為任務(wù)設(shè)置好運(yùn)行環(huán)境（包括環(huán)境變量、JAR包、二進(jìn)制程序等）后，將任務(wù)啟動命令寫到一個腳本中，并通過運(yùn)行該腳本啟動任務(wù)。

步驟7：各個任務(wù)通過某個RPC協(xié)議向ApplicationMaster匯報自己的狀態(tài)和進(jìn)度，使ApplicationMaster能夠隨時掌握各個任務(wù)的運(yùn)行狀態(tài)，從而可以在任務(wù)失敗時重新啟動任務(wù)。在應(yīng)用程序運(yùn)行過程中，用戶可隨時通過RPC向ApplicationMaster查詢應(yīng)用程序的當(dāng)前運(yùn)行狀態(tài)。

步驟8：應(yīng)用程序運(yùn)行完成后，ApplicationMaster通過RPC協(xié)議向ResourceManager注銷并關(guān)閉自己。

3 MapReduce原理介紹

3.1 MapReduce介紹

MapReduce是由Google公司研究提出的一種面向大規(guī)模數(shù)據(jù)處理的并行計(jì)算模型和方法，是Hadoop面向大數(shù)據(jù)并行處理的計(jì)算模型、框架和平臺。

MapReduce執(zhí)行流包括input、map、shuffle、reduce和output共5個過程，如下圖所示：

?

3.2MapReduce2運(yùn)行原理 YARN框架下的Mapreduce工作流程如下圖所示：

?

步驟1：客戶端向集群提交作業(yè)。

步驟2：Job從ResourceManager獲取新的作業(yè)應(yīng)用程序ID。

步驟3：客戶端檢查作業(yè)的輸出情況，計(jì)算輸入分片，并將作業(yè)jar包、配置、分片信息等作業(yè)資源復(fù)制到HDFS。

步驟4：Job向ResourceManager提交作業(yè)。

步驟5：ResourceManager接收到作業(yè)后，將作業(yè)請求傳遞給調(diào)度器，調(diào)度器根據(jù)作業(yè)信息為ResourceManager分配一個container，然后ResourceManager在NodeManager的管理下，在container中啟動一個ApplicationMaster進(jìn)程。

步驟6：ApplicationMaster對作業(yè)進(jìn)行初始化，并保持對作業(yè)的跟蹤，判斷作業(yè)是否完成。

步驟7：ApplicationMaster根據(jù)存儲在HDFS中的分片信息確定Map和Reduce的數(shù)量。

步驟8：ApplicationMaster為本次作業(yè)的Map和Reduce以輪詢的方式向ResourceManager申請container。

步驟9：ApplicationMaster獲取到container后，與NodeManager進(jìn)行通信啟動container。

步驟10：container從HDFS中獲取作業(yè)的jar包、配置和分布式緩存文件等，將任務(wù)需要的資源本地化。

步驟11：container啟動Map或Reduce任務(wù)。

3.3 shuffle及排序 Mapreduce的map端輸出作為輸入傳遞給reduce端，并按鍵排序的過程稱為shuffle。shuffle的字面含義是洗牌，即將map產(chǎn)生的數(shù)據(jù)通過分區(qū)、排序等過程分配給了不同的reduce任務(wù)。Mapreduce的數(shù)據(jù)處理流程如下圖所示：

?

Map階段：

1、每個輸入分片會讓一個map任務(wù)來處理，默認(rèn)情況下，以HDFS的一個塊的大小（默認(rèn)為128M，可設(shè)置）為一個分片。map輸出的結(jié)果會暫時放在一個環(huán)形內(nèi)存緩沖區(qū)中（該緩沖區(qū)的大小默認(rèn)為100M，由io.sort.mb屬性控制）。當(dāng)該緩沖區(qū)快要溢出時（默認(rèn)為緩沖區(qū)大小的80%，由io.sort.spill.percent屬性控制），會在本地文件系統(tǒng)中創(chuàng)建一個溢出文件，將該緩沖區(qū)中的數(shù)據(jù)寫入這個文件。

2、在寫入磁盤之前，線程首先根據(jù)reduce任務(wù)的數(shù)目將數(shù)據(jù)劃分為相同數(shù)目的分區(qū)，也就是一個reduce任務(wù)對應(yīng)一個分區(qū)的數(shù)據(jù)。這樣做是為了避免有些reduce任務(wù)分配到大量數(shù)據(jù)，而有些reduce任務(wù)卻分到很少數(shù)據(jù)，甚至沒有分到數(shù)據(jù)的尷尬局面。然后對每個分區(qū)中的數(shù)據(jù)進(jìn)行排序，如果此時設(shè)置了Combiner，將排序后的結(jié)果進(jìn)行combine操作，這樣做可以有效減少磁盤IO和網(wǎng)絡(luò)IO。

3、當(dāng)map任務(wù)輸出最后一個記錄時，可能會有很多的溢出文件，這時需要將這些文件合并。合并的過程中會不斷地進(jìn)行排序和combine操作，這樣做是為了盡量減少每次寫入磁盤的數(shù)據(jù)量和盡量減少下一復(fù)制階段網(wǎng)絡(luò)傳輸?shù)臄?shù)據(jù)量。最后合并成了一個已分區(qū)且已排序的文件。為了減少網(wǎng)絡(luò)傳輸?shù)臄?shù)據(jù)量，這里可以將數(shù)據(jù)壓縮，只要將mapred.compress.map.out設(shè)置為true就可以了。

4、將分區(qū)中的數(shù)據(jù)拷貝給相對應(yīng)的reduce任務(wù)。那么分區(qū)中的數(shù)據(jù)如何知道它對應(yīng)的reduce是哪個呢？ ApplicationMaster保存了整個作業(yè)的宏觀信息，只要reduce任務(wù)向ApplicationMaster獲取對應(yīng)的map輸出位置就可以了。

Reduce階段：

1、Reduce會接收到不同map任務(wù)傳來的數(shù)據(jù)，并且每個map傳來的數(shù)據(jù)都是有序的。如果reduce接受的數(shù)據(jù)量相當(dāng)小，則直接存儲在內(nèi)存中，如果數(shù)據(jù)量超過了該緩沖區(qū)大小的一定比例，則對數(shù)據(jù)合并后溢寫到磁盤中。

2、隨著溢寫文件的增多，后臺線程會將它們合并成一個更大的有序文件，這樣做是為了給后面的合并節(jié)省時間。其實(shí)不管在map端還是reduce端，MapReduce都是反復(fù)地執(zhí)行排序、合并操作，所以說排序是hadoop的靈魂。

3、在合并的過程中會產(chǎn)生許多的中間文件（寫入磁盤了），但MapReduce會讓寫入磁盤的數(shù)據(jù)盡可能地少，并且最后一次合并的結(jié)果并沒有寫入磁盤，而是直接輸入到reduce函數(shù)。

轉(zhuǎn)載于:https://www.cnblogs.com/cmbk/p/10229998.html

總結(jié)

以上是生活随笔為你收集整理的HDFS2.X架构及工作原理的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。