1 HDFS體系結構簡單介紹及優缺點

1.1體系結構簡單介紹

HDFS是一個主/從(Mater/Slave)體系結構。從終于用戶的角度來看，它就像傳統的文件系統一樣，能夠通過文件夾路徑對文件運行CRUD(Create、Read、Update和Delete)操作。但因為分布式存儲的性質，HDFS集群擁有一個NameNode和一些DataNode。NameNode管理文件系統的元數據，DataNode存儲實際的數據。

client通過同NameNode和DataNodes的交互訪問文件系統。

client聯系NameNode以獲取文件的元數據，而真正的文件I/O操作是直接和DataNode進行交互的。

下圖為HDFS整體結構示意圖

?

1.1.1?NameNode

NameNode能夠看作是分布式文件系統中的管理者。主要負責管理文件系統的命名空間、集群配置信息和存儲塊的復制等。NameNode會將文件系統的Meta-data存儲在內存中，這些信息主要包含了文件信息、每個文件相應的文件塊的信息和每個文件塊在DataNode的信息等。

l

Masterl 管理HDFS的名稱空間l 管理數據塊映射信息l 配置副本策略l 處理client讀寫請求

1.1.2?Secondary namenode

并不是NameNode的熱備； 輔助NameNode，分擔其工作量； 定期合并fsimage和fsedits，推送給NameNode； 在緊急情況下。可輔助恢復NameNode。

1.1.3?DataNode

DataNode是文件存儲的基本單元，它將Block存儲在本地文件系統中，保存了Block的Meta-data，同一時候周期性地將全部存在的Block信息發送給NameNode。

Slavel 存儲實際的數據塊 運行數據塊讀/寫

1.1.4?Client

文件切分 與NameNode交互，獲取文件位置信息； 與DataNode交互。讀取或者寫入數據； 管理HDFS。 訪問HDFS。

1.1.5?文件寫入

1) Client向NameNode發起文件寫入的請求。 2) NameNode依據文件大小和文件塊配置情況。返回給Client它所管理部分DataNode的信息。 3) Client將文件劃分為多個Block，依據DataNode的地址信息，按順序寫入到每個DataNode塊中。

1.1.6?文件讀取

1) Client向NameNode發起文件讀取的請求。 2) NameNode返回文件存儲的DataNode的信息。

3) Client讀取文件信息。

HDFS典型的部署是在一個專門的機器上執行NameNode，集群中的其它機器各執行一個DataNode；也能夠在執行NameNode的機器上同一時候執行DataNode，或者一臺機器上執行多個DataNode。一個集群僅僅有一個NameNode的設計大大簡化了系統架構。

1.2長處

1.2.1?處理超大文件

這里的超大文件一般是指百MB、設置數百TB大小的文件。眼下在實際應用中，HDFS已經能用來存儲管理PB級的數據了。

1.2.2?流式的訪問數據

HDFS的設計建立在很多其它地響應"一次寫入、多次讀寫"任務的基礎上。

這意味著一個數據集一旦由數據源生成。就會被復制分發到不同的存儲節點中，然后響應各種各樣的數據分析任務請求。

在多數情況下，分析任務都會涉及數據集中的大部分數據，也就是說，對HDFS來說。請求讀取整個數據集要比讀取一條記錄更加高效。

1.2.3?執行于便宜的商用機器集群上

hadoop設計對硬件需求比較低。僅僅須執行在低廉的商用硬件集群上，而無需昂貴的高可用性機器上。便宜的商用機也就意味著大型集群中出現節點故障情況的概率很高。這就要求設計HDFS時要充分考慮數據的可靠性，安全性及高可用性。

1.3?缺點

1.3.1?不適合低延遲數據訪問

假設要處理一些用戶要求時間比較短的低延遲應用請求。則HDFS不適合。HDFS是為了處理大型數據集分析任務的，主要是為達到高的數據吞吐量而設計的，這就可能要求以高延遲作為代價。

改進策略：

對于那些有低延時要求的應用程序，HBase是一個更好的選擇。

通過上層數據管理項目來盡可能地彌補這個不足。在性能上有了非常大的提升，它的口號就是goes real time。

使用緩存或多master設計能夠降低client的數據請求壓力，以降低延時。還有就是對HDFS系統內部的改動，這就得權衡大吞吐量與低延時了，HDFS不是萬能的銀彈。

1.3.2?無法高效存儲大量小文件

由于Namenode把文件系統的元數據放置在內存中，所以文件系統所能容納的文件數目是由Namenode的內存大小來決定。一般來說，每個文件、目錄和Block須要占領150字節左右的空間。所以。假設你有100萬個文件，每個占領一個Block，你就至少須要300MB內存。當前來說，數百萬的文件還是可行的，當擴展到數十億時。對于當前的硬件水平來說就沒法實現了。另一個問題就是，由于Map

task的數量是由splits來決定的。所以用MR處理大量的小文件時。就會產生過多的Maptask。線程管理開銷將會添加作業時間。

舉個樣例。處理10000M的文件，若每一個split為1M。那就會有10000個Maptasks，會有非常大的線程開銷；若每一個split為100M。則僅僅有100個Maptasks。每一個Maptask將會有很多其它的事情做，而線程的管理開銷也將減小非常多。

改進策略：

要想讓HDFS能處理好小文件。有不少方法。

利用SequenceFile、MapFile、Har等方式歸檔小文件，這種方法的原理就是把小文件歸檔起來管理，HBase就是基于此的。

對于這樣的方法，假設想找回原來的小文件內容，那就必須得知道與歸檔文件的映射關系。橫向擴展，一個Hadoop集群能管理的小文件有限，那就把幾個Hadoop集群拖在一個虛擬server后面。形成一個大的Hadoop集群。google也是這么干過的。多Master設計，這個作用顯而易見了。正在研發中的GFS

II也要改為分布式多Master設計，還支持Master的Failover。并且Block大小改為1M。有意要調優處理小文件啊。

附帶個Alibaba DFS的設計，也是多Master設計。它把Metadata的映射存儲和管理分開了，由多個Metadata存儲節點和一個查詢Master節點組成。

1.3.3?不支持多用戶寫入及隨意改動文件

在HDFS的一個文件里僅僅有一個寫入者，并且寫操作僅僅能在文件末尾完畢。即僅僅能運行追加操作。

眼下HDFS還不支持多個用戶對同一文件的寫操作，以及在文件任何位置進行改動。

總結

以上是生活随笔為你收集整理的hdfs数据节点分发什么协议_HDFS主要节点解说(一)节点功能的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。