Hadoop 分布式文件系統(tǒng)：架構和設計要點
原文：http://hadoop.apache.org/core/docs/current/hdfs_design.html
一、前提和設計目標
1 、硬件錯誤是常態(tài)，而非異常情況， HDFS 可能是有成百上千的 server 組成，任何一個組件都有可能一直失效，因此錯誤檢測和快速、自動的恢復是 HDFS 的核心架構目標。
2 、跑在 HDFS 上的應用與一般的應用不同，它們主要是以流式讀為主，做批量處理；比之關注數(shù)據(jù)訪問的低延遲問題，更關鍵的在于數(shù)據(jù)訪問的高吞吐量。
3 、 HDFS 以支持大數(shù)據(jù)集合為目標，一個存儲在上面的典型文件大小一般都在千兆至 T 字節(jié)，一個單一 HDFS 實例應該能支撐數(shù)以千萬計的文件。
4 、 HDFS 應用對文件要求的是 write-one-read-many 訪問模型。一個文件經過創(chuàng)建、寫，關閉之后就不需要改變。這一假設簡化了數(shù)據(jù)一致性問題，使高吞吐量的數(shù)據(jù)訪問成為可能。典型的如 MapReduce 框架，或者一個 web crawler 應用都很適合這個模型。
5 、移動計算的代價比之移動數(shù)據(jù)的代價低。一個應用請求的計算，離它操作的數(shù)據(jù)越近就越高效，這在數(shù)據(jù)達到海量級別的時候更是如此。將計算移動到數(shù)據(jù)附近，比之將數(shù)據(jù)移動到應用所在顯然更好， HDFS 提供給應用這樣的接口。
6 、在異構的軟硬件平臺間的可移植性。

二、 Namenode 和 Datanode
??? HDFS 采用 master/slave 架構。一個 HDFS 集群是有一個 Namenode 和一定數(shù)目的 Datanode 組成。 Namenode 是一個中心服務器，負責管理文件系統(tǒng)的 namespace 和客戶端對文件的訪問。 Datanode 在集群中一般是一個節(jié)點一個，負責管理節(jié)點上它們附帶的存儲。在內部，一個文件其實分成一個或多個 block ，這些 block 存儲在 Datanode 集合里。 Namenode 執(zhí)行文件系統(tǒng)的 namespace 操作，例如打開、關閉、重命名文件和目錄，同時決定 block 到具體 Datanode 節(jié)點的映射。 Datanode 在 Namenode 的指揮下進行 block 的創(chuàng)建、刪除和復制。 Namenode 和 Datanode 都是設計成可以跑在普通的廉價的運行 linux 的機器上。 HDFS 采用 java 語言開發(fā)，因此可以部署在很大范圍的機器上。一個典型的部署場景是一臺機器跑一個單獨的 Namenode 節(jié)點，集群中的其他機器各跑一個 Datanode 實例。這個架構并不排除一臺機器上跑多個 Datanode ，不過這比較少見。

單一節(jié)點的 Namenode 大大簡化了系統(tǒng)的架構。 Namenode 負責保管和管理所有的 HDFS 元數(shù)據(jù)，因而用戶數(shù)據(jù)就不需要通過 Namenode （也就是說文件數(shù)據(jù)的讀寫是直接在 Datanode 上）。

三、文件系統(tǒng)的 namespace
?? HDFS 支持傳統(tǒng)的層次型文件組織，與大多數(shù)其他文件系統(tǒng)類似，用戶可以創(chuàng)建目錄，并在其間創(chuàng)建、刪除、移動和重命名文件。 HDFS 不支持 user quotas 和訪問權限，也不支持鏈接（ link) ，不過當前的架構并不排除實現(xiàn)這些特性。 Namenode 維護文件系統(tǒng)的 namespace ，任何對文件系統(tǒng) namespace 和文件屬性的修改都將被 Namenode 記錄下來。應用可以設置 HDFS 保存的文件的副本數(shù)目，文件副本的數(shù)目稱為文件的 replication 因子，這個信息也是由 Namenode 保存。

