3分佈式文件系統HDFS

3.1分佈式文件系統

3.1.1計算機集羣結構

分佈式文件系統把文件分佈存儲到多個計算機節點上，成千上萬的計算機節點構成計算機集羣。

與以前使用多個處理器和專用高級硬件的並行化處理裝置不一樣的是，目前的分佈式文件系統所採用的計算機集羣，都由普通硬件構成的，這就大大下降了硬件上的開銷

 

3.1.2分佈式文件系統的結構

分佈式文件系統在物理結構上是由計算機集羣中的多個節點構成的，這些節點分爲兩類，一類叫「主節點」（Master Node）或者也被稱爲「名稱節點」（NameNode），另外一類叫「從節點」（Slave Node）或者也被稱爲「數據節點」（DataNode）

 

3.2HDFS簡介

整體而言，HDFS要實現如下目標：

• 兼容廉價的硬件設備
• 流數據讀寫
• 大數據集
• 簡單的文件模型
• 強大的跨平臺兼容性

HDFS特殊的設計，在實現上述優良特性的同時，也使得自身具備一些應用侷限性，主要包括如下幾個方面：

• 不適合低延遲數據訪問
• 沒法高效存儲大量小文件
• 不支持多用戶寫入及任意修改文件

 

3.3HDFS相關概念

 3.3.1塊

HDFS默認一個塊64MB，一個文件被分紅多個塊，以塊做爲存儲單位

塊的大小遠遠大於普通文件系統，能夠最小化尋址開銷

HDFS採用抽象的塊概念能夠帶來如下幾個明顯的好處：

支持大規模文件存儲：文件以塊爲單位進行存儲，一個大規模文件能夠被分拆成若干個文件塊，不一樣的文件塊能夠被分發到不一樣的節點上，所以，一個文件的大小不會受到單個節點的存儲容量的限制，能夠遠遠大於網絡中任意節點的存儲容量。

簡化系統設計：首先，大大簡化了存儲管理，由於文件塊大小是固定的，這樣就能夠很容易計算出一個節點能夠存儲多少文件塊；其次，方便了元數據的管理，元數據不須要和文件塊一塊兒存儲，能夠由其餘系統負責管理元數據。

適合數據備份：每一個文件塊均可以冗餘存儲到多個節點上，大大提升了系統的容錯性和可用性。

3.3.2名稱節點和數據節點

NameNode	DataNode
存儲元數據	存儲文件內容
元數據保存在內存中	文件內容保存在磁盤
保存文件block，datanode之間的映射關係	維護了block id到datanode本地文件的映射關係

名稱節點的數據結構

在HDFS中，名稱節點（NameNode）負責管理分佈式文件系統的命名空間（Namespace），保存了兩個核心的數據結構，即FsImage和EditLog

FsImage用於維護文件系統樹以及文件樹中全部的文件和文件夾元數據

操做日誌文件EditLog中記錄了全部針對文件的建立、刪除、重命名等操做

名稱節點記錄了每一個文件中各個塊所在的數據節點的位置信息

FsImage文件

FsImage文件包含文件系統中全部目錄和文件inode的序列化形式。每一個inode是一個文件或目錄的元數據的內部表示，幷包含此類信息：文件的複製等級、修改和訪問時間、訪問權限、塊大小以及組成文件的塊。對於目錄，則存儲修改時間、權限和配額元數據。

FsImage文件沒有記錄塊存儲在哪一個數據節點。而是由名稱節點把這些映射保留在內存中，當數據節點加入HDFS集羣時，數據節點會把本身所包含的塊列表告知給名稱節點，此後會按期執行這種告知操做，以確保名稱節點的塊映射是最新的。

名稱節點的啓動

在名稱節點啓動的時候，它會將FsImage文件中的內容加載到內存中，以後再執行EditLog文件中的各項操做，使得內存中的元數據和實際的同步，存在內存中的元數據支持客戶端的讀操做。

一旦在內存中成功創建文件系統元數據的映射，則建立一個新的FsImage文件和一個空的EditLog文件。

名稱節點起來以後，HDFS中的更新操做會從新寫到EditLog文件中，由於FsImage文件通常都很大（GB級別的很常見），若是全部的更新操做都往FsImage文件中添加，這樣會致使系統運行的十分緩慢，可是，若是往EditLog文件裏面寫就不會這樣，由於EditLog 要小不少。每次執行寫操做以後，且在向客戶端發送成功代碼以前，edits文件都須要同步更新。

名稱節點運行期間EditLog不斷變大的問題

在名稱節點運行期間，HDFS的全部更新操做都是直接寫到EditLog中，長此以往， EditLog文件將會變得很大

