Hadoop中HDFS的儲存機制

HDFS（Hadoop Distributed File System）是Hadoop分散式計算中的資料儲存系統，是基於流資料模式訪問和處理超大檔案的需求而開發的。下面我們首先介紹HDFS中的一些基礎概念，然後介紹HDFS中讀寫操作的過程，最後分析了HDFS的優缺點。

1. HDFS中的基礎概念

Block：HDFS中的儲存單元是每個資料塊block，HDFS預設的最基本的儲存單位是64M的資料塊。和普通的檔案系統相同的是，HDFS中的檔案也是被分成64M一塊的資料塊儲存的。不同的是，在HDFS中，如果一個檔案大小小於一個數據塊的大小，它是不需要佔用整個資料塊的儲存空間的。

NameNode：元資料節點。該節點用來管理檔案系統中的名稱空間，是master。其將所有的為了見和資料夾的元資料儲存在一個檔案系統樹中，這些資訊在硬碟上儲存為了：名稱空間映象（namespace image）以及修改日誌（edit log），後面還會講到。此外，NameNode還儲存了一個檔案包括哪些資料塊，分佈在哪些資料節點上。然而，這些資訊不存放在硬碟上，而是在系統啟動的時候從資料節點收集而成的。

DataNode：資料節點。是HDFS真正儲存資料的地方。客戶端（client）和元資料節點（NameNode）可以向資料節點請求寫入或者讀出資料塊。此外，DataNode需要週期性的向元資料節點回報其儲存的資料塊資訊。

Secondary NameNode:從元資料節點。從元資料節點並不是NameNode出現問題時候的備用節點，它的主要功能是週期性的將NameNode中的namespace image和edit log合併，以防log檔案過大。此外，合併過後的namespace image檔案也會在Secondary NameNode上儲存一份，以防NameNode失敗的時候，可以恢復。

edit log：修改日誌。當檔案系統客戶端client進行------寫------操作的時候，我們就要把這條記錄放在修改日誌中。在記錄了修改日誌後，NameNode則修改記憶體中的資料結構。每次寫操作成功之前，edit log都會同步到檔案系統中。

fsimage：名稱空間映象。它是記憶體中的元資料在硬碟上的checkpoint。當NameNode失敗的時候，最新的checkpoint的元資料資訊就會從fsimage載入到記憶體中，然後注意重新執行修改日誌中的操作。而Secondary NameNode就是用來幫助元資料節點將記憶體中的元資料資訊checkpoint到硬碟上的。

具體checkpoint的過程如下圖：（參考hadoop叢集的部落格）

checkpoint的過程如下：Secondary NameNode通知NameNode生成新的日誌檔案，以後的日誌都寫到新的日誌檔案中。Secondary NameNode用http get從NameNode獲得fsimage檔案及舊的日誌檔案。Secondary NameNode將fsimage檔案載入到記憶體中，並執行日誌檔案中的操作，然後生成新的fsimage檔案。Secondary NameNode將新的fsimage檔案用http post傳回NameNode。NameNode可以將舊的fsimage檔案及舊的日誌檔案，換為新的fsimage檔案和新的日誌檔案(第一步生成的)，然後更新fstime檔案，寫入此次checkpoint的時間。這樣NameNode中的fsimage檔案儲存了最新的checkpoint的元資料資訊，日誌檔案也重新開始，不會變的很大了。

2. HDFS中檔案讀寫操作流程

在HDFS中，檔案的讀寫過程就是client和NameNode以及DataNode一起互動的過程。我們已經知道NameNode管理著檔案系統的元資料，DataNode儲存的是實際的資料，那麼client就會聯絡NameNode以獲取檔案的元資料，而真正的檔案讀取操作是直接和DataNode進行互動的。