四、數(shù)據(jù)復制
??? HDFS 被設計成在一個大集群中可以跨機器地可靠地存儲海量的文件。它將每個文件存儲成 block 序列，除了最后一個 block ，所有的 block 都是同樣的大小。文件的所有 block 為了容錯都會被復制。每個文件的 block 大小和 replication 因子都是可配置的。 Replication 因子可以在文件創(chuàng)建的時候配置，以后也可以改變。 HDFS 中的文件是 write-one ，并且嚴格要求在任何時候只有一個 writer 。 Namenode 全權管理 block 的復制，它周期性地從集群中的每個 Datanode 接收心跳包和一個 Blockreport 。心跳包的接收表示該 Datanode 節(jié)點正常工作，而 Blockreport 包括了該 Datanode 上所有的 block 組成的列表。

1 、副本的存放，副本的存放是 HDFS 可靠性和性能的關鍵。 HDFS 采用一種稱為 rack-aware 的策略來改進數(shù)據(jù)的可靠性、有效性和網絡帶寬的利用。這個策略實現(xiàn)的短期目標是驗證在生產環(huán)境下的表現(xiàn)，觀察它的行為，構建測試和研究的基礎，以便實現(xiàn)更先進的策略。龐大的 HDFS 實例一般運行在多個機架的計算機形成的集群上，不同機架間的兩臺機器的通訊需要通過交換機，顯然通常情況下，同一個機架內的兩個節(jié)點間的帶寬會比不同機架間的兩臺機器的帶寬大。
??? 通過一個稱為 Rack Awareness 的過程， Namenode 決定了每個 Datanode 所屬的 rack id 。一個簡單但沒有優(yōu)化的策略就是將副本存放在單獨的機架上。這樣可以防止整個機架（非副本存放）失效的情況，并且允許讀數(shù)據(jù)的時候可以從多個機架讀取。這個簡單策略設置可以將副本分布在集群中，有利于組件失敗情況下的負載均衡。但是，這個簡單策略加大了寫的代價，因為一個寫操作需要傳輸 block 到多個機架。
??? 在大多數(shù)情況下， replication 因子是 3 ， HDFS 的存放策略是將一個副本存放在本地機架上的節(jié)點，一個副本放在同一機架上的另一個節(jié)點，最后一個副本放在不同機架上的一個節(jié)點。機架的錯誤遠遠比節(jié)點的錯誤少，這個策略不會影響到數(shù)據(jù)的可靠性和有效性。三分之一的副本在一個節(jié)點上，三分之二在一個機架上，其他保存在剩下的機架中，這一策略改進了寫的性能。

2 、副本的選擇，為了降低整體的帶寬消耗和讀延時， HDFS 會盡量讓 reader 讀最近的副本。如果在 reader 的同一個機架上有一個副本，那么就讀該副本。如果一個 HDFS 集群跨越多個數(shù)據(jù)中心，那么 reader 也將首先嘗試讀本地數(shù)據(jù)中心的副本。

3 、 SafeMode
??? Namenode 啟動后會進入一個稱為 SafeMode 的特殊狀態(tài)，處在這個狀態(tài)的 Namenode 是不會進行數(shù)據(jù)塊的復制的。 Namenode 從所有的 Datanode 接收心跳包和 Blockreport 。 Blockreport 包括了某個 Datanode 所有的數(shù)據(jù)塊列表。每個 block 都有指定的最小數(shù)目的副本。當 Namenode 檢測確認某個 Datanode 的數(shù)據(jù)塊副本的最小數(shù)目，那么該 Datanode 就會被認為是安全的；如果一定百分比（這個參數(shù)可配置）的數(shù)據(jù)塊檢測確認是安全的，那么 Namenode 將退出 SafeMode 狀態(tài)，接下來它會確定還有哪些數(shù)據(jù)塊的副本沒有達到指定數(shù)目，并將這些 block 復制到其他 Datanode 。

