Hadoop中HDFS的存儲(chǔ)機(jī)制

1、Hadoop中HDFS的存儲(chǔ)機(jī)制HDFS （Hadoop Distributed File System）是Hadoop分布式計(jì)算中的數(shù)據(jù)存儲(chǔ)系統(tǒng)， 是基于流數(shù)據(jù)模式訪問(wèn)和處理超大文件的需求而開(kāi)發(fā)的。下面我們首先介紹HDFS中的一些基礎(chǔ)概念，然后介紹HDFS中讀寫(xiě)操作的過(guò)程，最后分析了 HDFS的優(yōu)缺點(diǎn)。1. HDFS中的基礎(chǔ)概念i=Block： HDFS中的存儲(chǔ)單元是每個(gè)數(shù)據(jù)塊block，HDFS默認(rèn)的最基本的存儲(chǔ)單位是64M的數(shù) 據(jù)塊。和普通的文件系統(tǒng)相同的是，HDFS中的文件也是被分成64M 一塊的數(shù)據(jù)塊存儲(chǔ)的。 不同的是，在HDFS中，如果一個(gè)文件大小小于一個(gè)數(shù)據(jù)塊的大小，它是不需要占

2、用整個(gè)數(shù) 據(jù)塊的存儲(chǔ)空間的。NameNode：元數(shù)據(jù)節(jié)點(diǎn)。該節(jié)點(diǎn)用來(lái)管理文件系統(tǒng)中的命名空間，是 master。其將所有的為了見(jiàn)和文件夾的元數(shù)據(jù)保存在一個(gè)文件系統(tǒng)樹(shù)中，這些信息在硬盤(pán)上 保存為了命名空間鏡像（namespace image）以及修改日志（edit log），后面還會(huì)講到。 此外，NameNode還保存了一個(gè)文件包括哪些數(shù)據(jù)塊，分布在哪些數(shù)據(jù)節(jié)點(diǎn)上。然而，這些 信息不存放在硬盤(pán)上，而是在系統(tǒng)啟動(dòng)的時(shí)候從數(shù)據(jù)節(jié)點(diǎn)收集而成的oDataNode：數(shù)據(jù)節(jié)點(diǎn)， 是HDFS真正存儲(chǔ)數(shù)據(jù)的地方。客戶端（client）和元數(shù)據(jù)節(jié)點(diǎn)（NameNode）可以向數(shù)據(jù)節(jié) 點(diǎn)請(qǐng)求寫(xiě)入或者讀出數(shù)據(jù)塊。此外，

3、DataNode需要周期性的向元數(shù)據(jù)節(jié)點(diǎn)回報(bào)其存儲(chǔ)的數(shù) 據(jù)塊信息。Secondary NameNode:從元數(shù)據(jù)節(jié)點(diǎn)。從元數(shù)據(jù)節(jié)點(diǎn)并不是NameNode出現(xiàn)問(wèn)題 時(shí)候的備用節(jié)點(diǎn)，它的主要功能是周期性的將NameNode中的namespace image和edit log 合并，以防log文件過(guò)大。此外，合并過(guò)后的namespace image文件也會(huì)在Secondary NameNode上保存一份，以防NameNode失敗的時(shí)候，可以恢復(fù)。edit log：修改日志，當(dāng)文 件系統(tǒng)客戶端client進(jìn)行寫(xiě)操作的時(shí)候，我們就要把這條記錄放在修改日志中。在記錄了 修改日志后，NameNode則修改內(nèi)

4、存中的數(shù)據(jù)結(jié)構(gòu)。每次寫(xiě)操作成功之前，edit log都會(huì)同 步到文件系統(tǒng)中。fsimage：命名空間鏡像，它是內(nèi)存中的元數(shù)據(jù)在硬盤(pán)上的checkpointo 當(dāng)NameNode失敗的時(shí)候，最新的checkpoint的元數(shù)據(jù)信息就會(huì)從fsimage加載到內(nèi)存中， 然后注意重新執(zhí)行修改日志中的操作。而Secondary NameNode就是用來(lái)幫助元數(shù)據(jù)節(jié)點(diǎn)將 內(nèi)存中的元數(shù)據(jù)信息checkpoint到硬盤(pán)上的。具體checkpoint的過(guò)程如下圖：（參考hadoop集群的博客）checkpoint 的過(guò)程如下：Secondary NameNode 通知 NameNode 生成新的 日志文件，以后的

