Hadoop分布式文件系統(HDFS)是一種分布式文件系統。它與現有的分布式文件系統有許多相似之處。但是，與其他分布式文件系統的差異是值得我們注意的：

• HDFS具有高度容錯能力，旨在部署在低成本硬件上。(高容錯)
• HDFS提供對數據的高吞吐量訪問，適用于具有海量數據集的應用程序。(高吞吐量)
• HDFS放寬了一些POSIX要求，以實現對文件系統數據的流式訪問。(流式訪問)
• HDFS最初是作為Apache Nutch網絡搜索引擎項目的基礎設施而構建的。HDFS是Apache Hadoop Core項目的一部分。

目標和假設

硬件故障檢測：硬件故障是常態而非例外。Hadoop通常部署在低成本的硬件上，并且通常包含成百上千的服務器，每個服務器都存儲文件系統數據的一部分。由于存在大量的組件，并且每個組件都具有不可忽略(non-trivial )的故障概率，這意味著HDFS的某些組件始終都不起作用。因此，故障檢測并快速恢復是HDFS的核心架構目標。

流式訪問：HDFS更適合批處理而不是交互式使用，更加注重數據訪問的高吞吐量而不是數據訪問的低延遲。在HDFS上運行的應用程序需要對其數據集進行流式訪問。

海量數據集：運行在HDFS上的應用程序具有大型數據集，HDFS中的一個典型文件的大小是g到tb，因此，HDFS被調優為支持大文件。它應該提供高聚合數據帶寬，并可擴展到單個集群中的數百個節點。它應該在一個實例中支持數千萬個文件。

一致性模型：HDFS應用程序需要一個一次寫入多次讀取的文件訪問模型。文件一旦創建、寫入和關閉，除了追加和截斷操作外，無需要更改。支持將內容追加到文件末尾，但無法在任意點更新。該假設簡化了數據一致性問題并實現了高吞吐量數據訪問。MapReduce應用程序或Web爬蟲應用程序完全適合此模型。

移動計算比移動數據便宜：應用程序請求的計算如果在其操作的數據附近執行，效率會高得多。當數據集的大小很大時尤其如此。這可以最大限度地減少網絡擁塞并提高系統的整體吞吐量。因此更好的做法是將計算遷移到更靠近數據所在的位置，而不是將數據移動到運行應用程序的位置。HDFS為應用程序提供了一些接口，使它們自己更接近數據所在的位置。

跨平臺和可移植：Hadoop使用Java語言開發，使得Hadoop具有良好的跨平臺性。

NameNode和DataNodes

HDFS具有主/從( master/slave)架構。HDFS集群由一個NameNode和許多DataNode組成，NameNode是一個主服務器(master)，管理文件系統名稱空間并管理客端對數據的訪問(NameNode在Hadoop集群中充當u管家/u的角色)。此外集群中每個節點通常是一個DataNode，DataNode管理它們的節點上存儲的數據。

HDFS公開文件系統名稱空間，并允許用戶數據存儲在文件中。在內部，文件被分成一個或多個塊(block)，這些塊存儲在DataNode中。NameNode執行文件系統名稱空間的相關操作，如打開、關閉和重命名文件和目錄。它還確定了塊到DataNode的映射(塊存儲到哪個DataNode中)。數據節點負責服務來自文件系統客戶端的讀寫請求。數據節點還根據NameNode的指令執行塊創建、刪除和復制。

深入理解Hadoop之HDFS架構

集群中單一NameNode的結構大大簡化了系統的架構。NameNode是所有HDFS元數據的仲裁者和管理者，這樣，用戶數據永遠不會流過NameNode。

文件系統名稱空間(namespace)

HDFS支持傳統的層次型文件組織結構。用戶或者應用程序可以創建目錄，然后將文件保存在這些目錄里。文件系統名稱空間的層次結構和大多數現有的文件系統類似：用戶可以創建、刪除、移動或重命名文件。當前，HDFS不支持用戶磁盤配額和訪問權限控制，也不支持硬鏈接和軟鏈接。但是HDFS架構并不妨礙實現這些特性。

NameNode負責維護文件系統的名稱空間，任何對文件系統名稱空間或屬性的修改都將被NameNode記錄下來。應用程序可以設置HDFS保存的文件的副本數目。文件副本的數目稱為文件的副本系數，這個信息也是由NameNode保存的。

如果想深入了解HDFS文件系統名稱空間可以查看這篇博文：http://leotse90.com/...

數據復制