五、文件系統(tǒng)元數(shù)據(jù)的持久化
??? Namenode 存儲 HDFS 的元數(shù)據(jù)。對于任何對文件元數(shù)據(jù)產生修改的操作， Namenode 都使用一個稱為 Editlog 的事務日志記錄下來。例如，在 HDFS 中創(chuàng)建一個文件， Namenode 就會在 Editlog 中插入一條記錄來表示；同樣，修改文件的 replication 因子也將往 Editlog 插入一條記錄。 Namenode 在本地 OS 的文件系統(tǒng)中存儲這個 Editlog 。整個文件系統(tǒng)的 namespace ，包括 block 到文件的映射、文件的屬性，都存儲在稱為 FsImage 的文件中，這個文件也是放在 Namenode 所在系統(tǒng)的文件系統(tǒng)上。
??? Namenode 在內存中保存著整個文件系統(tǒng) namespace 和文件 Blockmap 的映像。這個關鍵的元數(shù)據(jù)設計得很緊湊，因而一個帶有 4G 內存的 Namenode 足夠支撐海量的文件和目錄。當 Namenode 啟動時，它從硬盤中讀取 Editlog 和 FsImage ，將所有 Editlog 中的事務作用（ apply) 在內存中的 FsImage ，并將這個新版本的 FsImage 從內存中 flush 到硬盤上 , 然后再 truncate 這個舊的 Editlog ，因為這個舊的 Editlog 的事務都已經作用在 FsImage 上了。這個過程稱為 checkpoint 。在當前實現(xiàn)中， checkpoint 只發(fā)生在 Namenode 啟動時，在不久的將來我們將實現(xiàn)支持周期性的 checkpoint 。
??? Datanode 并不知道關于文件的任何東西，除了將文件中的數(shù)據(jù)保存在本地的文件系統(tǒng)上。它把每個 HDFS 數(shù)據(jù)塊存儲在本地文件系統(tǒng)上隔離的文件中。 Datanode 并不在同一個目錄創(chuàng)建所有的文件，相反，它用啟發(fā)式地方法來確定每個目錄的最佳文件數(shù)目，并且在適當?shù)臅r候創(chuàng)建子目錄。在同一個目錄創(chuàng)建所有的文件不是最優(yōu)的選擇，因為本地文件系統(tǒng)可能無法高效地在單一目錄中支持大量的文件。當一個 Datanode 啟動時，它掃描本地文件系統(tǒng)，對這些本地文件產生相應的一個所有 HDFS 數(shù)據(jù)塊的列表，然后發(fā)送報告到 Namenode ，這個報告就是 Blockreport 。

六、通訊協(xié)議
??? 所有的 HDFS 通訊協(xié)議都是構建在 TCP/IP 協(xié)議上。客戶端通過一個可配置的端口連接到 Namenode ，通過 ClientProtocol 與 Namenode 交互。而 Datanode 是使用 DatanodeProtocol 與 Namenode 交互。從 ClientProtocol 和 Datanodeprotocol 抽象出一個遠程調用 (RPC ），在設計上， Namenode 不會主動發(fā)起 RPC ，而是是響應來自客戶端和 Datanode 的 RPC 請求。

七、健壯性
??? HDFS 的主要目標就是實現(xiàn)在失敗情況下的數(shù)據(jù)存儲可靠性。常見的三種失敗： Namenode failures, Datanode failures 和網絡分割（ network partitions) 。
1 、硬盤數(shù)據(jù)錯誤、心跳檢測和重新復制
??? 每個 Datanode 節(jié)點都向 Namenode 周期性地發(fā)送心跳包。網絡切割可能導致一部分 Datanode 跟 Namenode 失去聯(lián)系。 Namenode 通過心跳包的缺失檢測到這一情況，并將這些 Datanode 標記為 dead ，不會將新的 IO 請求發(fā)給它們。寄存在 dead Datanode 上的任何數(shù)據(jù)將不再有效。 Datanode 的死亡可能引起一些 block 的副本數(shù)目低于指定值， Namenode 不斷地跟蹤需要復制的 block ，在任何需要的情況下啟動復制。在下列情況可能需要重新復制：某個 Datanode 節(jié)點失效，某個副本遭到損壞， Datanode 上的硬盤錯誤，或者文件的 replication 因子增大。