雖然這對名稱節點運行時候是沒有什麼明顯影響的，可是，當名稱節點重啓的時候，名稱節點須要先將FsImage裏面的全部內容映像到內存中，而後再一條一條地執行EditLog中的記錄，當EditLog文件很是大的時候，會致使名稱節點啓動操做很是慢，而在這段時間內HDFS系統處於安全模式，一直沒法對外提供寫操做，影響了用戶的使用

         如何解決？答案是：SecondaryNameNode第二名稱節點

第二名稱節點是HDFS架構中的一個組成部分，它是用來保存名稱節點中對HDFS 元數據信息的備份，並減小名稱節點重啓的時間。SecondaryNameNode通常是單獨運行在一臺機器上

 

SecondaryNameNode的工做狀況：
　　（1）SecondaryNameNode會按期和NameNode通訊，請求其中止使用EditLog文件，暫時將新的寫操做寫到一個新的文件edit.new上來，這個操做是瞬間完成，上層寫日誌的函數徹底感受不到差異；
　　（2）SecondaryNameNode經過HTTP GET方式從NameNode上獲取到FsImage和EditLog文件，並下載到本地的相應目錄下；
　　（3）SecondaryNameNode將下載下來的FsImage載入到內存，而後一條一條地執行EditLog文件中的各項更新操做，使得內存中的FsImage保持最新；這個過程就是EditLog和FsImage文件合併；
　　（4）SecondaryNameNode執行完（3）操做以後，會經過post方式將新的FsImage文件發送到NameNode節點上；
　　（5）NameNode將從SecondaryNameNode接收到的新的FsImage替換舊的FsImage文件，同時將edit.new替換EditLog文件，經過這個過程EditLog就變小了。

數據節點（DataNode）

數據節點是分佈式文件系統HDFS的工做節點，負責數據的存儲和讀取，會根據客戶端或者是名稱節點的調度來進行數據的存儲和檢索，而且向名稱節點按期發送本身所存儲的塊的列表。

每一個數據節點中的數據會被保存在各自節點的本地Linux文件系統中。

 

3.4HDFS體系結構

3.4.1HDFS體系結構概述

 HDFS採用了主從（Master/Slave）結構模型，一個HDFS集羣包括一個名稱節點（NameNode）和若干個數據節點（DataNode）（如圖所示）。名稱節點做爲中心服務器，負責管理文件系統的命名空間及客戶端對文件的訪問。集羣中的數據節點通常是一個節點運行一個數據節點進程，負責處理文件系統客戶端的讀/寫請求，在名稱節點的統一調度下進行數據塊的建立、刪除和複製等操做。每一個數據節點的數據其實是保存在本地Linux文件系統中的。

 

3.4.2HDFS命名空間管理

 HDFS的命名空間包含目錄、文件和塊

在HDFS1.0體系結構中，在整個HDFS集羣中只有一個命名空間，而且只有惟一一個名稱節點，該節點負責對這個命名空間進行管理

HDFS使用的是傳統的分級文件體系，所以，用戶能夠像使用普通文件系統同樣，建立、刪除目錄和文件，在目錄間轉移文件，重命名文件等

3.4.3通訊協議

 HDFS是一個部署在集羣上的分佈式文件系統，所以，不少數據須要經過網絡進行傳輸

全部的HDFS通訊協議都是構建在TCP/IP協議基礎之上的

客戶端經過一個可配置的端口向名稱節點主動發起TCP鏈接，並使用客戶端協議與名稱節點進行交互

名稱節點和數據節點之間則使用數據節點協議進行交互

客戶端與數據節點的交互是經過RPC（Remote Procedure Call）來實現的。在設計上，名稱節點不會主動發起RPC，而是響應來自客戶端和數據節點的RPC請求

3.4.4客戶端

客戶端是用戶操做HDFS最經常使用的方式，HDFS在部署時都提供了客戶端

HDFS客戶端是一個庫，暴露了HDFS文件系統接口，這些接口隱藏了HDFS實現中的大部分複雜性

嚴格來講，客戶端並不算是HDFS的一部分

客戶端能夠支持打開、讀取、寫入等常見的操做，而且提供了相似Shell的命令行方式來訪問HDFS中的數據

此外，HDFS也提供了Java API，做爲應用程序訪問文件系統的客戶端編程接口

3.4.5HDFS體系結構的侷限性

 

HDFS只設置惟一一個名稱節點，這樣作雖然大大簡化了系統設計，但也帶來了一些明顯的侷限性，具體以下：
（1）命名空間的限制：名稱節點是保存在內存中的，所以，名稱節點可以容納的對象（文件、塊）的個數會受到內存空間大小的限制。
（2）性能的瓶頸：整個分佈式文件系統的吞吐量，受限於單個名稱節點的吞吐量。
（3）隔離問題：因爲集羣中只有一個名稱節點，只有一個命名空間，所以，沒法對不一樣應用程序進行隔離。
（4）集羣的可用性：一旦這個惟一的名稱節點發生故障，會致使整個集羣變得不可用。

 

