天天看點

Hadoop中HDFS的存儲機制1. HDFS中的基礎概念2. HDFS中檔案讀寫操作流程3. HDFS的優缺點分析

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的中繼資料資訊,日志檔案也重新開始,不會變的很大了。
Hadoop中HDFS的存儲機制1. HDFS中的基礎概念2. HDFS中檔案讀寫操作流程3. HDFS的優缺點分析

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中的另外兩個資料節點。

          中繼資料節點則被通知此資料塊是複制塊數不足,将來會再建立第三份備份。

  • 當用戶端結束寫入資料,則調用stream的close函數。此操作将所有的資料塊寫入pipeline中的資料節點,并等待ack queue傳回成功。最後通知中繼資料節點寫入完畢。
Hadoop中HDFS的存儲機制1. HDFS中的基礎概念2. HDFS中檔案讀寫操作流程3. HDFS的優缺點分析

    讀取檔案的過程:

  • 用戶端(client)用FileSystem的open()函數打開檔案
  • DistributedFileSystem用RPC調用中繼資料節點,得到檔案的資料塊資訊。
  • 對于每一個資料塊,中繼資料節點傳回儲存資料塊的資料節點的位址。
  • DistributedFileSystem傳回FSDataInputStream給用戶端,用來讀取資料。
  • 用戶端調用stream的read()函數開始讀取資料。
  • DFSInputStream連接配接儲存此檔案第一個資料塊的最近的資料節點。
  • Data從資料節點讀到用戶端(client)
  • 當此資料塊讀取完畢時,DFSInputStream關閉和此資料節點的連接配接,然後連接配接此檔案下一個資料塊的最近的資料節點。
  • 當用戶端讀取完畢資料的時候,調用FSDataInputStream的close函數。

              在讀取資料的過程中,如果用戶端在與資料節點通信出現錯誤,則嘗試連接配接包含此資料塊的下一個資料節點。失敗的資料節點将被記錄,以後不再連接配接。

Hadoop中HDFS的存儲機制1. HDFS中的基礎概念2. HDFS中檔案讀寫操作流程3. HDFS的優缺點分析

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還不支援多個使用者對同一檔案的寫操作,以及在檔案任意位置進行修改。

參考連結:http://www.cnblogs.com/xia520pi/archive/2012/05/28/2520813.html

繼續閱讀