Hadoop系列之七：分佈式文件系統HDFS(2)

一、訪問HDFS文件系統

HDFS是工做於用戶空間的文件系統，它的樹狀文件系統是獨立的，不能像傳統上工做於內核空間的文件系統同樣掛載至當前操做系統的目錄樹上對HDFS進行訪問，傳統上實現文件或目錄管理的命令如ls、cat等此處也沒法正常使用。對HDFS文件系統上的文件進行訪問，須要經過HDFS的API或者由hadoop提供的命令行工具進行。
1.1 HDFS用戶接口
(1) hadoop dfs命令行接口；
(2) hadoop dfsadmin命令行接口；
(3) web接口；
(4) HDFS API；

前三者方式在後文會有詳細的使用說明。不管基於何種方式與HDFS文件系統交互，其讀取或寫入數據的過程是相同的，下面分別對寫操做和讀操做的過程進行詳細描述。
1.2 向HDFS文件系統保存數據
當須要存儲文件並寫數據時，客戶端程序首先會向名稱節點發起名稱空間更新請求，名稱節點檢查用戶的訪問權限及文件是否已經存在，若是沒有問題，名稱空間會挑選一個合適的數據節點分配一個空閒數據塊給客戶端程序。客戶端程序直接將要存儲的數據發往對應的數據節點，在完成存儲後，數據節點將根據名稱節點的指示將數據塊複製多個副本至其它節點。

(1) 向HDFS集羣中保存數據以前，HDFS客戶端須要事先知悉目標文件系統使用的「塊大小」以及「複製因子(Replication Factor，即每個塊須要保存的副本數目)」。在提交數據至HDFS以前，HDFS客戶端須要將要保存的文件按塊大小進行分割，並將其逐個向名稱節點發起塊存儲請求，此時，根據複製因子，客戶端會要求名稱節點給出與複製因子相同個數的空閒塊，這裏假設爲3個；

(2) 名稱節點須要從找出至少3個具備可用空閒塊的數據節點(同複製因子)，並將這3個節點的地址以距客戶端的距離由近及遠的次序響應給客戶端；

(3) 客戶端僅向最近的數據節點(假設爲DN1)發起數據存儲請求；當此最近的數據節點存儲完成後，其會將數據塊複製到剩餘的數據節點中的一個(假設爲DN2)，傳輸完成後，由DN2負責將數據塊再同步至最後一個數據節點(假設爲DN3)；這個也稱爲「複製管道(replication pipeline)；

(4) 當三個數據節點均存儲完成後，它們會將「存儲完成(DONE)」的信息分別通知給名稱節點；然後，名稱節點會通知客戶端存儲完成；

(5) 客戶端以此種方式存儲剩餘的全部數據塊，並在所有數據塊存儲完成後通知名稱節點關閉此文件，名稱節點接着會將此文件的元數據信息存儲至持久存儲中；

1.3 從HDFS讀取數據
HDFS提供了POSIX風絡的訪問接口，全部的數據操做對客戶端程序都是透明的。當客戶端程序須要訪問HDFS中的數據時，它首先基於TCP/IP協議與名稱節點監聽的TCP端口創建鏈接，接着經過客戶端協議(Client Protocol)發起讀取文件的請求，然後名稱節點根據用戶請求返回相關文件的塊標識符(blockid)及存儲了此數據塊的數據節點。接下來客戶端向對應的數據節點監聽的端口發起請求並取回所須要數據塊。

(1) 客戶端向名稱節點請求訪問某文件；

(2) 名稱節點向客戶端響應兩個列表：(a)此文件包含的全部數據塊，(b)此文件的每一個數據塊所在的數據節點列表；

(3) 客戶端將每個數據塊從存儲列表中最近的數據節點讀取，然後在本地完成合並；

二、名稱節點的可用性