3.5HDFS存儲原理

3.5.1冗餘數據保存

做爲一個分佈式文件系統，爲了保證系統的容錯性和可用性，HDFS採用了多副本方式對數據進行冗餘存儲，一般一個數據塊的多個副本會被分佈到不一樣的數據節點上，如圖所示，數據塊1被分別存放到數據節點A和C上，數據塊2被存放在數據節點A和B上。這種多副本方式具備如下幾個優勢：

（1）加快數據傳輸速度
（2）容易檢查數據錯誤
（3）保證數據可靠性

 

3.5.2數據存取策略

 一、數據存放

第一個副本：放置在上傳文件的數據節點；若是是集羣外提交，則隨機挑選一臺磁盤不太滿、CPU不太忙的節點
第二個副本：放置在與第一個副本不一樣的機架的節點上
第三個副本：與第一個副本相同機架的其餘節點上
更多副本：隨機節點

Block的副本放置策略

二、數據讀取

HDFS提供了一個API能夠肯定一個數據節點所屬的機架ID，客戶端也能夠調用API獲取本身所屬的機架ID
當客戶端讀取數據時，從名稱節點得到數據塊不一樣副本的存放位置列表，列表中包含了副本所在的數據節點，能夠調用API來肯定客戶端和這些數據節點所屬的機架ID，當發現某個數據塊副本對應的機架ID和客戶端對應的機架ID相同時，就優先選擇該副本讀取數據，若是沒有發現，就隨機選擇一個副本讀取數據

3.5.3數據錯誤與恢復

 

HDFS具備較高的容錯性，能夠兼容廉價的硬件，它把硬件出錯看做一種常態，而不是異常，並設計了相應的機制檢測數據錯誤和進行自動恢復，主要包括如下幾種情形：名稱節點出錯、數據節點出錯和數據出錯。

一、名稱節點出錯

  名稱節點保存了全部的元數據信息，其中，最核心的兩大數據結構是FsImage和Editlog，若是這兩個文件發生損壞，那麼整個HDFS實例將失效。所以，HDFS設置了備份機制，把這些核心文件同步複製到備份服務器SecondaryNameNode上。當名稱節點出錯時，就能夠根據備份服務器SecondaryNameNode中的FsImage和Editlog數據進行恢復。

二、數據節點出錯

每一個數據節點會按期向名稱節點發送「心跳」信息，向名稱節點報告本身的狀態
當數據節點發生故障，或者網絡發生斷網時，名稱節點就沒法收到來自一些數據節點的心跳信息，這時，這些數據節點就會被標記爲「宕機」，節點上面的全部數據都會被標記爲「不可讀」，名稱節點不會再給它們發送任何I/O請求
這時，有可能出現一種情形，即因爲一些數據節點的不可用，會致使一些數據塊的副本數量小於冗餘因子
名稱節點會按期檢查這種狀況，一旦發現某個數據塊的副本數量小於冗餘因子，就會啓動數據冗餘複製，爲它生成新的副本
HDFS和其它分佈式文件系統的最大區別就是能夠調整冗餘數據的位置

三、數據出錯

網絡傳輸和磁盤錯誤等因素，都會形成數據錯誤
客戶端在讀取到數據後，會採用md5和sha1對數據塊進行校驗，以肯定讀取到正確的數據
在文件被建立時，客戶端就會對每個文件塊進行信息摘錄，並把這些信息寫入到同一個路徑的隱藏文件裏面
當客戶端讀取文件的時候，會先讀取該信息文件，而後，利用該信息文件對每一個讀取的數據塊進行校驗，若是校驗出錯，客戶端就會請求到另一個數據節點讀取該文件塊，而且向名稱節點報告這個文件塊有錯誤，名稱節點會按期檢查而且從新複製這個塊

 

3.6HDFS數據讀寫過程

 讀取文件

寫入文件

FileSystem是一個通用文件系統的抽象基類，能夠被分佈式文件系統繼承，全部可能使用Hadoop文件系統的代碼，都要使用這個類
Hadoop爲FileSystem這個抽象類提供了多種具體實現
DistributedFileSystem就是FileSystem在HDFS文件系統中的具體實現
FileSystem的open()方法返回的是一個輸入流FSDataInputStream對象，在HDFS文件系統中，具體的輸入流就是DFSInputStream；FileSystem中的create()方法返回的是一個輸出流FSDataOutputStream對象，在HDFS文件系統中，具體的輸出流就是DFSOutputStream。

3.6.1讀數據的過程

 

 

 

3.6.2寫數據的過程

 

 

 

 

3.7HDFS編程實踐