寫檔案的過程：

 客戶端呼叫create()來建立檔案DistributedFileSystem用RPC呼叫元資料節點，在檔案系統的名稱空間中建立一個新的檔案。元資料節點首先確定檔案原來不存在，並且客戶端有建立檔案的許可權，然後建立新檔案。DistributedFileSystem返回DFSOutputStream，客戶端用於寫資料。客戶端開始寫入資料，DFSOutputStream將資料分成塊，寫入data queue。Data queue由Data Streamer讀取，並通知元資料節點分配資料節點，用來儲存資料塊(每塊預設複製3塊)。分配的資料節點放在一個pipeline裡。Data Streamer將資料塊寫入pipeline中的第一個資料節點。第一個資料節點將資料塊傳送給第二個資料節點。第二個資料節點將資料傳送給第三個資料節點。DFSOutputStream為發出去的資料塊儲存了ack queue，等待pipeline中的資料節點告知資料已經寫入成功。如果資料節點在寫入的過程中失敗：

關閉pipeline，將ack queue中的資料塊放入data queue的開始。
當前的資料塊在已經寫入的資料節點中被元資料節點賦予新的標示，則錯誤節點重啟後能夠察覺其資料塊是過時的，會被刪除。
失敗的資料節點從pipeline中移除，另外的資料塊則寫入pipeline中的另外兩個資料節點。
元資料節點則被通知此資料塊是複製塊數不足，將來會再建立第三份備份。

讀取檔案的過程：

3. HDFS的優缺點分析

優點：

1）能夠處理超大的檔案；

2）流式訪問資料。HDFS能夠很好的處理“一次寫入，多次讀寫”的任務。也就是說，一個數據集一旦生成了，就會被複制到不同的儲存節點中，然後響應各種各樣的資料分析任務請求。在多數情況下，分析任務都會涉及到資料集中的大部分資料。所以，HDFS請求讀取整個資料集要比讀取一條記錄更加高效。

3）可以執行在比較廉價的商用機器叢集上。

缺點和改進策略：

1）不適合低延遲資料訪問：HDFS是為了處理大型資料集分析任務的，主要是為達到大資料分析，所以延遲時間可能會較高。改進策略：對於那些有低延時要求的應用程式，HBase是一個更好的選擇。通過上層資料管理專案來儘可能地彌補這個不足。在效能上有了很大的提升，它的口號就是goes real time。使用快取或多master設計可以降低client的資料請求壓力，以減少延時。還有就是對HDFS系統內部的修改，這就得權衡大吞吐量與低延時了。

2）無法高效儲存大量小檔案：因為Namenode把檔案系統的元資料放置在記憶體中，所以檔案系統所能容納的檔案數目是由Namenode的記憶體大小來決定。一般來說，每一個檔案、資料夾和Block需要佔據150位元組左右的空間，所以，如果你有100萬個檔案，每一個佔據一個Block，你就至少需要300MB記憶體。當前來說，數百萬的檔案還是可行的，當擴充套件到數十億時，對於當前的硬體水平來說就沒法實現了。還有一個問題就是，因為Map task的數量是由splits來決定的，所以用MR處理大量的小檔案時，就會產生過多的Maptask，執行緒管理開銷將會增加作業時間。舉個例子，處理10000M的檔案，若每個split為1M，那就會有10000個Maptasks，會有很大的執行緒開銷；若每個split為100M，則只有100個Maptasks，每個Maptask將會有更多的事情做，而執行緒的管理開銷也將減小很多。改進策略：要想讓HDFS能處理好小檔案，有不少方法。利用SequenceFile、MapFile、Har等方式歸檔小檔案，這個方法的原理就是把小檔案歸檔起來管理，HBase就是基於此的。對於這種方法，如果想找回原來的小檔案內容，那就必須得知道與歸檔檔案的對映關係。橫向擴充套件，一個Hadoop叢集能管理的小檔案有限，那就把幾個Hadoop叢集拖在一個虛擬伺服器後面，形成一個大的Hadoop叢集。google也是這麼幹過的。多Master設計，這個作用顯而易見了。正在研發中的GFS II也要改為分散式多Master設計，還支援Master的Failover，而且Block大小改為1M，有意要調優處理小檔案啊。
附帶個Alibaba DFS的設計，也是多Master設計，它把Metadata的對映儲存和管理分開了，由多個Metadata儲存節點和一個查詢Master節點組成。

3）不支援多使用者寫入以及任意修改檔案：在HDFS的一個檔案中只有一個寫入者，而且寫操作只能在檔案末尾完成，即只能執行追加操作。目前HDFS還不支援多個使用者對同一檔案的寫操作，以及在檔案任意位置進行修改。

轉載：點選開啟連結