官术网_书友最值得收藏!

3.2 HDFS體系結(jié)構(gòu)

HDFS采用master/slave的架構(gòu)來存儲數(shù)據(jù),這種架構(gòu)主要由4個部分組成,分別為HDFS Client、NameNode、DataNode和Secondary NameNode。下面分別介紹這4個組成部分及其功能。

(1)Client—客戶端

1)文件切分。文件上傳HDFS的時候,Client將文件切分成一個一個的Block,然后進(jìn)行存儲。

2)與NameNode交互,獲取文件的位置信息。

3)與DataNode交互,讀取或者寫入數(shù)據(jù)。

4)Client提供一些命令來管理HDFS,比如啟動或者關(guān)閉HDFS。

5)Client可以通過一些命令來訪問HDFS。

(2)NameNode—master是一個主管

1)管理HDFS的名稱空間。

2)管理數(shù)據(jù)塊(Block)映射信息。

3)配置副本策略。

4)處理客戶端讀寫請求。

(3)DataNode-slave(NameNode下達(dá)命令,DataNode執(zhí)行實際的操作)

1)存儲實際的數(shù)據(jù)塊。

2)執(zhí)行數(shù)據(jù)塊的讀/寫操作。

(4)Secondary NameNode

并非NameNode的熱備。當(dāng)NameNode掛掉的時候,它并不能馬上替換NameNode并提供服務(wù)。

1)輔助NameNode,分擔(dān)其工作量。

2)定期合并fsimage和fsedits,并推送給NameNode。

3)在緊急情況下,可輔助恢復(fù)NameNode。

HDFS總體架構(gòu)為主從結(jié)構(gòu),主節(jié)點只有一個(NameNode),從節(jié)點有很多個(DataNode),采用master-slave模式和NameNode中心服務(wù)器(master)來維護(hù)文件系統(tǒng)樹以及整棵樹內(nèi)的文件目錄、負(fù)責(zé)整個數(shù)據(jù)集群的管理。DataNode分布在不同的機架上(slave):在客戶端或者NameNode的調(diào)度下,存儲并檢索數(shù)據(jù)塊,并且定期向NameNode發(fā)送所存儲的數(shù)據(jù)塊的列表。客戶端與NameNode獲取元數(shù)據(jù),與DataNode交互獲取數(shù)據(jù)。默認(rèn)情況下,每個DataNode都保存了三個副本,其中兩個保存在同一個機架的兩個不同的節(jié)點上。另一個副本放在不同機架的節(jié)點上。NameNode和DataNode都被設(shè)計成可以在普通商用計算機上運行。這些計算機通常運行的是GNU/Linux操作系統(tǒng)。

HDFS采用Java語言開發(fā),因此任何支持Java的機器都可以部署NameNode和DataNode。一個典型的部署場景是集群中的一臺機器運行一個NameNode實例,其他機器分別運行一個DataNode實例。當(dāng)然,并不排除一臺機器運行多個DataNode實例的情況。集群中單一的NameNode的設(shè)計大大簡化了系統(tǒng)的架構(gòu)。NameNode是所有HDFS元數(shù)據(jù)的管理者,用戶數(shù)據(jù)永遠(yuǎn)不會經(jīng)過NameNode。HDFS總體架構(gòu)和物理網(wǎng)絡(luò)環(huán)境如圖3-6和圖3-7所示。

圖3-6 HDFS總體架構(gòu)

圖3-7 HDFS物理網(wǎng)絡(luò)環(huán)境

實驗一NameNode

1)通過maven下載源代碼,查看hdfs-default.xml配置文件。

描述信息為:確定在本地文件系統(tǒng)上的DFS名稱節(jié)點存儲名稱表(fsimage)。fsimage的內(nèi)容會被存儲到以逗號分隔的列表的目錄中,然后在所有的目錄中復(fù)制名稱表目錄,用于冗余。在實際應(yīng)用中只需要將上述的源代碼復(fù)制到hdfs-site.xml中,將<value>中的值改為以逗號分隔的列表即可。

注意:逗號后千萬不可加空格再寫文件。

2)通過源代碼信息的查找,尋找dfs.NameNode.name.dir的信息,首先應(yīng)該找到hadoop.tmp.dir的配置信息,從而尋找到core-site.xml。

3)根據(jù)上述分析查找tmp目錄及其子目錄的詳細(xì)信息,如圖3-8所示。

圖3-8 tmp目錄及其子目錄信息

4)VERSION信息的內(nèi)容。

顯示內(nèi)容:

例3-2多次格式化NameNode的問題原因解釋