5、日志都寫(xiě)到新的日志文件中o Secondary NameNode用http get從NameNode獲得fsimage文件及舊的日志文件。Secondary NameNode 將fsimage文件加載到內(nèi)存中，并執(zhí)行日志文件中的操作，然后生成新的 fsimage 文件。Secondary NameNode 將新的 fsimage 文件用 http post 傳回 NameNodeo NameNode可以將舊的fsimage文件及舊的日志文件，換為新的 fsimage文件和新的日志文件（第一步生成的），然后更新fstime文件，寫(xiě)入此次checkpoint的時(shí)間。這樣NameNode中的fsim

6、age文件保存了最新的 checkpoint的元數(shù)據(jù)信息，日志文件也重新開(kāi)始，不會(huì)變的很大了。從元數(shù)據(jù)節(jié)點(diǎn)HDFS中文件讀寫(xiě)操作流程在HDFS中，文件的讀寫(xiě)過(guò)程就是client和NameNode以及DataNode 一起交互的過(guò)程。 我們已經(jīng)知道NameNode管理著文件系統(tǒng)的元數(shù)據(jù)，DataNode存儲(chǔ)的是實(shí)際的數(shù)據(jù)，那么 client就會(huì)聯(lián)系NameNode以獲取文件的元數(shù)據(jù)，而真正的文件讀取操作是直接和DataNode 進(jìn)行交互的。寫(xiě)文件的過(guò)程：客戶端調(diào)用create()來(lái)創(chuàng)建文件DistributedFileSystem用RPC調(diào)用元數(shù)據(jù)節(jié)點(diǎn)，在文件 系統(tǒng)的命名空間中創(chuàng)建一個(gè)新的文件。

7、元數(shù)據(jù)節(jié)點(diǎn)首先確定文件原來(lái)不存在，并且客戶端有 創(chuàng)建文件的權(quán)限，然后創(chuàng)建新文件。DistributedFileSystem返回DFSOutputStream，客戶端用于寫(xiě)數(shù)據(jù)。客戶端開(kāi)始寫(xiě)入數(shù)據(jù)，DFSOutputStream將數(shù)據(jù)分成塊，寫(xiě)入data queue。 Data queue由Data Streamer讀取，并通知元數(shù)據(jù)節(jié)點(diǎn)分配數(shù)據(jù)節(jié)點(diǎn)，用來(lái)存儲(chǔ)數(shù)據(jù)塊(每 塊默認(rèn)復(fù)制3塊)。分配的數(shù)據(jù)節(jié)點(diǎn)放在一個(gè)pipeline里。Data Streamer將數(shù)據(jù)塊寫(xiě)入 pipeline中的第一個(gè)數(shù)據(jù)節(jié)點(diǎn)。第一個(gè)數(shù)據(jù)節(jié)點(diǎn)將數(shù)據(jù)塊發(fā)送給第二個(gè)數(shù)據(jù)節(jié)點(diǎn)。第二個(gè) 數(shù)據(jù)節(jié)點(diǎn)將數(shù)據(jù)發(fā)送給第三個(gè)數(shù)據(jù)節(jié)點(diǎn)。DF

