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所示。

【實驗一】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所示。

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所示。

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

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所示。

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

【實驗二】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所示。

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

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

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

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

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

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

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

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

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

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)行修改。