從HDFS看分佈式文件系統的設計需求

分佈式文件系統的設計需求大概是這麼幾個：透明性、併發控制、可伸縮性、容錯以及安全需求等。我想試試從這幾個角度去觀察HDFS的設計和實現，能夠更清楚地看出HDFS的應用場景和設計理念。

首先、透明性。若是按照開放分佈式處理的標準肯定就有8種透明性：訪問的透明性、位置的透明性、併發透明性、複製透明性、故障透明性、移動透明性、性能透明性和伸縮透明性。對於分佈式文件系統，最重要的是但願能達到5個透明性要求：

1）訪問的透明性：用戶能經過相同的操做來訪問本地文件和遠程文件資源。HDFS能夠作到這一點，若是HDFS設置成本地文件系統，而非分佈式，那麼讀寫 分佈式HDFS的程序能夠不用修改地讀寫本地文件，要作修改的是配置文件。可見，HDFS提供的訪問的透明性是不徹底的，畢竟它構建於java之上，不能 像NFS或者AFS那樣去修改unix內核，同時將本地文件和遠程文件以一致的方式處理。

2）位置的透明性：使用單一的文件命名空間，在不改變路徑名的前提下，文件或者文件集合能夠被重定位。HDFS集羣只有一個Namenode來負責文件系 統命名空間的管理，文件的block能夠從新分佈複製，block能夠增長或者減小副本，副本能夠跨機架存儲，而這一切對客戶端都是透明的。

3）移動的透明性：這一點與位置的透明性相似，HDFS中的文件常常因爲節點的失效、增長或者replication因子的改變或者從新均衡等進行着複製或者移動，而客戶端和客戶端程序並不須要改變什麼，Namenode的edits日誌文件記錄着這些變動。

4）性能的透明性和伸縮的透明性：HDFS的目標就是構建在大規模廉價機器上的分佈式文件系統集羣，可伸縮性毋庸置疑，至於性能能夠參考它首頁上的一些benchmark。

第2、併發控制。客戶端對於文件的讀寫不該該影響其餘客戶端對同一個文件的讀寫。要想實現近似原生文件系統的單個文件拷貝語義，分佈式文件系統須要作出復 雜的交互，例如採用時間戳，或者相似回調承諾（相似服務器到客戶端的RPC回調，在文件更新的時候；回調有兩種狀態：有效或者取消。客戶端經過檢查回調承 諾的狀態，來判斷服務器上的文件是否被更新過）。

HDFS並無這樣作，它的機制很是簡單，任什麼時候間都只容許一個寫的客戶端，文件經建立並寫入以後再也不改 變，它的模型是write-one-read-many， 一次寫，屢次讀。這與它的應用場合是一致，HDFS的文件大小一般是兆至T級的，這些數據不會常常修改，最常常的是被順序讀並處理，隨機讀不多，所以 HDFS很是適合MapReduce框架或者web crawler應用。HDFS文件的大小也決定了它的客戶端不能像某些分佈式文件系統那樣緩存經常使用到的幾百個文件。

第三，文件複製功能。一個文件能夠表示爲其內容在不一樣位置的多個拷貝。這樣作帶來了兩個好處：訪問同個文件時能夠從多個服務器中獲取從而改善服務的伸縮 性，另外就是提升了容錯能力，某個副本損壞了，仍然能夠從其餘服務器節點獲取該文件。HDFS文件的block爲了容錯都將被備份，根據配置的 replication因子來，默認是3。副本的存放策略也是頗有講究，一個放在本地機架的節點，一個放在同一機架的另外一節點，另外一個放在其餘機架上。這 樣能夠最大限度地防止因故障致使的副本的丟失。不只如此，HDFS讀文件的時候也將優先選擇從同一機架乃至同一數據中心的節點上讀取block。

第四，硬件和操做系統的異構性。因爲構建在java平臺上，HDFS的跨平臺能力毋庸置疑，得益於java平臺已經封裝好的文件IO系統，HDFS能夠在不一樣的操做系統和計算機上實現一樣的客戶端和服務端程序。

第五，容錯能力。在分佈式文件系統中，儘可能保證文件服務在客戶端或者服務端出現問題的時候能正常使用是很是重要的。HDFS的容錯能力大概能夠分爲兩個方面：文件系統的容錯性以及Hadoop自己的容錯能力。文件系統的容錯性經過這麼幾個手段：

在Namenode和Datanode之間維持心跳檢測，當因爲網絡故障之類的緣由，致使Datanode發出的心跳包沒有被Namenode正常收 到的時候，Namenode就不會將任何新的IO操做派發給那個Datanode，該Datanode上的數據被認爲是無效的，所以Namenode會檢 測是否有文件block的副本數目小於設置值，若是小於就自動開始複製新的副本並分發到其餘Datanode節點。

檢測文件block的完整性，HDFS會記錄每一個新建立的文件的全部block的校驗和。當之後檢索這些文件的時候，從某個節點獲取block，會首先確認校驗和是否一致，若是不一致，會從其餘Datanode節點上獲取該block的副本。

集羣的負載均衡，因爲節點的失效或者增長，可能致使數據分佈的不均勻，當某個Datanode節點的空閒空間大於一個臨界值的時候，HDFS會自動從其餘Datanode遷移數據過來。

Namenode上的fsimage和edits日誌文件是HDFS的核心數據結構，若是這些文件損壞了，HDFS將失效。於是，Namenode能夠配置成支持維護多 個FsImage和Editlog的拷貝。任何對FsImage或者Editlog的修改，都將同步到它們的副本上。它老是選取最近的一致的FsImage和Editlog使用。Namenode在HDFS是單點存在，若是Namenode所在的機器錯誤，手工的干預是必須的。

  文件的刪除，刪除並非立刻從Namenode移出namespace，而是放在/trash目錄隨時可恢復，直到超過設置時間才被正式移除。

再說Hadoop自己的容錯性，Hadoop支持升級和回滾，當升級Hadoop軟件時出現bug或者不兼容現象，能夠經過回滾恢復到老的Hadoop版本。

最後一個就是安全性問題，HDFS的安全性是比較弱的，只有簡單的與unix文件系統相似的文件許可控制，將來版本會實現相似NFS的kerberos驗證系統。

總結：HDFS做爲通用的分佈式文件系統並不適合，它在併發控制、緩存一致性以及小文件讀寫的效率上是比較弱的。可是它有本身明確的設計目標，那就是支 持大的數據文件（兆至T級），而且這些文件以順序讀爲主，以文件讀的高吞吐量爲目標，而且與MapReduce框架緊密結合。