分布式文件系統的設計需求大概是這么幾個：透明性、并發控制、可伸縮性、容錯以及安全需求等。我想試試從這幾個角度去觀察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。

第二、并發控制。客戶端對于文件的讀寫不應該影響其他客戶端對同一個文件的讀寫。要想實現近似原生文件系統的單個文件拷貝語義，分布式文件系統需要做出復 雜的交互，例如采用時間戳，或者類似回調承諾（類似服務器到客戶端的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框架緊密結合。