Hadoop 三劍客之 —— 分散式檔案儲存系統 HDFS

單人影發表於2019-06-26

Hadoop分散式

一、介紹

HDFS （Hadoop Distributed File System）是Hadoop下的分散式檔案系統，具有高容錯、高吞吐量等特性，可以部署在低成本的硬體上。

二、HDFS 設計原理

2.1 HDFS 架構

HDFS 遵循主/從架構，由單個NameNode(NN)和多個DataNode(DN)組成：

NameNode : 負責執行有關檔案系統名稱空間的操作，例如開啟，關閉、重新命名檔案和目錄等。它同時還負責叢集後設資料的儲存，記錄著檔案中各個資料塊的位置資訊。
DataNode：負責提供來自檔案系統客戶端的讀寫請求，執行塊的建立，刪除等操作。

2.2 檔案系統名稱空間

HDFS的檔案系統名稱空間的層次結構與大多數檔案系統類似(如Linux)，支援目錄和檔案的建立、移動、刪除和重新命名等操作，支援配置使用者和訪問許可權，但不支援硬連結和軟連線。NameNode負責維護檔案系統名稱空間，記錄對名稱空間或其屬性的任何更改。

2.3 資料複製

由於Hadoop被設計執行在廉價的機器上，這意味著硬體是不可靠的，為了保證容錯性，HDFS提供了資料複製機制。HDFS 將每一個檔案儲存為一系列塊，每個塊由多個副本來保證容錯，塊的大小和複製因子可以自行配置（預設情況下，塊大小是128M，預設複製因子是3）。

2.4 資料複製的實現原理

大型的HDFS例項在通常分佈在多個機架的多臺伺服器上，不同機架上的兩臺伺服器之間通過交換機進行通訊。在大多數情況下，同一機架中的伺服器間的網路頻寬大於不同機架中的伺服器之間的頻寬。因此HDFS採用機架感知副本放置策略，對於常見情況，當複製因子為3時，HDFS的放置策略是：

在寫入程式位於datanode上時，就優先將寫入檔案的一個副本放置在該datanode上，否則放在隨機datanode上。之後在另一個遠端機架上的任意一個節點上放置另一個副本，並在該機架上的另一個節點上放置最後一個副本。此策略可以減少機架間的寫入流量，從而提高寫入效能。

如果複製因子大於3，則隨機確定第4個和之後副本的放置位置，同時保持每個機架的副本數量低於上限，上限值通常為（複製係數 - 1）/機架數量 + 2，需要注意的是不允許同一個dataNode上具有同一個塊的多個副本。

2.5 副本的選擇

為了最大限度地減少頻寬消耗和讀取延遲，HDFS在執行讀取請求時，優先讀取距離讀取器最近的副本。如果在與讀取器節點相同的機架上存在副本，則優先選擇該副本。如果HDFS群集跨越多個資料中心，則優先選擇本地資料中心上的副本。

2.6 架構的穩定性

1. 心跳機制和重新複製

每個DataNode定期向NameNode傳送心跳訊息，如果超過指定時間沒有收到心跳訊息，則將DataNode標記為死亡。NameNode不會將任何新的IO請求轉發給標記為死亡的DataNode，也不會再使用這些DataNode上的資料。由於資料不再可用，可能會導致某些塊的複製因子小於其指定值，NameNode會跟蹤這些塊，並在必要的時候進行重新複製。

2. 資料的完整性

由於儲存裝置故障等原因，儲存在DataNode上的資料塊也會發生損壞。為了避免讀取到已經損壞的資料而導致錯誤，HDFS提供了資料完整性校驗機制來保證資料的完整性，具體操作如下：

當客戶端建立HDFS檔案時，它會計算檔案的每個塊的校驗和，並將校驗和儲存在同一HDFS名稱空間下的單獨的隱藏檔案中。當客戶端檢索檔案內容時，它會驗證從每個DataNode接收的資料是否與儲存在關聯校驗和檔案中的校驗和匹配。如果匹配失敗，則證明資料已經損壞，此時客戶端會選擇從其他DataNode獲取該塊的其他可用副本。

3.後設資料的磁碟故障

FsImage和EditLog是HDFS的核心資料，這些資料的意外丟失可能會導致整個HDFS服務不可用。為了避免這個問題，可以配置NameNode使其支援FsImage和EditLog多副本同步，這樣FsImage或EditLog的任何改變都會引起每個副本FsImage和EditLog的同步更新。