HDFS被設計成能夠在一個大集群中跨機器可靠地存儲超大文件。它將每個文件存儲成一系列的數據塊，除了最后一個，所有的數據塊都是同樣大小的。為了容錯，文件的所有數據塊都會有副本。每個文件的數據塊大小和副本系數都是可配置的。應用程序可以指定某個文件的副本數目。副本系數可以在文件創建的時候指定，也可以在之后改變。HDFS中的文件都是一次性寫入的，并且嚴格要求在任何時候只能有一個寫入者。

NameNode全權管理數據塊的復制，它周期性地從集群中的每個DataNode接收心跳信號(Heartbeat )和塊狀態報告(Blockreport)。

接收到心跳信號意味著該DataNode節點工作正常。

塊狀態報告包含了一個該Datanode上所有數據塊的列表。

深入理解Hadoop之HDFS架構

副本存放: 最最開始的一步

副本的存放是HDFS可靠性和性能的關鍵。優化的副本存放策略是HDFS區分于其他大部分分布式文件系統的重要特性。這種特性需要做大量的調優，并需要經驗的積累。HDFS采用一種稱為機架感知(rack-aware)的策略來改進數據的可靠性、可用性和網絡帶寬的利用率。目前實現的副本存放策略只是在這個方向上的第一步。實現這個策略的短期目標是驗證它在生產環境下的有效性，觀察它的行為，為實現更先進的策略打下測試和研究的基礎。

大型HDFS實例一般運行在跨越多個機架的計算機組成的集群上，不同機架上的兩臺機器之間的通訊需要經過交換機。在大多數情況下，同一個機架內的兩臺機器間的帶寬會比不同機架的兩臺機器間的帶寬大。

通過一個機架感知的過程，NameNode可以確定每個DataNode所屬的機架id。一個簡單但沒有優化的策略就是將副本存放在不同的機架上。這樣可以有效防止當整個機架失效時數據的丟失，并且允許讀數據的時候充分利用多個機架的帶寬。這種策略設置可以將副本均勻分布在集群中，有利于當組件失效情況下的負載均衡。但是，因為這種策略的一個寫操作需要傳輸數據塊到多個機架，這增加了寫的代價。

在大多數情況下，副本系數是3，HDFS的存放策略是將一個副本存放在本地機架的節點上，一個副本放在同一機架的另一個節點上，最后一個副本放在不同機架的節點上。這種策略減少了機架間的數據傳輸，這就提高了寫操作的效率。機架的錯誤遠遠比節點的錯誤少，所以這個策略不會影響到數據的可靠性和可用性。于此同時，因為數據塊只放在兩個(不是三個)不同的機架上，所以此策略減少了讀取數據時需要的網絡傳輸總帶寬。在這種策略下，副本并不是均勻分布在不同的機架上。三分之一的副本在一個節點上，三分之二的副本在一個機架上，其他副本均勻分布在剩下的機架中，這一策略在不損害數據可靠性和讀取性能的情況下改進了寫的性能。

副本選擇

為了降低整體的帶寬消耗和讀取延時，HDFS會盡量讓讀取程序讀取離它最近的副本。如果在讀取程序的同一個機架上有一個副本，那么就讀取該副本。如果一個HDFS集群跨越多個數據中心，那么客戶端也將首先讀本地數據中心的副本。(就近原則)

安全模式

NameNode啟動后會進入一個稱為安全模式的特殊狀態。處于安全模式的NameNode是不會進行數據塊的復制的。NameNode從所有的 DataNode接收心跳信號和塊狀態報告。塊狀態報告包括了某個DataNode所有的數據塊列表。每個數據塊都有一個指定的最小副本數。當NameNode檢測確認某個數據塊的副本數目達到這個最小值，那么該數據塊就會被認為是副本安全(safely replicated)的;在一定百分比(這個參數可配置)的數據塊被NameNode檢測確認是安全之后(加上一個額外的30秒等待時間)，NameNode將退出安全模式狀態。接下來它會確定還有哪些數據塊的副本沒有達到指定數目，并將這些數據塊復制到其他DataNode上。

文件系統元數據的持久化

NameNode上保存著HDFS的DataNode空間。對于任何對文件系統元數據產生修改的操作，NameNode都會使用一種稱為EditLog的事務日志記錄下來。例如，在HDFS中創建一個文件，NameNode就會在Editlog中插入一條記錄來表示;同樣地，修改文件的副本系數也將往Editlog插入一條記錄。NameNode在本地操作系統的文件系統中存儲這個Editlog。整個文件系統的DataNode空間，包括數據塊到文件的映射、文件的屬性等，都存儲在一個稱為FsImage的文件中，這個文件也是放在NameNode所在的本地文件系統上。