8、SOutputStream為發(fā)出去的數(shù)據(jù)塊保存了 ack queue，等待pipeline中的數(shù)據(jù)節(jié)點(diǎn)告知數(shù)據(jù)已經(jīng)寫(xiě)入成功。如果數(shù)據(jù)節(jié)點(diǎn)在寫(xiě)入的過(guò)程中 失敗：關(guān)閉pipeline，將ack queue中的數(shù)據(jù)塊放入data queue的開(kāi)始。當(dāng)前的數(shù)據(jù)塊在已經(jīng)寫(xiě)入的數(shù)據(jù)節(jié)點(diǎn)中被元數(shù)據(jù)節(jié)點(diǎn)賦予新的標(biāo)示，則錯(cuò)誤節(jié)點(diǎn)重啟后能夠 察覺(jué)其數(shù)據(jù)塊是過(guò)時(shí)的，會(huì)被刪除。失敗的數(shù)據(jù)節(jié)點(diǎn)從pipeline中移除，另外的數(shù)據(jù)塊則寫(xiě)入pipeline中的另外兩個(gè)數(shù)據(jù)節(jié)點(diǎn)。元數(shù)據(jù)節(jié)點(diǎn)則被通知此數(shù)據(jù)塊是復(fù)制塊數(shù)不足，將來(lái)會(huì)再創(chuàng)建第三份備份。當(dāng)客戶端結(jié)束寫(xiě)入數(shù)據(jù)，則調(diào)用stream的close函數(shù)。此操作將所有的數(shù)據(jù)塊寫(xiě)入

9、pipeline 中的數(shù)據(jù)節(jié)點(diǎn)，并等待ack queue返回成功。最后通知元數(shù)據(jù)節(jié)點(diǎn)寫(xiě)入完畢。client JVMl：reate6：演FSDwnamenodedient nodedatanodedatancdeNdineN 缺DdiaNodeDataNodePipelinedHDF5di entDistributedHleSyflem5： jck packet讀取文件的過(guò)程:客戶端(client)用 FileSystem 的 open()函數(shù)打開(kāi)文件 DistributedFileSystem用 RPC 調(diào)用 元數(shù)據(jù)節(jié)點(diǎn)，得到文件的數(shù)據(jù)塊信息。對(duì)于每一個(gè)數(shù)據(jù)塊，元數(shù)據(jù)節(jié)點(diǎn)返回保存數(shù)據(jù)塊的數(shù) 據(jù)

10、節(jié)點(diǎn)的地址。DistributedFileSystem返回FSDataInputStream給客戶端，用來(lái)讀取數(shù)據(jù)。 客戶端調(diào)用stream的read ()函數(shù)開(kāi)始讀取數(shù)據(jù)DFSInputStream連接保存此文件第一個(gè)數(shù) 據(jù)塊的最近的數(shù)據(jù)節(jié)點(diǎn)。Data從數(shù)據(jù)節(jié)點(diǎn)讀到客戶端(client)當(dāng)此數(shù)據(jù)塊讀取完畢時(shí)，DFSInputStream關(guān)閉和此數(shù)據(jù)節(jié)點(diǎn)的連接，然后連接此文件下一個(gè)數(shù)據(jù)塊的最近的數(shù)據(jù)節(jié) 點(diǎn)。當(dāng)客戶端讀取完畢數(shù)據(jù)的時(shí)候，調(diào)用FSDataInputStream的close函數(shù)。在讀取數(shù)據(jù) 的過(guò)程中，如果客戶端在與數(shù)據(jù)節(jié)點(diǎn)通信出現(xiàn)錯(cuò)誤，則嘗試連接包含此數(shù)據(jù)塊的下一個(gè)數(shù)據(jù) 節(jié)點(diǎn)。失敗的

