HDFS (Hadoop Distributed File System)是Hadoop下的分佈式文件系統,具備高容錯、高吞吐量等特性,能夠部署在低成本的硬件上。html
HDFS 遵循主/從架構,由單個NameNode(NN)和多個DataNode(DN)組成:node
文件系統命名空間
的操做,例如打開,關閉、重命名文件和目錄等。它同時還負責集羣元數據的存儲,記錄着文件中各個數據塊的位置信息。HDFS的文件系統命名空間
的層次結構與大多數文件系統相似(如Linux), 支持目錄和文件的建立、移動、刪除和重命名等操做,支持配置用戶和訪問權限,但不支持硬連接和軟鏈接。NameNode
負責維護文件系統名稱空間,記錄對名稱空間或其屬性的任何更改。git
因爲Hadoop被設計運行在廉價的機器上,這意味着硬件是不可靠的,爲了保證容錯性,HDFS提供了數據複製機制。HDFS 將每個文件存儲爲一系列塊,每一個塊由多個副原本保證容錯,塊的大小和複製因子能夠自行配置(默認狀況下,塊大小是128M,默認複製因子是3)。github
大型的HDFS實例在一般分佈在多個機架的多臺服務器上,不一樣機架上的兩臺服務器之間經過交換機進行通信。在大多數狀況下,同一機架中的服務器間的網絡帶寬大於不一樣機架中的服務器之間的帶寬。所以HDFS採用機架感知副本放置策略,對於常見狀況,當複製因子爲3時,HDFS的放置策略是:apache
在寫入程序位於datanode
上時,就優先將寫入文件的一個副本放置在該datanode
上,不然放在隨機datanode
上。以後在另外一個遠程機架上的任意一個節點上放置另外一個副本,並在該機架上的另外一個節點上放置最後一個副本。此策略能夠減小機架間的寫入流量,從而提升寫入性能。服務器
若是複製因子大於3,則隨機肯定第4個和以後副本的放置位置,同時保持每一個機架的副本數量低於上限,上限值一般爲(複製係數 - 1)/機架數量 + 2
,須要注意的是不容許同一個dataNode
上具備同一個塊的多個副本。網絡
爲了最大限度地減小帶寬消耗和讀取延遲,HDFS在執行讀取請求時,優先讀取距離讀取器最近的副本。若是在與讀取器節點相同的機架上存在副本,則優先選擇該副本。若是HDFS羣集跨越多個數據中心,則優先選擇本地數據中心上的副本。架構
每一個DataNode按期向NameNode發送心跳消息,若是超過指定時間沒有收到心跳消息,則將DataNode標記爲死亡。NameNode不會將任何新的IO請求轉發給標記爲死亡的DataNode,也不會再使用這些DataNode上的數據。 因爲數據再也不可用,可能會致使某些塊的複製因子小於其指定值,NameNode會跟蹤這些塊,並在必要的時候進行從新複製。框架
因爲存儲設備故障等緣由,存儲在DataNode上的數據塊也會發生損壞。爲了不讀取到已經損壞的數據而致使錯誤,HDFS提供了數據完整性校驗機制來保證數據的完整性,具體操做以下:分佈式
當客戶端建立HDFS文件時,它會計算文件的每一個塊的校驗和
,並將校驗和
存儲在同一HDFS命名空間下的單獨的隱藏文件中。當客戶端檢索文件內容時,它會驗證從每一個DataNode接收的數據是否與存儲在關聯校驗和文件中的校驗和
匹配。若是匹配失敗,則證實數據已經損壞,此時客戶端會選擇從其餘DataNode獲取該塊的其餘可用副本。
FsImage
和EditLog
是HDFS的核心數據,這些數據的意外丟失可能會致使整個HDFS服務不可用。爲了不這個問題,能夠配置NameNode使其支持FsImage
和EditLog
多副本同步,這樣FsImage
或EditLog
的任何改變都會引發每一個副本FsImage
和EditLog
的同步更新。
快照支持在特定時刻存儲數據副本,在數據意外損壞時,能夠經過回滾操做恢復到健康的數據狀態。
因爲HDFS 採用數據的多副本方案,因此部分硬件的損壞不會致使所有數據的丟失。
HDFS設計的重點是支持高吞吐量的數據訪問,而不是低延遲的數據訪問。
HDFS適合於大文件的存儲,文檔的大小應該是是GB到TB級別的。
HDFS更適合於一次寫入屢次讀取(write-once-read-many)的訪問模型。支持將內容追加到文件末尾,但不支持數據的隨機訪問,不能從文件任意位置新增數據。
HDFS具備良好的跨平臺移植性,這使得其餘大數據計算框架都將其做爲數據持久化存儲的首選方案。
說明:如下圖片引用自博客:翻譯經典 HDFS 原理講解漫畫
第二部分:讀寫故障的處理
第三部分:DataNode故障處理
副本佈局策略:
更多大數據系列文章能夠參見我的 GitHub 開源項目: 大數據入門指南