2 、集群均衡
?? HDFS 支持數(shù)據(jù)的均衡計劃，如果某個 Datanode 節(jié)點上的空閑空間低于特定的臨界點，那么就會啟動一個計劃自動地將數(shù)據(jù)從一個 Datanode 搬移到空閑的 Datanode 。當對某個文件的請求突然增加，那么也可能啟動一個計劃創(chuàng)建該文件新的副本，并分布到集群中以滿足應用的要求。這些均衡計劃目前還沒有實現(xiàn)。

3 、數(shù)據(jù)完整性
? 從某個 Datanode 獲取的數(shù)據(jù)塊有可能是損壞的，這個損壞可能是由于 Datanode 的存儲設備錯誤、網絡錯誤或者軟件 bug 造成的。 HDFS 客戶端軟件實現(xiàn)了 HDFS 文件內容的校驗和。當某個客戶端創(chuàng)建一個新的 HDFS 文件，會計算這個文件每個 block 的校驗和，并作為一個單獨的隱藏文件保存這些校驗和在同一個 HDFS namespace 下。當客戶端檢索文件內容，它會確認從 Datanode 獲取的數(shù)據(jù)跟相應的校驗和文件中的校驗和是否匹配，如果不匹配，客戶端可以選擇從其他 Datanode 獲取該 block 的副本。

4 、元數(shù)據(jù)磁盤錯誤
??? FsImage 和 Editlog 是 HDFS 的核心數(shù)據(jù)結構。這些文件如果損壞了，整個 HDFS 實例都將失效。因而， Namenode 可以配置成支持維護多個 FsImage 和 Editlog 的拷貝。任何對 FsImage 或者 Editlog 的修改，都將同步到它們的副本上。這個同步操作可能會降低 Namenode 每秒能支持處理的 namespace 事務。這個代價是可以接受的，因為 HDFS 是數(shù)據(jù)密集的，而非元數(shù)據(jù)密集。當 Namenode 重啟的時候，它總是選取最近的一致的 FsImage 和 Editlog 使用。
?? Namenode 在 HDFS 是單點存在，如果 Namenode 所在的機器錯誤，手工的干預是必須的。目前，在另一臺機器上重啟因故障而停止服務的 Namenode 這個功能還沒實現(xiàn)。

5 、快照
?? 快照支持某個時間的數(shù)據(jù)拷貝，當 HDFS 數(shù)據(jù)損壞的時候，可以恢復到過去一個已知正確的時間點。 HDFS 目前還不支持快照功能。