(1)啟動服務(wù)器bin/hdfs oiv-i某個fsimage文件。

(2)查看內(nèi)容bin/hdfs dfs-ls-R webhdfs。//hdfs格式化會改變命名空間ID,首次格式化時DataNode和NameNode會產(chǎn)生一個相同的namespaceID,然后讀取數(shù)據(jù)即可,如果你重新執(zhí)行格式化的時候,NameNode的namespaceID改變了,但是DataNode的namespaceID沒有改變,兩邊就不一致了,如果重新啟動或進(jìn)行讀寫Hadoop就會掛掉。

解決方案:hdfs namenode-format-force進(jìn)行強制的格式化會同時格式化NameNode和DataNode。

完整的命令為hdfs namenode[-format[-clusterid cid][-force][-nonInteractive]]。

查看NameNode內(nèi)容:

1)啟動服務(wù)器bin/hdfs oiv-i某個fsimage文件,如圖3-9所示。

圖3-9 啟動服務(wù)器

2)查看內(nèi)容bin/hdfs dfs-ls-R webhdfs://127.0.0.1:5978/,如圖3-10所示。

圖3-10 查看內(nèi)容

3)導(dǎo)出結(jié)果bin/hdfs oiv-p XML-itmp/dfs/name/current/fsimage_0000000000000000055-o fsimage.xml。

4)查看edtis內(nèi)容bin/hdfs oev-i tmp/dfs/name/current/edits_0000000000000000057-0000000000000000186-o edits.xml,如圖3-11所示。

圖3-11 查看edtis內(nèi)容

在Hadoop2中,NameNode的50030端口換成8088,新的yarn平臺默認(rèn)是8088,如圖3-12所示。也可以通過yarn-site.xml進(jìn)行如下配置。

圖3-12 yarn 8088端口

實驗二DataNode

1)HDFS塊大小如何設(shè)定?

描述信息:新文件的默認(rèn)塊大?。ㄒ宰止?jié)為單位),可以使用以下后綴(不區(qū)分大小寫)指定大小(例如128k,512m,1g等),包括k(千),m(兆),g(giga),t(tera),p(拍);或提供完整的大小(以128MB為單位的134217728)。

2)如何修改默認(rèn)的塊大小?

只需要修改上述配置文件即可,但是這種方式是全局的修改。64M=67108864,如果想針對文件修改,只要使用命令修改即可:hadoop fs-Ddfs.blocksize=134217728-put./test.txt/test。

修改數(shù)據(jù)塊的測試,如圖3-13所示。

圖3-13 修改數(shù)據(jù)塊測試

源數(shù)據(jù)信息如圖3-14所示。

圖3-14 源數(shù)據(jù)信息

上傳之后在HDFS的配置目錄查看,其大小等于19B,而非64MB,如圖3-15所示。

圖3-15 修改塊大小

或者通過瀏覽器查看,如圖3-16和圖3-17所示。

圖3-16 選擇瀏覽器

圖3-17 效果對比

注意:一個文件可以產(chǎn)生多個塊,多個文件是不可能成為一個塊信息的,為了減輕NameNode的壓力,最好的方式就是一個文件一個塊。

3)文件塊存放路徑查看與具體信息解釋。

查找DataNode存放數(shù)據(jù)的位置,配置信息在hdfs-site.xml中,如圖3-18所示。

圖3-18 配置信息

進(jìn)入DataNode存放信息的目錄查看。

可以查看到元數(shù)據(jù)的信息以及數(shù)據(jù)信息,如圖3-19所示。

圖3-19 元數(shù)據(jù)信息

注意:可以在本地新建一個文件,上傳到HDFS中,查看是否增加了塊信息。

副本機制:默認(rèn)為3。vi hdfs-site.xml可以修改,配置文件對全局生效。

如果想一部分文件副本為3,一部分文件副本為2,同樣在命令行執(zhí)行操作即可,如圖3-20和圖3-21所示。

圖3-20 查看副本

圖3-21 副本數(shù)修改

HDFS的優(yōu)缺點總結(jié)如下。

1.HDFS的優(yōu)點

(1)處理超大文件

這里的超大文件通常是指數(shù)百MB、甚至數(shù)百TB大小的文件。目前在實際應(yīng)用中,HDFS已經(jīng)能用來存儲管理PB級的數(shù)據(jù)了。

(2)流式的訪問數(shù)據(jù)