NameNode在內存中保存著整個文件系統的DataNode空間和文件數據塊映射(Blockmap)的映像。這個關鍵的元數據結構設計得很緊湊，因而一個有4G內存的NameNode足夠支撐大量的文件和目錄。當NameNode啟動時，它從硬盤中讀取Editlog和FsImage，將所有Editlog中的事務作用在內存中的FsImage上，并將這個新版本的FsImage從內存中保存到本地磁盤上，然后刪除舊的Editlog，因為這個舊的Editlog的事務都已經作用在FsImage上了。這個過程稱為一個檢查點(checkpoint)。在當前實現中，檢查點只發生在NameNode啟動時，在不久的將來將實現支持周期性的檢查點。

Datanode將HDFS數據以文件的形式存儲在本地的文件系統中，它并不知道有關HDFS文件的信息。它把每個HDFS數據塊存儲在本地文件系統的一個單獨的文件中。Datanode并不在同一個目錄創建所有的文件，實際上，它用試探的方法來確定每個目錄的最佳文件數目，并且在適當的時候創建子目錄。在同一個目錄中創建所有的本地文件并不是最優的選擇，這是因為本地文件系統可能無法高效地在單個目錄中支持大量的文件。當一個Datanode啟動時，它會掃描本地文件系統，產生一個這些本地文件對應的所有HDFS數據塊的列表，然后作為報告發送到NameNode，這個報告就是塊狀態報告。

通訊協議

所有的HDFS通訊協議都是建立在TCP/IP協議之上。客戶端通過一個可配置的TCP端口連接到NameNode，通過ClientProtocol協議與NameNode交互。而Datanode使用DatanodeProtocol協議與NameNode交互。一個遠程過程調用(RPC)模型被抽象出來封裝ClientProtocol和Datanodeprotocol協議。在設計上，NameNode不會主動發起RPC，而是響應來自客戶端或 Datanode 的RPC請求。

健壯性

HDFS的主要目標就是即使在出錯的情況下也要保證數據存儲的可靠性。常見的三種出錯情況是：NameNode出錯, Datanode出錯和網絡割裂(network partitions)。

磁盤數據錯誤，心跳檢測和重新復制

每個Datanode節點周期性地向NameNode發送心跳信號。網絡割裂可能導致一部分Datanode跟NameNode失去聯系。NameNode通過心跳信號的缺失來檢測這一情況，并將這些近期不再發送心跳信號Datanode標記為宕機，不會再將新的IO請求發給它們。任何存儲在宕機Datanode上的數據將不再有效。Datanode的宕機可能會引起一些數據塊的副本系數低于指定值，NameNode不斷地檢測這些需要復制的數據塊，一旦發現就啟動復制操作。在下列情況下，可能需要重新復制：某個Datanode節點失效，某個副本遭到損壞，Datanode上的硬盤錯誤，或者文件的副本系數增大。

集群均衡

HDFS的架構支持數據均衡策略。如果某個Datanode節點上的空閑空間低于特定的臨界點，按照均衡策略系統就會自動地將數據從這個Datanode移動到其他空閑的Datanode。當對某個文件的請求突然增加，那么也可能啟動一個計劃創建該文件新的副本，并且同時重新平衡集群中的其他數據。這些均衡策略目前還沒有實現。

數據完整性

從某個Datanode獲取的數據塊有可能是損壞的，損壞可能是由Datanode的存儲設備錯誤、網絡錯誤或者軟件bug造成的。HDFS客戶端軟件實現了對HDFS文件內容的校驗和(checksum)檢查。當客戶端創建一個新的HDFS文件，會計算這個文件每個數據塊的校驗和，并將校驗和作為一個單獨的隱藏文件保存在同一個HDFSDataNode空間下。當客戶端獲取文件內容后，它會檢驗從Datanode獲取的數據跟相應的校驗和文件中的校驗和是否匹配，如果不匹配，客戶端可以選擇從其他Datanode獲取該數據塊的副本。

元數據磁盤錯誤

FsImage和Editlog是HDFS的核心數據結構。如果這些文件損壞了，整個HDFS實例都將失效。因而，NameNode可以配置成支持維護多個FsImage和Editlog的副本。任何對FsImage或者Editlog的修改，都將同步到它們的副本上。這種多副本的同步操作可能會降低NameNode每秒處理的DataNode空間事務數量。然而這個代價是可以接受的，因為即使HDFS的應用是數據密集的，它們也非元數據密集的。當NameNode重啟的時候，它會選取最近的完整的FsImage和Editlog來使用。

增加故障恢復能力的另一個選擇是使用多個NameNode 在NFS上使用共享存儲或使用分布式編輯日志(稱為Journal)來啟用高可用性。后者是推薦的方法。

快照

快照支持在特定時刻存儲數據副本。快照功能的一種用途可以是將損壞的HDFS實例回滾到先前已知的良好時間點。

數據組織

數據塊

