Hadoop分布式文件系統設計要點與架構
發佈時間:2012-8-12Hadoop簡介：一個分布式系統基礎架構，由Apache基金會開發。用戶可以在不了解分布式底層細節的情況下，開發分布式程序。充分利用集群的威力高速運算和存儲。Hadoop實現了一個分布式文件系統（Hadoop Distributed File System），簡稱HDFS。HDFS有着高容錯性的特點，并且設計用來部署在低廉的（low-cost）硬件上。而且它提供高傳輸率（high throughput）來訪問應用程序的數據，适合那些有着超大數據集（large data set）的應用程序。HDFS放寬了（relax）POSIX的要求（requirements）這樣可以流的形式訪問（streaming access）文件系統中的數據。
Hadoop官網：http://hadoop.apache.org/
Hadoop中文文檔：http://hadoop.apache.org/common/docs/r0.21.0/cn/
一、前提和設計目标
1、硬件錯誤是常态，而非異常情況，HDFS可能是有成百上千的server組成，任何一個組件都有可能一直失效，因此錯誤檢測和快速、自動的恢複是HDFS的核心架構目标。
2、跑在HDFS上的應用與一般的應用不同，它們主要是以流式讀爲主，做批量處理；比之關注數據訪問的低延遲問題，更關鍵的在于數據訪問的高吞吐量。
3、HDFS以支持大數據集合爲目标，一個存儲在上面的典型文件大小一般都在千兆至T字節，一個單一HDFS實例應該能支撐數以千萬計的文件。
4、 HDFS應用對文件要求的是write-one-read-many訪問模型。一個文件經過創建、寫，關閉之後就不需要改變。這一假設簡化了數據一緻性問 題，使高吞吐量的數據訪問成爲可能。典型的如MapReduce框架，或者一個web crawler應用都很适合這個模型。
5、移動計算的代價比之移動數據的代價低。一個應用請求的計算，離它操作的數據越近就越高效，這在數據達到海量級别的時候更是如此。将計算移動到數據附近，比之将數據移動到應用所在顯然更好，HDFS提供給應用這樣的接口。
6、在異構的軟硬件平台間的可移植性。
二、Namenode和Datanode
HDFS采用master/slave架構。一個HDFS集群是有一個Namenode和一定數目的Datanode組成。Namenode是一個中心服 務器，負責管理文件系統的namespace和客戶端對文件的訪問。Datanode在集群中一般是一個節點一個，負責管理節點上它們附帶的存儲。在内 部，一個文件其實分成一個或多個block，這些block存儲在Datanode集合裏。Namenode執行文件系統的namespace操作，例如 打開、關閉、重命名文件和目錄，同時決定block到具體Datanode節點的映射。Datanode在Namenode的指揮下進行block的創 建、删除和複制。Namenode和Datanode都是設計成可以跑在普通的廉價的運行linux的機器上。HDFS采用java語言開發，因此可以部 署在很大範圍的機器上。一個典型的部署場景是一台機器跑一個單獨的Namenode節點，集群中的其他機器各跑一個Datanode實例。這個架構并不排 除一台機器上跑多個Datanode，不過這比較少見。
單一節點的Namenode大大簡化了系統的架構。Namenode負責保管和管理所有的HDFS元數據，因而用戶數據就不需要通過Namenode（也就是說文件數據的讀寫是直接在Datanode上）。
三、文件系統的namespace
HDFS支持傳統的層次型文件組織，與大多數其他文件系統類似，用戶可以創建目錄，并在其間創建、删除、移動和重命名文件。HDFS不支持user quotas和訪問權限，也不支持鏈接（link)，不過當前的架構并不排除實現這些特性。Namenode維護文件系統的namespace，任何對文 件系統namespace和文件屬性的修改都将被Namenode記錄下來。應用可以設置HDFS保存的文件的副本數目，文件副本的數目稱爲文件的 replication因子，這個信息也是由Namenode保存。
四、數據複制
HDFS被設計成在一個大集群中可以跨機器地可靠地存儲海量的文件。它将每個文件存儲成block序列，除了最後一個block，所有的block都是同 樣的大小。文件的所有block爲了容錯都會被複制。每個文件的block大小和replication因子都是可配置的。Replication因子可 以在文件創建的時候配置，以後也可以改變。HDFS中的文件是write-one，并且嚴格要求在任何時候隻有一個writer。Namenode全權管 理block的複制，它周期性地從集群中的每個Datanode接收心跳包和一個Blockreport。心跳包的接收表示該Datanode節點正常工 作，而Blockreport包括了該Datanode上所有的block組成的列表。
1、副本的存放，副本的存放是HDFS可靠性和性能的關鍵。HDFS采用一種稱爲rack-aware的策略來改進數據的可靠性、有效性和網絡帶寬的利 用。這個策略實現的短期目标是驗證在生産環境下的表現，觀察它的行爲，構建測試和研究的基礎，以便實現更先進的策略。龐大的HDFS實例一般運行在多個機 架的計算機形成的集群上，不同機架間的兩台機器的通訊需要通過交換機，顯然通常情況下，同一個機架内的兩個節點間的帶寬會比不同機架間的兩台機器的帶寬大。
通過一個稱爲Rack Awareness的過程，Namenode決定了每個Datanode所屬的rack id。一個簡單但沒有優化的策略就是将副本存放在單獨的機架上。這樣可以防止整個機架（非副本存放）失效的情況，并且允許讀數據的時候可以從多個機架讀 取。這個簡單策略設置可以将副本分布在集群中，有利于組件失敗情況下的負載均衡。但是，這個簡單策略加大了寫的代價，因爲一個寫操作需要傳輸block到 多個機架。
在大多數情況下，replication因子是3，HDFS的存放策略是将一個副本存放在本地機架上的節點，一個副本放在同一機架上的另一個節點，最後一 個副本放在不同機架上的一個節點。機架的錯誤遠遠比節點的錯誤少，這個策略不會影響到數據的可靠性和有效性。三分之一的副本在一個節點上，三分之二在一個 機架上，其他保存在剩下的機架中，這一策略改進了寫的性能。
2、副本的選擇，爲了降低整體的帶寬消耗和讀延時，HDFS會盡量讓reader讀最近的副本。如果在reader的同一個機架上有一個副本，那麽就讀該副本。如果一個HDFS集群跨越多個數據中心，那麽reader也将首先嘗試讀本地數據中心的副本。
3、SafeMode
Namenode啓動後會進入一個稱爲SafeMode的特殊狀态，處在這個狀态的Namenode是不會進行數據塊的複制的。Namenode從所有的 Datanode接收心跳包和Blockreport。Blockreport包括了某個Datanode所有的數據塊列表。每個block都有指定的最 小數目的副本。當Namenode檢測确認某個Datanode的數據塊副本的最小數目，那麽該Datanode就會被認爲是安全的；如果一定百分比（這 個參數可配置）的數據塊檢測确認是安全的，那麽Namenode将退出SafeMode狀态，接下來它會确定還有哪些數據塊的副本沒有達到指定數目，并将 這些block複制到其他Datanode。
五、文件系統元數據的持久化
Namenode存儲HDFS的元數據。對于任何對文件元數據産生修改的操作，Namenode都使用一個稱爲Editlog的事務日志記錄下來。例如， 在HDFS中創建一個文件，Namenode就會在Editlog中插入一條記錄來表示；同樣，修改文件的replication因子也将往Editlog插入一條記錄。Namenode在本地OS的文件系統中存儲這個Editlog。整個文件系統的namespace，包括block到文件 的映射、文件的屬性，都存儲在稱爲FsImage的文件中，這個文件也是放在Namenode所在系統的文件系統上。
Namenode在内存中保存着整個文件系統namespace和文件Blockmap的映像。這個關鍵的元數據設計得很緊湊，因而一個帶有4G内存的 Namenode足夠支撐海量的文件和目錄。當Namenode啓動時，它從硬盤中讀取Editlog和FsImage，将所有Editlog中的事務作 用（apply)在内存中的FsImage ，并将這個新版本的FsImage從内存中flush到硬盤上,然後再truncate這個舊的Editlog，因爲這個舊的Editlog的事務都已經 作用在FsImage上了。這個過程稱爲checkpoint。在當前實現中，checkpoint隻發生在Namenode啓動時，在不久的将來我們将 實現支持周期性的checkpoint。
Datanode并不知道關于文件的任何東西，除了将文件中的數據保存在本地的文件系統上。它把每個HDFS數據塊存儲在本地文件系統上隔離的文件中。 Datanode并不在同一個目錄創建所有的文件，相反，它用啓發式地方法來确定每個目錄的最佳文件數目，并且在适當的時候創建子目錄。在同一個目錄創建 所有的文件不是最優的選擇，因爲本地文件系統可能無法高效地在單一目錄中支持大量的文件。當一個Datanode啓動時，它掃描本地文件系統，對這些本地 文件産生相應的一個所有HDFS數據塊的列表，然後發送報告到Namenode，這個報告就是Blockreport。
六、通訊協議
所有的HDFS通訊協議都是構建在TCP/IP協議上。客戶端通過一個可配置的端口連接到Namenode，通過ClientProtocol與Namenode交互。而Datanode是使用DatanodeProtocol與Namenode交互。從ClientProtocol和 Datanodeprotocol抽象出一個遠程調用(RPC），在設計上，Namenode不會主動發起RPC，而是是響應來自客戶端和 Datanode 的RPC請求。
七、健壯性
HDFS的主要目标就是實現在失敗情況下的數據存儲可靠性。常見的三種失敗：Namenode failures, Datanode failures和網絡分割（network partitions)。
1、硬盤數據錯誤、心跳檢測和重新複制
每個Datanode節點都向Namenode周期性地發送心跳包。網絡切割可能導緻一部分Datanode跟Namenode失去聯系。Namenode通過心跳包的缺失檢測到這一情況，并将這些Datanode标記爲dead，不會将新的IO請求發給它們。寄存在dead Datanode上的任何數據将不再有效。Datanode的死亡可能引起一些block的副本數目低于指定值，Namenode不斷地跟蹤需要複制的block，在任何需要的情況下啓動複制。在下列情況可能需要重新複制：某個Datanode節點失效，某個副本遭到損壞，Datanode上的硬盤錯 誤，或者文件的replication因子增大。
2、集群均衡
HDFS支持數據的均衡計劃，如果某個Datanode節點上的空閑空間低于特定的臨界點，那麽就會啓動一個計劃自動地将數據從一個Datanode搬移 到空閑的Datanode。當對某個文件的請求突然增加，那麽也可能啓動一個計劃創建該文件新的副本，并分布到集群中以滿足應用的要求。這些均衡計劃目前 還沒有實現。
3、數據完整性
從某個Datanode獲取的數據塊有可能是損壞的，這個損壞可能是由于Datanode的存儲設備錯誤、網絡錯誤或者軟件bug造成的。HDFS客戶端 軟件實現了HDFS文件内容的校驗和。當某個客戶端創建一個新的HDFS文件，會計算這個文件每個block的校驗和，并作爲一個單獨的隐藏文件保存這些 校驗和在同一個HDFS namespace下。當客戶端檢索文件内容，它會确認從Datanode獲取的數據跟相應的校驗和文件中的校驗和是否匹配，如果不匹配，客戶端可以選擇 從其他Datanode獲取該block的副本。
4、元數據磁盤錯誤
FsImage和Editlog是HDFS的核心數據結構。這些文件如果損壞了，整個HDFS實例都将失效。因而，Namenode可以配置成支持維護多 個FsImage和Editlog的拷貝。任何對FsImage或者Editlog的修改，都将同步到它們的副本上。這個同步操作可能會降低Namenode每秒能支持處理的namespace事務。這個代價是可以接受的，因爲HDFS是數據密集的，而非元數據密集。當Namenode重啓的 時候，它總是選取最近的一緻的FsImage和Editlog使用。
Namenode在HDFS是單點存在，如果Namenode所在的機器錯誤，手工的幹預是必須的。目前，在另一台機器上重啓因故障而停止服務的Namenode這個功能還沒實現。
5、快照
快照支持某個時間的數據拷貝，當HDFS數據損壞的時候，可以恢複到過去一個已知正确的時間點。HDFS目前還不支持快照功能。
八、數據組織
1、數據塊
兼容HDFS的應用都是處理大數據集合的。這些應用都是寫數據一次，讀卻是一次到多次，并且讀的速度要滿足流式讀。HDFS支持文件的write- once-read-many語義。一個典型的block大小是64MB，因而，文件總是按照64M切分成chunk，每個chunk存儲于不同的Datanode
2、步驟
某個客戶端創建文件的請求其實并沒有立即發給Namenode，事實上，HDFS客戶端會将文件數據緩存到本地的一個臨時文件。應用的寫被透明地重定向到 這個臨時文件。當這個臨時文件累積的數據超過一個block的大小（默認64M)，客戶端才會聯系Namenode。Namenode将文件名插入文件系 統的層次結構中，并且分配一個數據塊給它，然後返回Datanode的标識符和目标數據塊給客戶端。客戶端将本地臨時文件flush到指定的 Datanode上。當文件關閉時，在臨時文件中剩餘的沒有flush的數據也會傳輸到指定的Datanode，然後客戶端告訴Namenode文件已經 關閉。此時Namenode才将文件創建操作提交到持久存儲。如果Namenode在文件關閉前挂了，該文件将丢失。
上述方法是對通過對HDFS上運行的目标應用認真考慮的結果。如果不采用客戶端緩存，由于網絡速度和網絡堵塞會對吞估量造成比較大的影響。
3、流水線複制
當某個客戶端向HDFS文件寫數據的時候，一開始是寫入本地臨時文件，假設該文件的replication因子設置爲3，那麽客戶端會從Namenode 獲取一張Datanode列表來存放副本。然後客戶端開始向第一個Datanode傳輸數據，第一個Datanode一小部分一小部分（4kb)地接收數 據，将每個部分寫入本地倉庫，并且同時傳輸該部分到第二個Datanode節點。第二個Datanode也是這樣，邊收邊傳，一小部分一小部分地收，存儲 在本地倉庫，同時傳給第三個Datanode，第三個Datanode就僅僅是接收并存儲了。這就是流水線式的複制。
九、可訪問性
HDFS給應用提供了多種訪問方式，可以通過DFSShell通過命令行與HDFS數據進行交互，可以通過java API調用，也可以通過C語言的封裝API訪問，并且提供了浏覽器訪問的方式。正在開發通過WebDav協議訪問的方式。具體使用參考文檔。
十、空間的回收
1、文件的删除和恢複
用戶或者應用删除某個文件，這個文件并沒有立刻從HDFS中删除。相反，HDFS将這個文件重命名，并轉移到/trash目錄。當文件還在/trash目 錄時，該文件可以被迅速地恢複。文件在/trash中保存的時間是可配置的，當超過這個時間，Namenode就會将該文件從namespace中删除。 文件的删除，也将釋放關聯該文件的數據塊。注意到，在文件被用戶删除和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 源碼: http://hadoop.apache.org/core/version_control.html
原文：http://hadoop.apache.org/core/docs/current/hdfs_design.html
翻譯：http://hadoop.apache.org/common/docs/r0.21.0/cn/hdfs_design.html
【返回】