由前一節所述的過程能夠得知，名稱節點的宕機將會致使HDFS文件系統中的全部數據變爲不可用，而若是名稱節點上的名稱空間鏡像文件或編輯日誌文件損壞的話，整個HDFS甚至將無從重建，全部數據都會丟失。所以，出於數據可用性、可靠性等目的，必須提供額外的機制以確保此類故障不會發生，Hadoop爲此提供了兩種解決方案。
最簡單的方式是將名稱節點上的持久元數據信息實時存儲多個副本於不一樣的存儲設備中。Hadoop的名稱節點能夠經過屬性配置使用多個不一樣的名稱空間存儲設備，而名稱節點對多個設備的寫入操做是同步的。當名稱節點故障時，可在一臺新的物理主機上加載一份可用的名稱空間鏡像副本和編輯日誌副本完成名稱空間的重建。然而，根據編輯日誌的大小及集羣規模，這個重建過程可能須要很長時間。

另外一種方式是提供第二名稱節點(Secondary NameNode)。第二名稱節點並不真正扮演名稱節點角色，它的主要任務是週期性地將編輯日誌合併至名稱空間鏡像文件中以避免編輯日誌變得過大。它運行在一個獨立的物理主機上，並須要跟名稱節點一樣大的內存資源來完成文件合併。另外，它還保存一份名稱空間鏡像的副本。然而，根據其工做機制可知，第二名稱節點要滯後於主節點，所以名稱節點故障時，部分數據丟失仍然不可避免。
儘管上述兩種機制能夠最大程序上避免數據丟失，但其並不具備高可用的特性，名稱節點依然是一個單點故障，由於其宕機後，全部的數據將不可以被訪問，進而全部依賴於此HDFS運行的MapReduce做業也將停止。就算是備份了名稱空間鏡像和編輯日誌，在一個新的主機上重建名稱節點並完成接收來自各數據節點的塊信息報告也須要很長的時間才能完成。在有些應用環境中，這多是沒法接受的，爲此，Hadoop 0.23引入了名稱節點的高可用機制——設置兩個名稱節點工做於「主備」模型，主節點故障時，其全部服務將當即轉移至備用節點。進一步信息請參考官方手冊。
在大規模的HDFS集羣中，爲了不名稱節點成爲系統瓶頸，在Hadoop 0.23版本中引入了HDFS聯邦(HDFS Federation)機制。HDFS聯邦中，每一個名稱節點管理一個由名稱空間元數據和包含了全部塊相關信息的塊池組成名稱空間卷(namespace volume)，各名稱節點上的名稱空間卷是互相隔離的，所以，一個名稱節點的損壞並不影響其它名稱節點繼續提供服務。進一步信息請參考官方手冊。
三、HDFS的容錯能力

HDFS故障的三種最多見場景爲：節點故障、網絡故障和數據損壞。
在不具有名稱節點HA功能的Hadoop中，名稱節點故障將會致使整個文件系統離線；所以，名稱節點故障具備很是嚴重的後果。具體的解決方案請見「名稱節點的可用性」一節。
在HDFS集羣中，各數據節點週期性地(每3秒鐘)向名稱節點發送心跳信息(HEARTBEAT)以通告其「健康」情況；相應地，名稱節點若是在10分鐘內沒有收到某數據節點的心跳信息，則認爲其產生了故障並將其從可用數據節點列表中移除，不管此故障產生的緣由是節點自身仍是網絡問題。
客戶端與數據節點之間的數據傳輸基於TCP協議進行，客戶端每發送一個報文給數據節點，數據節點均會返回一個響應報文給客戶端；所以，若是客戶端重試數次後仍未能正常接收到來自數據節點的響應報文，其將放棄此數據節點轉而使用名稱節點提供的列表中的第二個數據節點。
網絡傳輸中的噪聲等都有可能致使數據訛誤，爲了不數據節點存儲錯誤的數據，客戶端發送數據至數據節點時會一併傳送此數據的校驗和，而數據節點會連同數據一塊兒存儲此校驗和。HDFS集羣中，數據節點週期性地每將本身持有的全部數據塊信息報告給名稱節點，但在發送每一個數據塊的相關信息以前，其會根據校驗和檢驗此數據塊是否出現了訛誤，若是檢驗出錯，數據節點將再也不向名稱節點通告本身持有此數據塊，名稱節點從而能夠得知此數據節點有數據塊損壞。

參考文獻：

Data-Intensive Text Processing with MapReduce

Hadoop in prictise
Hadoop Operations

Hadoop Documentation