HDFS被設計成支持大文件，適用HDFS的是那些需要處理大規模的數據集的應用。這些應用都是只寫入數據一次，但卻讀取一次或多次，并且讀取速度應能滿足流式讀取的需要。HDFS支持文件的“一次寫入多次讀取”語義。一個典型的數據塊大小是128MB。因而，HDFS中的文件總是按照128M被切分成不同的塊，每個塊盡可能地存儲于不同的Datanode中。

流水線復制

當客戶端向HDFS文件寫入數據的時候，一開始是寫到本地臨時文件中。假設該文件的副本系數設置為3，當本地臨時文件累積到一個數據塊的大小時，客戶端會從NameNode獲取一個Datanode列表用于存放副本。然后客戶端開始向第一個Datanode傳輸數據，第一個Datanode一小部分一小部分(4 KB)地接收數據，將每一部分寫入本地倉庫，并同時傳輸該部分到列表中第二個Datanode節點。第二個Datanode也是這樣，一小部分一小部分地接收數據，寫入本地倉庫，并同時傳給第三個Datanode。最后，第三個Datanode接收數據并存儲在本地。因此，Datanode能流水線式地從前一個節點接收數據，并在同時轉發給下一個節點，數據以流水線的方式從前一個Datanode復制到下一個。

可訪問性

可以通過多種不同方式從應用程序訪問HDFS。本地，HDFS 為應用程序提供了FileSystem Java API。一本Java API的C語言包裝和REST API也是可用的。此外，還有HTTP瀏覽器，也可用于瀏覽HDFS實例的文件。通過使用NFS網關，HDFS可以作為客戶端本地文件系統的一部分進行安裝。

FS Shell

HDFS以文件和目錄的形式組織用戶數據。它提供了一個命令行的接口(FS Shell)讓用戶與HDFS中的數據進行交互。命令的語法和用戶熟悉的其他shell(例如 bash, csh)工具類似。下面是一些動作/命令的示例：

• 深入理解Hadoop之HDFS架構
• FS shell適用于需要腳本語言與存儲數據交互的應用程序。
• DFSAdmin
• 典型的HDFS安裝配置Web服務器以通過可配置的TCP端口公開HDFS命名空間。這允許用戶使用Web瀏覽器導航HDFS命名空間并查看其文件的內容。
• 深入理解Hadoop之HDFS架構
• 存儲空間回收
• 文件的刪除和恢復

如果啟用了回收站配置，當用戶或應用程序刪除某個文件時，這個文件并沒有立刻從HDFS中刪除。實際上，HDFS會將這個文件重命名轉移到/trash目錄(/user/username/.Trash)。只要文件還在/trash目錄中，該文件就可以被迅速地恢復。文件在/trash中保存的時間是可配置的，當超過這個時間時，NameNode就會將該文件從DataNode空間中刪除。刪除文件會使得該文件相關的數據塊被釋放。注意，從用戶刪除文件到HDFS空閑空間的增加之間會有一定時間的延遲。

以下是一個示例，它將顯示FS Shell如何從HDFS中刪除文件。我們在目錄delete下創建了2個文件(test1和test2) 

$ hadoop fs -mkdir -p delete/test1  
$ hadoop fs -mkdir -p delete/test2  
$ hadoop fs -ls delete/  
Found 2 items  
drwxr-xr-x - hadoop hadoop 0 2015-05-08 12:39 delete/test1  
drwxr-xr-x - hadoop hadoop 0 2015-05-08 12:40 delete/test2 

我們將刪除文件test1。下面的注釋顯示該文件已移至/trash目錄。 

$ hadoop fs -rm -r delete/test1  
Moved: hdfs://localhost:8020/user/hadoop/delete/test1 to trash at: hdfs://localhost:8020/user/hadoop/.Trash/Current 

現在我們將使用skipTrash選項刪除該文件，該選項不會將文件發送到Trash。它將從HDFS中完全刪除。 

$ hadoop fs -rm -r -skipTrash delete/test2  
Deleted delete/test2 

我們現在可以看到Trash目錄只包含文件test1。 

$ hadoop fs -ls .Trash/Current/user/hadoop/delete/  
Found 1 items\  
drwxr-xr-x - hadoop hadoop 0 2015-05-08 12:39 .Trash/Current/user/hadoop/delete/test1 

因此文件test1進入垃圾箱并永久刪除文件test2。

減少副本系數

當一個文件的副本系數被減小后，NameNode會選擇過剩的副本刪除。下次心跳檢測時會將該信息傳遞給Datanode。Datanode遂即移除相應的數據塊，集群中的空閑空間加大。同樣，在調用setReplication API結束和集群中空閑空間增加間會有一定的延遲。