八、數(shù)據(jù)組織
1 、數(shù)據(jù)塊
??? 兼容 HDFS 的應用都是處理大數(shù)據(jù)集合的。這些應用都是寫數(shù)據(jù)一次，讀卻是一次到多次，并且讀的速度要滿足流式讀。 HDFS 支持文件的 write- once-read-many 語義。一個典型的 block 大小是 64MB ，因而，文件總是按照 64M 切分成 chunk ，每個 chunk 存儲于不同的 Datanode
2 、步驟
??? 某個客戶端創(chuàng)建文件的請求其實并沒有立即發(fā)給 Namenode ，事實上， HDFS 客戶端會將文件數(shù)據(jù)緩存到本地的一個臨時文件。應用的寫被透明地重定向到這個臨時文件。當這個臨時文件累積的數(shù)據(jù)超過一個 block 的大小（默認 64M) ，客戶端才會聯(lián)系 Namenode 。 Namenode 將文件名插入文件系統(tǒng)的層次結構中，并且分配一個數(shù)據(jù)塊給它，然后返回 Datanode 的標識符和目標數(shù)據(jù)塊給客戶端。客戶端將本地臨時文件 flush 到指定的 Datanode 上。當文件關閉時，在臨時文件中剩余的沒有 flush 的數(shù)據(jù)也會傳輸?shù)街付ǖ? Datanode ，然后客戶端告訴 Namenode 文件已經關閉。此時 Namenode 才將文件創(chuàng)建操作提交到持久存儲。如果 Namenode 在文件關閉前掛了，該文件將丟失。
?? 上述方法是對通過對 HDFS 上運行的目標應用認真考慮的結果。如果不采用客戶端緩存，由于網絡速度和網絡堵塞會對吞估量造成比較大的影響。

3 、流水線復制
??? 當某個客戶端向 HDFS 文件寫數(shù)據(jù)的時候，一開始是寫入本地臨時文件，假設該文件的 replication 因子設置為 3 ，那么客戶端會從 Namenode 獲取一張 Datanode 列表來存放副本。然后客戶端開始向第一個 Datanode 傳輸數(shù)據(jù)，第一個 Datanode 一小部分一小部分（ 4kb) 地接收數(shù)據(jù)，將每個部分寫入本地倉庫，并且同時傳輸該部分到第二個 Datanode 節(jié)點。第二個 Datanode 也是這樣，邊收邊傳，一小部分一小部分地收，存儲在本地倉庫，同時傳給第三個 Datanode ，第三個 Datanode 就僅僅是接收并存儲了。這就是流水線式的復制。

九、可訪問性
??? HDFS 給應用提供了多種訪問方式，可以通過 DFSShell 通過命令行與 HDFS 數(shù)據(jù)進行交互，可以通過 java API 調用，也可以通過 C 語言的封裝 API 訪問，并且提供了瀏覽器訪問的方式。正在開發(fā)通過 WebDav 協(xié)議訪問的方式。具體使用參考文檔。
十、空間的回收
1 、文件的刪除和恢復
??? 用戶或者應用刪除某個文件，這個文件并沒有立刻從 HDFS 中刪除。相反， HDFS 將這個文件重命名，并轉移到 /trash 目錄。當文件還在 /trash 目錄時，該文件可以被迅速地恢復。文件在 /trash 中保存的時間是可配置的，當超過這個時間， Namenode 就會將該文件從 namespace 中刪除。文件的刪除，也將釋放關聯(lián)該文件的數(shù)據(jù)塊。注意到，在文件被用戶刪除和 HDFS 空閑空間的增加之間會有一個等待時間延遲。
??? 當被刪除的文件還保留在 /trash 目錄中的時候，如果用戶想恢復這個文件，可以檢索瀏覽 /trash 目錄并檢索該文件。 /trash 目錄僅僅保存被刪除文件的最近一次拷貝。 /trash 目錄與其他文件目錄沒有什么不同，除了一點： HDFS 在該目錄上應用了一個特殊的策略來自動刪除文件，目前的默認策略是刪除保留超過 6 小時的文件，這個策略以后會定義成可配置的接口。

2 、 Replication 因子的減小
??? 當某個文件的 replication 因子減小， Namenode 會選擇要刪除的過剩的副本。下次心跳檢測就將該信息傳遞給 Datanode ， Datanode 就會移除相應的 block 并釋放空間，同樣，在調用 setReplication 方法和集群中的空閑空間增加之間會有一個時間延遲。

參考資料：
HDFS Java API: http://hadoop.apache.org/core/docs/current/api/
HDFS source code: http://hadoop.apache.org/core/version_control.html
???

Hadoop分布式文件系統(tǒng)：架構和設計要點