淺談hdfs架構與資料流

摘要： 隨著資料量越來越大，在一個作業系統管轄的範圍內存不下了，那麼就分配到更多的作業系統管理的磁碟中，但是不方便管理和維護，迫切需要一種系統來管理多臺機器上的檔案，這就是分散式檔案管理系統。HDFS只是分散式檔案管理系統中的一種。 HDFS，它是一個檔案系統，用於儲存檔案，通過目錄樹來定位檔...

隨著資料量越來越大，在一個作業系統管轄的範圍內存不下了，那麼就分配到更多的作業系統管理的磁碟中，但是不方便管理和維護，迫切需要一種系統來管理多臺機器上的檔案，這就是分散式檔案管理系統。HDFS只是分散式檔案管理系統中的一種。

HDFS，它是一個檔案系統，用於儲存檔案，通過目錄樹來定位檔案；其次，它是分散式的，由很多伺服器聯合起來實現其功能，叢集中的伺服器有各自的角色。HDFS的設計適合一次寫入，多次讀出的場景，且不支援檔案的修改。適合用來做資料分析，並不適合用來做網盤應用。

HDFS架構

這種架構主要由四個部分組成，分別為HDFS Client、NameNode、DataNode和Secondary NameNode。
下面我們分別介紹這四個組成部分。
複製程式碼

Client客戶端

• 檔案切分。檔案上傳HDFS的時候，Client將檔案切分成一個一個的Block，然後進行儲存。
• 與NameNode互動，獲取檔案的位置資訊。
• 與DataNode互動，讀取或者寫入資料。
• Client提供一些命令來管理HDFS，比如啟動或者關閉HDFS。
• Client可以通過一些命令來訪問HDFS。

NameNode

就是master，它是一個主管、管理者
複製程式碼

• 管理HDFS的名稱空間。
• 管理資料塊（Block）對映資訊
• 配置副本策略
• 處理客戶端讀寫請求。

DataNode

就是Slave，NameNode下達命令，DataNode執行實際的操作
複製程式碼

• 儲存實際的資料塊。
• 執行資料塊的讀/寫操作。

Secondary NameNode

並非NameNode的熱備，當NameNode掛掉的時候，它並不能馬上替換NameNode並提供服務
複製程式碼

• 輔助NameNode，分擔其工作量。
• 定期合併Fsimage和Edits，並推送給NameNode。
• 在緊急情況下，可輔助恢復NameNode。

關於HDFS檔案塊大小

HDFS中的檔案在物理上是分塊儲存（block），塊的大小可以通過配置引數( dfs.blocksize)來規定，
預設大小在hadoop2.x版本中是128M，老版本中是64M。

HDFS的塊比磁碟的塊大，其目的是為了最小化定址開銷。如果塊設定得足夠大,從磁碟傳輸資料的時間會明顯大於定位
這個塊開始位置所需的時間,因而，傳輸一個由多個塊組成的檔案的時間取決於磁碟傳輸速率。 

如果定址時間約為10ms，而傳輸速率為100MB/s，為了使定址時間僅佔傳輸時間的1%，
我們要將塊大小設定約為100MB。預設的塊大小128MB。塊的大小：10ms*100*100M/s = 100M
複製程式碼

HDFS寫資料流程

• 客戶端通過Distributed FileSystem模組向namenode請求上傳檔案，namenode檢查目標檔案是否已存在，父目錄是否存在。
• namenode返回是否可以上傳。
• 客戶端請求第一個 block上傳到哪幾個datanode伺服器上。
• namenode返回3個datanode節點，分別為dn1、dn2、dn3。
• 客戶端通過FSDataOutputStream模組請求dn1上傳資料，dn1收到請求會繼續呼叫dn2，然後dn2呼叫dn3，將這個通訊管道建立完成。
• dn1、dn2、dn3逐級應答客戶端。
• 客戶端開始往dn1上傳第一個block（先從磁碟讀取資料放到一個本地記憶體快取），以packet為單位，dn1收到一個packet就會傳給dn2，dn2傳給dn3；dn1每傳一個packet會放入一個應答佇列等待應答。
• 當一個block傳輸完成之後，客戶端再次請求namenode上傳第二個block的伺服器。（重複執行3-7步）

HDFS讀資料流程

• 客戶端通過Distributed FileSystem向namenode請求下載檔案，namenode通過查詢元資料，找到檔案塊所在的datanode地址。
• 挑選一臺datanode（就近原則，然後隨機）伺服器，請求讀取資料。
• datanode開始傳輸資料給客戶端（從磁盤裡面讀取資料輸入流，以packet為單位來做校驗）。
• 客戶端以packet為單位接收，先在本地快取，然後寫入目標檔案。

NameNode & Secondary NameNode工作機制

• 第一階段：namenode啟動
  • 第一次啟動namenode格式化後，建立fsimage和edits檔案。如果不是第一次啟動，直接載入編輯日誌和映象檔案到記憶體。
  • 客戶端對元資料進行增刪改的請求。
  • namenode記錄操作日誌，更新滾動日誌。
  • namenode在記憶體中對資料進行增刪改查。
• 第二階段：Secondary NameNode工作
  • Secondary NameNode詢問namenode是否需要checkpoint。直接帶回namenode是否檢查結果。
  • Secondary NameNode請求執行checkpoint。
  • namenode滾動正在寫的edits日誌。
  • 將滾動前的編輯日誌和映象檔案拷貝到Secondary NameNode。
  • Secondary NameNode載入編輯日誌和映象檔案到記憶體，併合並。
  • 生成新的映象檔案fsimage.chkpoint。
  • 拷貝fsimage.chkpoint到namenode。
  • namenode將fsimage.chkpoint重新命名成fsimage。

關於映象檔案和編輯日誌檔案

概念

namenode被格式化之後，將在/opt/module/hadoop-2.7.2/data/tmp/dfs/name/current目錄中產生如下檔案:

edits_0000000000000000000
fsimage_0000000000000000000.md5
seen_txid
VERSION
複製程式碼

• Fsimage檔案：HDFS檔案系統元資料的一個永久性的檢查點，其中包含HDFS檔案系統的所有目錄和檔案idnode的序列化資訊。
• Edits檔案：存放HDFS檔案系統的所有更新操作的路徑，檔案系統客戶端執行的所有寫操作首先會被記錄到edits檔案中。
• seen_txid檔案儲存的是一個數字，就是最後一個edits_的數字
• 每次Namenode啟動的時候都會將fsimage檔案讀入記憶體，並從00001開始到seen_txid中記錄的數字依次執行每個edits裡面的更新操作，保證記憶體中的元資料資訊是最新的、同步的，可以看成Namenode啟動的時候就將fsimage和edits檔案進行了合併。