11、數(shù)據(jù)節(jié)點(diǎn)將被記錄，以后不再連接。HDFS的優(yōu)缺點(diǎn)分析優(yōu)點(diǎn)：1）能夠處理超大的文件；2）流式訪問(wèn)數(shù)據(jù)。HDFS能夠很好的處理“一次寫(xiě)入，多次讀寫(xiě)”的任務(wù)。也就是說(shuō)， 一個(gè)數(shù)據(jù)集一旦生成了，就會(huì)被復(fù)制到不同的存儲(chǔ)節(jié)點(diǎn)中，然后響應(yīng)各種各樣的數(shù)據(jù)分析任 務(wù)請(qǐng)求。在多數(shù)情況下，分析任務(wù)都會(huì)涉及到數(shù)據(jù)集中的大部分?jǐn)?shù)據(jù)。所以，HDFS請(qǐng)求讀 取整個(gè)數(shù)據(jù)集要比讀取一條記錄更加高效。3）可以運(yùn)行在比較廉價(jià)的商用機(jī)器集群上。缺點(diǎn)和改進(jìn)策略：1）不適合低延遲數(shù)據(jù)訪問(wèn)：HDFS是為了處理大型數(shù)據(jù)集分析任務(wù)的，主要是為達(dá)到大 數(shù)據(jù)分析，所以延遲時(shí)間可能會(huì)較高。改進(jìn)策略：對(duì)于那些有低延時(shí)要求的應(yīng)用程序，HBase 是一個(gè)

12、更好的選擇。通過(guò)上層數(shù)據(jù)管理項(xiàng)目來(lái)盡可能地彌補(bǔ)這個(gè)不足。在性能上有了很大的 提升，它的口號(hào)就是goes real time。使用緩存或多master設(shè)計(jì)可以降低client的數(shù)據(jù) 請(qǐng)求壓力，以減少延時(shí)。還有就是對(duì)HDFS系統(tǒng)內(nèi)部的修改，這就得權(quán)衡大吞吐量與低延時(shí) 了。2）無(wú)法高效存儲(chǔ)大量小文件：因?yàn)镹amenode把文件系統(tǒng)的元數(shù)據(jù)放置在內(nèi)存中，所以 文件系統(tǒng)所能容納的文件數(shù)目是由Namenode的內(nèi)存大小來(lái)決定。一般來(lái)說(shuō)，每一個(gè)文件、 文件夾和Block需要占據(jù)150字節(jié)左右的空間，所以，如果你有100萬(wàn)個(gè)文件，每一個(gè)占據(jù) 一個(gè)Block，你就至少需要300MB內(nèi)存。當(dāng)前來(lái)說(shuō)，數(shù)百萬(wàn)的文件還

13、是可行的，當(dāng)擴(kuò)展到數(shù) 十億時(shí)，對(duì)于當(dāng)前的硬件水平來(lái)說(shuō)就沒(méi)法實(shí)現(xiàn)了。還有一個(gè)問(wèn)題就是，因?yàn)镸ap task的數(shù) 量是由splits來(lái)決定的，所以用MR處理大量的小文件時(shí)，就會(huì)產(chǎn)生過(guò)多的Maptask，線程 管理開(kāi)銷將會(huì)增加作業(yè)時(shí)間。舉個(gè)例子，處理10000M的文件，若每個(gè)split為1M，那就會(huì) 有10000個(gè)Maptasks，會(huì)有很大的線程開(kāi)銷;若每個(gè)split為100M，則只有100個(gè)Maptasks， 每個(gè)Maptask將會(huì)有更多的事情做，而線程的管理開(kāi)銷也將減小很多。改進(jìn)策略：要想讓 HDFS能處理好小文件，有不少方法。利用SequenceFile、MapFile、Har等方式歸檔小文件， 這個(gè)方法的原理就是把小文件歸檔起來(lái)管理，HBase就是基于此的。對(duì)于這種方法，如果想 找回原來(lái)的小文件內(nèi)容，那就必須得知道與歸檔文件的映射關(guān)系。橫向擴(kuò)展，一個(gè)Hadoop 集群能管理的小文件有限，那就把幾個(gè)Hadoop集群拖在一個(gè)虛擬服務(wù)器后面，形成一個(gè)大 的Hadoop集群。google也是這么干過(guò)的。多Master設(shè)計(jì)，這個(gè)作用顯而易見(jiàn)了。正在研 發(fā)中的GFS II也要改為分布式多Master設(shè)計(jì)，還支持Master的Failove