【文章內(nèi)容簡介】 pache 下的一個(gè)開源項(xiàng)目，目前得到了大量的應(yīng)用。很多企業(yè)以及研究機(jī)構(gòu)使用HADOOP 框架作為研究或者構(gòu)建自己的云計(jì)算服務(wù)平臺(tái)。目前，HADOOP 已經(jīng)成長為包括Hadoop mon，HDFS, MapReduce，ZooKeeper，Avro，Chukwa,HBase，Hive，Mahout，Pig 在內(nèi)的10 個(gè)子項(xiàng)目。其中，HDFS 和MapReduce 是這個(gè)項(xiàng)目的核心。要使用HADOOP 構(gòu)建自己的云計(jì)算服務(wù)平臺(tái)，必須深刻的理解和掌握HDFS 和MapReduce。其實(shí)，作為一個(gè)開源項(xiàng)目，HADOOP 主要產(chǎn)生于Google 分布式文件系統(tǒng)GFS以及Google 的Map/Reduce 編程模式[2]。2．2 HDFS(HADOOP 分布式文件系統(tǒng))機(jī)制HDFS 是一個(gè)運(yùn)行在普通的組件集群上的分布式文件系統(tǒng)，它是HADOOP 框架主要的存儲(chǔ)系統(tǒng)。由于HADOOP 具有高數(shù)據(jù)吞吐量，并且實(shí)現(xiàn)了高度容錯(cuò)，因此具有很高的效能。本節(jié)將對(duì)HDFS 的核心機(jī)制和架構(gòu)作深入的研究和分析。研究內(nèi)容和觀點(diǎn)主要來自Hadoop 的官方站點(diǎn)。2．2．1 前提和設(shè)計(jì)目標(biāo)①硬件錯(cuò)誤硬件錯(cuò)誤是常態(tài)而不是異常。HDFS 可能由成百上千的服務(wù)器所構(gòu)成，每個(gè)服務(wù)器上存儲(chǔ)著文件系統(tǒng)的部分?jǐn)?shù)據(jù)。我們面對(duì)的現(xiàn)實(shí)是構(gòu)成系統(tǒng)的組件數(shù)目是巨大的，而且任一組件都有可能失效，這意味著總是有一部分HDFS 的組件是不工作的。因此錯(cuò)誤檢測(cè)和快速、自動(dòng)的恢復(fù)是HDFS 最核心的架構(gòu)目標(biāo)。②流式數(shù)據(jù)訪問運(yùn)行在HDFS 上的應(yīng)用和普通的應(yīng)用不同，需要流式訪問它們的數(shù)據(jù)集。HDFS的設(shè)計(jì)中更多的考慮到了數(shù)據(jù)批處理，而不是用戶交互處理。比之?dāng)?shù)據(jù)訪問的低延遲問題，更關(guān)鍵的在于數(shù)據(jù)訪問的高吞吐量。POSIX 標(biāo)準(zhǔn)設(shè)置的很多硬性約束對(duì)HDFS 應(yīng)用系統(tǒng)不是必需的。為了提高數(shù)據(jù)的吞吐量，在一些關(guān)鍵方面對(duì)POSIX的語義做了一些修改。③大規(guī)模數(shù)據(jù)集運(yùn)行在HDFS 上的應(yīng)用具有很大的數(shù)據(jù)集。HDFS 上的一個(gè)典型文件大小一般都在G 字節(jié)至T 字節(jié)。因此，HDFS 被調(diào)節(jié)以支持大文件存儲(chǔ)。它應(yīng)該能提供整體上高的數(shù)據(jù)傳輸帶寬，能在一個(gè)集群里擴(kuò)展到數(shù)百個(gè)節(jié)點(diǎn)。一個(gè)單一的HDFS實(shí)例應(yīng)該能支撐數(shù)以千萬計(jì)的文件。④簡單的一致性模型HDFS 應(yīng)用需要一個(gè)“一次寫入多次讀取”的文件訪問模型。一個(gè)文件經(jīng)過創(chuàng)建、寫入和關(guān)閉之后就不需要改變。這一假設(shè)簡化了數(shù)據(jù)一致性問題，并且使高吞吐量的數(shù)據(jù)訪問成為可能。Map/Reduce 應(yīng)用或者網(wǎng)絡(luò)爬蟲應(yīng)用都非常適合這個(gè)模型。目前還有計(jì)劃在將來擴(kuò)充這個(gè)模型，使之支持文件的附加寫操作。⑤“移動(dòng)計(jì)算比移動(dòng)數(shù)據(jù)更劃算”一個(gè)應(yīng)用請(qǐng)求的計(jì)算，離它操作的數(shù)據(jù)越近就越高效，在數(shù)據(jù)達(dá)到海量級(jí)別的時(shí)候更是如此。因?yàn)檫@樣就能降低網(wǎng)絡(luò)阻塞的影響，提高系統(tǒng)數(shù)據(jù)的吞吐量。將計(jì)算移動(dòng)到數(shù)據(jù)附近，比之將數(shù)據(jù)移動(dòng)到應(yīng)用所在顯然更好。HDFS 為應(yīng)用提供了將它們自己移動(dòng)到數(shù)據(jù)附近的接口。⑥異構(gòu)軟硬件平臺(tái)間的可移植性HDFS 在設(shè)計(jì)的時(shí)候就考慮到平臺(tái)的可移植性。這種特性方便了HDFS 作為大規(guī)模數(shù)據(jù)應(yīng)用平臺(tái)的推廣[3]。2．2．2 Namenode 和DatanodeHDFS 采用master/slave 架構(gòu)。一個(gè)HDFS 集群是由一個(gè)Namenode 和一定數(shù)目的Datanodes 組成。Namenode 是一個(gè)中心服務(wù)器，負(fù)責(zé)管理文件系統(tǒng)的名字空間(namespace)以及客戶端對(duì)文件的訪問。集群中的Datanode 一般是一個(gè)節(jié)點(diǎn)一個(gè)，負(fù)責(zé)管理它所在節(jié)點(diǎn)上的存儲(chǔ)。HDFS 暴露了文件系統(tǒng)的名字空間，用戶能夠以文件的形式在上面存儲(chǔ)數(shù)據(jù)。從內(nèi)部看，一個(gè)文件其實(shí)被分成一個(gè)或多個(gè)數(shù)據(jù)塊，這些塊存儲(chǔ)在一組Datanode 上。Namenode 執(zhí)行文件系統(tǒng)的名字空間操作，比如打開、關(guān)閉、重命名文件或目錄。它也負(fù)責(zé)確定數(shù)據(jù)塊到具體Datanode 節(jié)點(diǎn)的映射。Datanode 負(fù)責(zé)處理文件系統(tǒng)客戶端的讀寫請(qǐng)求。在Namenode 的統(tǒng)一調(diào)度下進(jìn)行數(shù)據(jù)塊的創(chuàng)建、刪除和復(fù)制。Namenode 和Datanode 被設(shè)計(jì)成可以在普通的商用機(jī)器上運(yùn)行。這些機(jī)器一般運(yùn)行著GNU/Linux 操作系統(tǒng)(OS)。HDFS 采用Java 語言開發(fā)，因此任何支持Java的機(jī)器都可以部署Namenode 或Datanode。由于采用了可移植性極強(qiáng)的Java 語言，使得HDFS 可以部署到多種類型的機(jī)器上。一個(gè)典型的部署場(chǎng)景是一臺(tái)機(jī)器上只運(yùn)行一個(gè)Namenode 實(shí)例，而集群中的其它機(jī)器分別運(yùn)行一個(gè)Datanode 實(shí)例。這種架構(gòu)并不排斥在一臺(tái)機(jī)器上運(yùn)行多個(gè)Datanode，只不過這樣的情況比較少見。集群中單一Namenode 的結(jié)構(gòu)大大簡化了系統(tǒng)的架構(gòu)。Namenode 是所有HDFS 元數(shù)據(jù)的仲裁者和管理者，這樣，用戶數(shù)據(jù)永遠(yuǎn)不會(huì)流過Namenode[4]。2．2．3 文件系統(tǒng)的名字空間HDFS 支持傳統(tǒng)的層次型文件組織結(jié)構(gòu)。用戶或者應(yīng)用程序可以創(chuàng)建目錄，然后將文件保存在這些目錄里。文件系統(tǒng)名字空間的層次結(jié)構(gòu)和大多數(shù)現(xiàn)有的文件系統(tǒng)類似：用戶可以創(chuàng)建、刪除、移動(dòng)或重命名文件。當(dāng)前，HDFS 不支持用戶磁盤配額和訪問權(quán)限控制，也不支持硬鏈接和軟鏈接。但是HDFS 架構(gòu)并不妨礙實(shí)現(xiàn)這些特性。Namenode 負(fù)責(zé)維護(hù)文件系統(tǒng)的名字空間，任何對(duì)文件系統(tǒng)名字空間或?qū)傩缘男薷亩紝⒈籒amenode 記錄下來。應(yīng)用程序可以設(shè)置HDFS 保存的文件的副本數(shù)目。文件副本的數(shù)目稱為文件的副本系數(shù)，這個(gè)信息也是由Namenode 保存的。2．2．4 通訊協(xié)議所有的HDFS 通訊協(xié)議都是建立在TCP/IP 協(xié)議之上?？蛻舳送ㄟ^一個(gè)可配置的TCP 端口連接到Namenode，通過ClientProtocol 協(xié)議與Namenode 交互。而Datanode 使用DatanodeProtocol 協(xié)議與Namenode 交互。一個(gè)遠(yuǎn)程過程調(diào)用(RPC)模型被抽象出來封裝ClientProtocol 和Datanodeprotocol 協(xié)議。在設(shè)計(jì)上，Namenode不會(huì)主動(dòng)發(fā)起RPC，而是響應(yīng)來自客戶端或 Datanode 的RPC 請(qǐng)求。2．2．5 健壯性HDFS 的主要目標(biāo)就是即使在出錯(cuò)的情況下也要保證數(shù)據(jù)存儲(chǔ)的可靠性。常見的三種出錯(cuò)情況是：Namenode 出錯(cuò), Datanode 出錯(cuò)和網(wǎng)絡(luò)割裂(network partitions)。①磁盤數(shù)據(jù)錯(cuò)誤，心跳檢測(cè)和重新復(fù)制每個(gè)Datanode 節(jié)點(diǎn)周期性地向Namenode 發(fā)送心跳信號(hào)。網(wǎng)絡(luò)割裂可能導(dǎo)致一部分Datanode 跟Namenode 失去聯(lián)系。Namenode 通過心跳信號(hào)的缺失來檢測(cè)這一情況，并將這些近期不再發(fā)送心跳信號(hào)Datanode 標(biāo)記為宕機(jī)，不會(huì)再將新的IO 請(qǐng)求發(fā)給它們。任何存儲(chǔ)在宕機(jī)Datanode 上的數(shù)據(jù)將不再有效。Datanode 的宕機(jī)可能會(huì)引起一些數(shù)據(jù)塊的副本系數(shù)低于指定值，Namenode 不斷地檢測(cè)這些需要復(fù)制的數(shù)據(jù)塊，一旦發(fā)現(xiàn)就啟動(dòng)復(fù)制操作。在下列情況下，可能需要重新復(fù)制：某個(gè)Datanode 節(jié)點(diǎn)失效，某個(gè)副本遭到損壞，Datanode 上的硬盤錯(cuò)誤，或者文件的副本系數(shù)增大。②集群均衡HDFS 的架構(gòu)支持?jǐn)?shù)據(jù)均衡策略。如果某個(gè)Datanode 節(jié)點(diǎn)上的空閑空間低于特定的臨界點(diǎn)，按照均衡策略系統(tǒng)就會(huì)自動(dòng)地將數(shù)據(jù)從這個(gè)Datanode 移動(dòng)到其他空閑的Datanode。當(dāng)對(duì)某個(gè)文件的請(qǐng)求突然增加，那么也可能啟動(dòng)一個(gè)計(jì)劃創(chuàng)建該文件新的副本，并且同時(shí)重新平衡集群中的其他數(shù)據(jù)。③數(shù)據(jù)完整性從某個(gè)Datanode 獲取的數(shù)據(jù)塊有可能是損壞的，損壞可能是由Datanode 的存儲(chǔ)設(shè)備錯(cuò)誤、網(wǎng)絡(luò)錯(cuò)誤或者軟件bug 造成的。HDFS 客戶端軟件實(shí)現(xiàn)了對(duì)HDFS文件內(nèi)容的校驗(yàn)和(checksum)檢查。當(dāng)客戶端創(chuàng)建一個(gè)新的HDFS 文件，會(huì)計(jì)算這個(gè)文件每個(gè)數(shù)據(jù)塊的校驗(yàn)和，并將校驗(yàn)和作為一個(gè)單獨(dú)的隱藏文件保存在同一個(gè)HDFS 名字空間下。當(dāng)客戶端獲取文件內(nèi)容后，它會(huì)檢驗(yàn)從Datanode 獲取的數(shù)據(jù)跟相應(yīng)的校驗(yàn)和文件中的校驗(yàn)和是否匹配，如果不匹配，客戶端可以選擇從其他Datanode 獲取該數(shù)據(jù)塊的副本。④元數(shù)據(jù)磁盤錯(cuò)誤FsImage 和Editlog 是HDFS 的核心數(shù)據(jù)結(jié)構(gòu)。如果這些文件損壞了，整個(gè)HDFS實(shí)例都將失效。因而，Namenode 可以配置成支持維護(hù)多個(gè)FsImage 和Editlog 的副本。任何對(duì)FsImage 或者Editlog 的修改，都將同步到它們的副本上。這種多副本的同步操作可能會(huì)降低Namenode 每秒處理的名字空間事務(wù)數(shù)量。然而這個(gè)代價(jià)是可以接受的，因?yàn)榧词笻DFS 的應(yīng)用是數(shù)據(jù)密集的，它們也非元數(shù)據(jù)密集的。當(dāng)Namenode 重啟的時(shí)候，它會(huì)選取最近的完整的FsImage 和Editlog 來使用。Namenode 是HDFS 集群中的單點(diǎn)故障(single point of failure)所在。如果Namenode機(jī)器故障，是需要手工干預(yù)的[5]。2．3 HADOOP MapReduce 編程模型2．3．1 操作介紹MapReduce 的操作主要包括Map，Combine 和Reduce 過程。①M(fèi)ap 操作在MapReduce 框架中，Map 過程是高度并行的。Map 的數(shù)目通常是由輸入數(shù)據(jù)的大小決定的，即輸入文件的總塊數(shù)。對(duì)于輸入文件，框架會(huì)根據(jù)文件所占的塊的個(gè)數(shù)而將文件劃分為相應(yīng)的片段。在文件劃分的時(shí)候，不會(huì)考慮文件的內(nèi)部邏輯結(jié)構(gòu)。文件都會(huì)按照二進(jìn)制字節(jié)數(shù)大小進(jìn)行片段劃分。對(duì)于產(chǎn)生的每一個(gè)文件片段，框架會(huì)自動(dòng)的創(chuàng)建一個(gè)Map 任務(wù)用來處理文件片段。形式將鍵值對(duì)傳遞給Map 函數(shù)。InputFormat 會(huì)將文件劃分為多個(gè)邏輯InputSplit 實(shí)例。每個(gè)InputSplit 會(huì)對(duì)應(yīng)著一個(gè)Map 函數(shù)。同時(shí)， InputFormat 會(huì)提供RecordReader 的實(shí)現(xiàn)。這個(gè)RecordReader 把InputSplit 的輸入文件轉(zhuǎn)化成(key,value)的形式，傳遞給Map。同時(shí)，InputFormat 類也需要處理達(dá)到FileSplit 邊界值的記錄。比如，默認(rèn)的TextInputFormat 會(huì)讀取超過分割邊界值的FileSplit 的最后一行，當(dāng)讀取其他的非第一個(gè)FileSplit 時(shí)，TextInputFormat 會(huì)忽略第一個(gè)新行以上部分的內(nèi)容。InputFormat 產(chǎn)生給Map 的鍵值對(duì)可以不必嚴(yán)格控制。即我們只需要完全傳遞給Map 文件的內(nèi)容即可。比如默認(rèn)TextInputFormat 的輸出中，key 即為行在文件中的偏移量，而value 則為行的內(nèi)容，并使用Text 對(duì)象來表示。Map 函數(shù)被定義在一個(gè)Mapper 類中。Mapper 對(duì)象會(huì)獲取從RecordReader 中得到的(key,value)對(duì)。用戶在Map 函數(shù)中會(huì)定義自己的處理規(guī)則來處理(key,value)，然后輸出另一對(duì)(key,value)，這個(gè)鍵值對(duì)被成為中間鍵值對(duì)，并被Output 使用collect方法收集。對(duì)于輸出的中間鍵值對(duì)，我們可以自己定義key 和value 的類型，這個(gè)與輸入鍵值對(duì)的類型沒有關(guān)系。但是，在HADOOP 框架中，所有的key 必須要實(shí)現(xiàn)WritableComparable 接口，所有的value 必須實(shí)現(xiàn)Writable 接口，這樣，所有的kay，value 都能被序列化，并且可以通過key 對(duì)鍵值對(duì)進(jìn)行排序操作。②Combine 操作當(dāng)Map 操作輸出它的(key,value)鍵值對(duì)之后，這些值會(huì)由于效率的原因存留在內(nèi)存中。對(duì)于每一個(gè)的Map 的輸出鍵值對(duì)，我們會(huì)聚集然后分發(fā)到不同的Reduce執(zhí)行規(guī)約的操作。但有時(shí)候，對(duì)于特定的任務(wù)，我們可以在Map 本地就執(zhí)行一個(gè)規(guī)約的操作，這樣，Map 輸出的結(jié)果得到的鍵值對(duì)就會(huì)得到大大的縮減，這樣不光提高了效率，也減少了網(wǎng)絡(luò)傳輸?shù)呢?fù)荷。這個(gè)在Map 本地執(zhí)行的規(guī)約過程我們使用Combiner 對(duì)象來完成。當(dāng)我們定義和使用了一個(gè)Combiner 類之后，Map 過程產(chǎn)生的(key，value)鍵值對(duì)就不會(huì)理解寫到輸出。這些輸出會(huì)先被手機(jī)到列表，每個(gè)key 對(duì)應(yīng)一個(gè)列表。當(dāng)一定的數(shù)量的鍵值對(duì)被寫入時(shí)，這個(gè)緩沖區(qū)里所有的鍵值對(duì)會(huì)被清空并轉(zhuǎn)移到Combliner 類中的Reduce 方法中進(jìn)行相應(yīng)的規(guī)約操作。最后，將操作合并后，產(chǎn)生的鍵值對(duì)輸出并進(jìn)行集合，最后分發(fā)給Reduce。③ReduceReduce 規(guī)約任務(wù)的輸出來自于Map 的輸入。Reduce 過程只要通過三個(gè)階段來完成。在第一階段，框架會(huì)獲得所有的Map 過程的輸出。第二階段，Reduce 會(huì)按照key 的值對(duì)Reduce 的輸入進(jìn)行分組。其實(shí)，第一階段和第二階段是同時(shí)進(jìn)行的，Map 的輸出在被取回的同時(shí)被合并。第三階段就是調(diào)用Reduce 函數(shù)進(jìn)行規(guī)約操作的階段。每一個(gè)Reduce 被分配了Map 的輸出后，這些鍵值對(duì)會(huì)作為一個(gè)集合被Reduce 操作。在分布式環(huán)境下，在開始任務(wù)之前，這些鍵值對(duì)集合就會(huì)被拷貝到Reduce 任務(wù)所在節(jié)點(diǎn)的本地文件系統(tǒng)。一旦數(shù)據(jù)準(zhǔn)備就緒，Reduce 規(guī)約操作開始。其實(shí)，Reduce 的過程很簡單：鍵值對(duì)被順序讀入，進(jìn)行操作。在Reduce 過程中，作為key 都是相同的，我們只需對(duì)value 進(jìn)行一個(gè)循環(huán)迭代的操作。當(dāng)規(guī)約完成，每個(gè)執(zhí)行的Reduce 的輸出都會(huì)包含到一個(gè)輸出文件。輸出文件的格式由JobConf。SetOutputFormat 方法來指定[6]。2．4 本章小結(jié)本章詳細(xì)介紹了HADOOP 系統(tǒng)中HADOOP 分布式文件系統(tǒng)HDFS 和HADOOP 并行編程模式MapReduce 的核心機(jī)制和實(shí)現(xiàn)原理。在本章最后，介紹了MapReduce 的調(diào)度和容錯(cuò)。在對(duì)HDFS 的介紹上，主要從HDFS 和其他文件系統(tǒng)的差別入手進(jìn)行分析。對(duì)HDFS 的缺點(diǎn)也做了一些相應(yīng)的介紹。另外，重點(diǎn)對(duì)HDFS 的實(shí)現(xiàn)和使用做了很多的研究和分析。對(duì)MapReduce 的研究我們主要建立在如何更好的使用MapReduce 進(jìn)行并行編程的角度。我們對(duì)MapReduce 的編程模式、執(zhí)行流程以及