HDFS的設(shè)計建立在更多地響應(yīng)“一次寫入、多次讀寫”任務(wù)的基礎(chǔ)上。這意味著一個數(shù)據(jù)集一旦由數(shù)據(jù)源生成,就會被復(fù)制分發(fā)到不同的存儲節(jié)點中,然后響應(yīng)各種各樣的數(shù)據(jù)分析任務(wù)請求。在多數(shù)情況下,分析任務(wù)都會涉及數(shù)據(jù)集中的大部分?jǐn)?shù)據(jù),也就是說,對HDFS來說,請求讀取整個數(shù)據(jù)集要比讀取一條記錄更加高效。

(3)運行于廉價的商用機器集群上

Hadoop設(shè)計對硬件需求比較低,只需運行在低廉的商用硬件集群上,而無需運行在昂貴的高可用性機器上。廉價的商用機也就意味著大型集群中出現(xiàn)節(jié)點故障情況的概率非常高。這就要求設(shè)計HDFS時要充分考慮數(shù)據(jù)的可靠性、安全性及高可用性。

2.HDFS的缺點

(1)不適合低延遲數(shù)據(jù)訪問

如果要處理一些用戶要求時間比較短的低延遲應(yīng)用請求,則HDFS不適合。HDFS是為了處理大型數(shù)據(jù)集分析任務(wù)的,主要是為達(dá)到高的數(shù)據(jù)吞吐量而設(shè)計的,這就可能要求以高延遲作為代價。

改進(jìn)策略:對于那些有低延時要求的應(yīng)用程序,HBase是一個更好的選擇。通過上層數(shù)據(jù)管理項目來盡可能地彌補這個不足。在性能上有了很大的提升,它的口號就是實時進(jìn)行。使用緩存或多master設(shè)計可以降低client的數(shù)據(jù)請求壓力,以減少延時。

(2)無法高效存儲大量小文件

因為NameNode把文件系統(tǒng)的元數(shù)據(jù)放置在內(nèi)存中,所以文件系統(tǒng)所能容納的文件數(shù)目是由NameNode的內(nèi)存大小來決定的。一般來說,每一個文件、文件夾和Block需要占據(jù)150B左右的空間,所以,如果你有100萬個文件,每一個占據(jù)一個Block,就至少需要300MB內(nèi)存。當(dāng)前來說,數(shù)百萬的文件還是可行的,當(dāng)擴(kuò)展到數(shù)十億時,對于當(dāng)前的硬件水平來說就無法實現(xiàn)了。還有一個問題就是,因為Maptask的數(shù)量是由splits來決定的,所以用MapReduce處理大量的小文件時,就會產(chǎn)生過多的Maptask,線程管理開銷將會增加作業(yè)時間。

舉個例子,處理10,000MB的文件,若每個split為1MB,那就會有10,000個Maptask,會有很大的線程開銷;若每個split為100MB,則只有100個Maptask,每個Maptask將會有更多的事情做,而線程的管理開銷也將減小很多。

改進(jìn)策略:要想讓HDFS能處理好小文件,有以下幾種方法。

1)利用SequenceFile、MapFile、Har等方式歸檔小文件,這個方法的原理就是把小文件歸檔起來管理,HBase就是基于此的。對于這種方法,如果想找回原來的小文件內(nèi)容,就必須得知道與歸檔文件的映射關(guān)系。

2)橫向擴(kuò)展,一個Hadoop集群能管理的小文件有限,那就把幾個Hadoop集群拖在一個虛擬服務(wù)器后面,形成一個大的Hadoop集群。Google也曾經(jīng)這樣做過。

3)多master設(shè)計,這個作用顯而易見。正在研發(fā)中的GFS II也改為分布式多Master設(shè)計,還支持master的故障轉(zhuǎn)移,而且Block大小改為1MB,有意要調(diào)優(yōu)處理小文件。

(3)不支持多用戶寫入及任意修改文件

在HDFS的一個文件中只有一個寫入者,而且寫操作只能在文件末尾完成,即只能執(zhí)行追加操作。目前HDFS還不支持多個用戶對同一文件的寫操作以及在文件任意位置進(jìn)行修改。

主站蜘蛛池模板: 邯郸市| 邳州市| 贵德县| 安龙县| 宣城市| 广灵县| 托里县| 绥棱县| 凤冈县| 和林格尔县| 海城市| 湾仔区| 高安市| 萨迦县| 博白县| 文水县| 东安县| 石柱| 乳山市| 古丈县| 全州县| 西贡区| 大化| 华亭县| 兴海县| 普定县| 柳州市| 邹平县| 钟祥市| 山东省| 潜山县| 射阳县| 共和县| 临沂市| 玉山县| 宣恩县| 福安市| 阿拉尔市| 纳雍县| 克什克腾旗| 精河县|