分布式文件系統HDFS解析

• • 設計目標
  • Namenode 和 Datanode
  • • HDFS HA
    • HDFS Federation
  • 讀寫流程
  • Replication
  • • 元數據
    • 副本均衡
    • 元數據磁盤錯誤
    • 快照
    • 流水線復制
  • 參考鏈接

---

HDFS作為分布式文件系統，主要是為了方便海量上層計算節點存取而設計的。提供posix api，將元數據（存放在NameNode）和數據（存放在DataNodes）分開存放。所有Node之間通過tcp通信。

設計目標

• 存儲非常大的文件：這里非常大指的是幾百M、G、或者TB級別。實際應用中已有很多集群存儲的數據達到PB級別。根據Hadoop官網，Yahoo！的Hadoop集群約有10萬顆CPU，運行在4萬個機器節點上。更多世界上的Hadoop集群使用情況，參考Hadoop官網.
• 采用流式的數據訪問方式: HDFS基于這樣的一個假設：最有效的數據處理模式是一次寫入、多次讀取數據集經常從數據源生成或者拷貝一次，然后在其上做很多分析工作
  分析工作經常讀取其中的大部分數據，即使不是全部。 因此讀取整個數據集所需時間比讀取第一條記錄的延時更重要。
• 運行于商業硬件上: Hadoop不需要特別貴的、reliable的機器，可運行于普通商用機器（可以從多家供應商采購） 商用機器不代表低端機器在集群中（尤其是大的集群），節點失敗率是比較高的HDFS的目標是確保集群在節點失敗的時候不會讓用戶感覺到明顯的中斷。
• 簡單的一致性模型：HDFS應用需要一個“一次寫入多次讀取”的文件訪問模型。一個文件經過創建、寫入和關閉之后就不需要改變。這一假設簡化了數據一致性問題，并且使高吞吐量的數據訪問成為可能。Map/Reduce應用或者網絡爬蟲應用都非常適合這個模型。目前還有計劃在將來擴充這個模型，使之支持文件的附加寫操作。

Namenode 和 Datanode

HDFS采用master/slave架構。一個HDFS集群是由一個Namenode和一定數目的Datanodes組成。Namenode是一個中心服務器，負責管理文件系統的名字空間(namespace)以及客戶端對文件的訪問。集群中的Datanode一般是一個節點一個，負責管理它所在節點上的存儲。HDFS暴露了文件系統的名字空間，用戶能夠以文件的形式在上面存儲數據。從內部看，一個文件其實被分成一個或多個數據塊，這些塊存儲在一組Datanode上。Namenode執行文件系統的名字空間操作，比如打開、關閉、重命名文件或目錄。它也負責確定數據塊到具體Datanode節點的映射。Datanode負責處理文件系統客戶端的讀寫請求。在Namenode的統一調度下進行數據塊的創建、刪除和復制。應用程序可以設置HDFS保存的文件的副本數目。文件副本的數目稱為文件的副本系數，這個信息也是由Namenode保存的。

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

NameNode管理著整個HDFS文件系統的元數據。從架構設計上看，元數據大致分成兩個層次：

Namespace管理層，負責管理文件系統中的樹狀目錄結構以及文件與數據塊的映射關系；

塊管理層，負責管理文件系統中文件的物理塊與實際存儲位置的映射關系BlocksMap

Namespace管理的元數據除內存常駐外，也會周期Flush到持久化設備上FsImage文件；BlocksMap元數據只在內存中存在；當NameNode發生重啟，首先從持久化設備中讀取FsImage構建Namespace，之后根據DataNode的匯報信息重新構造BlocksMap。這兩部分數據結構是占據了NameNode大部分JVM Heap空間。

除了對文件系統本身元數據的管理之外，NameNode還需要維護整個集群的機架及DataNode的信息、Lease管理以及集中式緩存引入的緩存管理等等。這幾部分數據結構空間占用相對固定，且占用較小。

測試數據顯示，Namespace目錄和文件總量到2億，數據塊總量到3億后，常駐內存使用量超過90GB。

HDFS HA

在Hadoop 1.x 中，Namenode是集群的單點故障，一旦Namenode出現故障，整個集群將不可用，重啟或者開啟一個新的Namenode才能夠從中恢復。

Hadoop HA（High Available）通過同時配置兩個處于Active/Passive模式的Namenode來解決上述問題，分別叫Active Namenode和Standby Namenode. Standby Namenode作為熱備份，從而允許在機器發生故障時能夠快速進行故障轉移，同時在日常維護的時候使用優雅的方式進行Namenode切換。Namenode只能配置一主一備，不能多于兩個Namenode。

實現方式主要有兩種：

使用NFS共享存儲edit log（存儲在NAS/SAN）

使用QJM（Quorum Journal Manager）edit log，使用Quorum+Zookeeper

當主備切換時，Standby通過回放edit log同步數據。

HDFS Federation

我們知道NameNode的內存會制約文件數量，HDFS Federation提供了一種橫向擴展NameNode的方式。在Federation模式中，每個NameNode管理命名空間的一部分，例如一個NameNode管理/user目錄下的文件， 另一個NameNode管理/share目錄下的文件。
每個NameNode管理一個namespace volumn，所有volumn構成文件系統的元數據。每個NameNode同時維護一個Block Pool，保存Block的節點映射等信息。各NameNode之間是獨立的，一個節點的失敗不會導致其他節點管理的文件不可用。
客戶端使用mount table將文件路徑映射到NameNode。mount table是在Namenode群組之上封裝了一層，這一層也是一個Hadoop文件系統的實現，通過viewfs:協議訪問。

讀寫流程

HDFS原生不支持追加寫，在HADOOP-8230后才支持最佳寫

Replication

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

HDFS的復制考慮了failure domain，使用稱為rack-aware的副本分布策略。

Namenode全權管理數據塊的復制，它周期性地從集群中的每個Datanode接收心跳信號和塊狀態報告(Blockreport)。接收到心跳信號意味著該Datanode節點工作正常。塊狀態報告包含了一個該Datanode上所有數據塊的列表。

由于數據一次寫入多次讀取，所以讀取時HDFS會盡量讓讀取程序讀取離它最近的副本。如果在讀取程序的同一個機架上有一個副本，那么就讀取該副本。如果一個HDFS集群跨越多個數據中心，那么客戶端也將首先讀本地數據中心的副本。

元數據

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

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

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

副本均衡

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

元數據磁盤錯誤

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

Namenode是HDFS集群中的單點故障(single point of failure)所在。

快照

HDFS 快照是從 Hadoop 2.1.0-beta 版本開始引入的新功能，詳見 HDFS-2802。

流水線復制

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

參考鏈接

Hadoop分布式文件系統：架構和設計

深入理解HDFS：Hadoop分布式文件系統

HDFS NameNode內存全景

HDFS 快照編程指南

Hadoop HDFS高可用（HA）

HDFS文件內容追加(Append)

總結

以上是生活随笔為你收集整理的分布式文件系统HDFS解析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。