HDFS 05 - HDFS 的後設資料管理(FSImage、EditLog、Checkpoint)

瘦風發表於2021-06-06

1 - NameNode 的啟動流程

1)Loading fsimage - 從 fsimage file 中讀取最新的後設資料快照(最近生成的 fsimage_xx);

2)Loading edits - 讀取 fsimage_xx 之後的所有事務的 edit logs,將 edit logs 中的操作重新執行一遍,此時 NameNode 就恢復到上次停止時的狀態了;

3)checkpoint - 將當前狀態寫入新的 checkpoint 中,即產生一個新的 fsimage_xx 檔案;

4)Safe mode - 等待各個 DataNodes 彙報自己的 block 資訊,形成 blockMap,然後退出安全模式。

此時 NameNode 啟動結束,等待接受使用者的操作請求,並把使用者操作寫入新的 edit log 中,定期進行 checkpoint,對後設資料執行快照。

2 - NameNode 的後設資料

NameNode 的所有操作及整個叢集的狀態都儲存在 後設資料 中,後設資料都儲存在 fsImage 和 eidts 檔案中。

它們的主要作用是:在叢集啟動時將叢集的狀態恢復到關閉前的狀態

第一次啟動 NameNode 前的格式化(hdfs namenode -format)操作會建立 fsimage 和 edits 檔案。

非第一次啟動,NameNode 會進行資料恢復:首先把 FSImage 檔案載入到記憶體中形成檔案系統映象,然後再把 EditLog 中 FsImage 的結束事務 id 之後的 EditLog 回放到這個檔案系統映象上。這個時候,叢集也就恢復到關閉前的狀態了。

它們的位置需要在 hdfs-site.xml 檔案中指定:

<!-- NameNode 後設資料的存放目錄 -->
<property>
    <name>dfs.namenode.name.dir</name>    
    <value>file:/Users/healchow/data/hadoop/namenode</value>
</property>
<!-- NameNode 日誌檔案的存放目錄 -->
<property>
     <name>dfs.namenode.edits.dir</name>
     <value>file:/Users/healchow/data/hadoop/namenode/edits</value
</property>

2.1 EditLog 操作日誌

1)客戶端對 HDFS 的寫操作會首先被記錄在 edits 檔案中;

HDFS 客戶端提交的建立、移動、刪除檔案等 寫操作 的時候,NameNode 會首先把這些操作記錄在 EditLog 檔案中。

2)edits 修改完成之後,會再更新記憶體中的檔案系統映象;

edits 檔案會不斷增大(導致系統執行、重啟恢復等過程非常緩慢),在一定條件下會和 fsimage 檔案合併,從而減小 EditLog 檔案的體積。

3)記錄在 EditLog 中的每一個操作又稱為一個事務,每個事務有一個整數形式的事務 id 作為編號。

(臨時總結,不一定對)EditLog 就是事務日誌,主要作用是用來記錄寫操作,以支援系統的恢復。

2.2 檢視 EditLog 檔案

EditLog 會被切割成很多段,每一段稱為一個 Segment。正在寫入的 Segment 處於 in-progress 狀態,其檔名形如 edits_inprogress_${start_txid},其中 ​${start_txid} 表示這個 Segment 的起始事務 id。

已經寫入完成的 Segment 處於 finalized 狀態,其檔名形如 edits_${start_txid}-${end_txid},其中 ${start_txid} 表示這個 Segment 的起始事務 id,${end_txid} 表示這個 Segment 的結束事務 id。

檢視 edits 中的檔案資訊

hdfs oev 回車後會顯示命令的幫助資訊:
cd ~/data/hadoop/namenode
hdfs oev -i edits_0000000000000000865-0000000000000000866 -p XML -o myedit.xml

2.3 FSImage 後設資料映象

1)FSImage 是 NameNode 中關於後設資料的映象,一般稱為檢查點的映象;

2)FSImage 是 NameNode 自上次 checkpoint 之後生成的後設資料,並不是實時的資料

3)FSImage 儲存了 NameNode 管理下的所有 DataNode 的檔案和目錄資訊:

對檔案來說:包括檔案的 block、各個 block 所在的 DataNode,以及它們的修改時間、訪問時間等;

對目錄來說:包括修改時間、訪問許可權控制資訊(許可權、屬組)等。

FSImage 預設會儲存2個,由屬性 dfs.namenode.num.checkpoints.retained 控制。

記憶體中的 FSImage 用於 NameNode 向客戶端提供讀服務,而 EditLog 僅僅只是在資料恢復的時候發揮作用。

2.4 檢視 FSImage 檔案

FSImage 檔案的檔名形如 fsimage_${end_txid},其中 ${end_txid} 表示這個 FSImage 檔案的結束事務 id。

檢視 fsimage 中的檔案資訊:

hdfs oev 回車後會顯示命令的幫助資訊:

cd ~/bigdata/data/hadoop/namenode
hdfs oiv -i fsimage_0000000000000000864 -p XML -o hello.xml

3 - Checkpoint 檢查點操作

3.1 為什麼要 Checkpoint

HDFS 的每個寫操作都會寫入EditLog 中,隨著時間的積累 EditLog 會變的很大,極端情況下會佔滿整個磁碟。

另外,由於 NameNode 在啟動的時候,需要將 EditLog 中的操作重新執行一遍,過大的 EditLog 會延長 NameNode 的啟動時間。

所以,通過 Checkpoint 定期對後設資料進行合併。

3.2 Checkpoint 的過程

Checkpoint 會把 FSImage 和 EditLog 的內容進行合併生成一個新的 FSImage。

這樣在 NameNode 啟動的時候就不用將巨大的 EditLog 中的事務再執行一遍,而是直接載入合併之後的新 FSImage ,然後重新執行未被合併的 EditLog 檔案就可以了。

建立新 FSImage 的過程需要大量的I/O、記憶體等資源,為了減輕影響,可將 Checkpoint 過程放在 SecondaryNameNode 或 StandbyNameNode 中(不同機器上)。

NameNode 在 Checkpoint 的時候會限制使用者的訪問(Hadoop 進入安全模式,此時需要管理員使用 dfsadmin 的 save namespace 來建立新的檢查點);

4 - SNN 輔助管理 FSImage 和 EditLog

4.1 相關配置

SNN(SecondaryNameNode,備份 NameNode)節點要在 conf/masters 檔案中指定;

SNN 的 hdfs-site.xml 檔案中需要配置下述引數:

<property>
  <name>dfs.http.address</name>
  <value>host:50070</value>
</property>

SecondaryNameNode 會定期合併 FSImage 和 EditLog,把 EditLog的體積控制在一個合理的範圍內。

Checkpoint 的觸發條件取決於兩個引數,可在 NameNode / SNN 的 core-site.xml 中配置:

<!-- 兩次 checkpoint 的時間間隔,預設3600秒,即1小時 -->
<property>
    <name>dfs.namenode.checkpoint.period</name>
    <value>3600s</value>
</property>
<!-- 新生成的 EditLog 中積累的事務數量達到了閾值,預設1000000次。優先順序高於上述引數 -->
<property>
    <name>dfs.namenode.checkpoint.txns</name>
    <value>1000000</value>
</property>
<!-- 每隔多久檢查一次 HDFS 未記錄到檢查點的事務數,預設60秒 -->
<property>
    <name>dfs.namenode.checkpoint.check.period</name>
    <value>60s</value>
</property>

<!-- 一次記錄檔案的大小,預設64MB -->
<property>
    <name>fs.checkpoint.size</name>
    <value>67108864</value>
</property>

4.2 管理流程

HDFS 05 - HDFS 的後設資料管理(FSImage、EditLog、Checkpoint)
  1. SecondaryNameNode 通知 NameNode 停止使用 EditLog,暫時將新的寫操作存放到 edits.new 檔案;

  2. SecondaryNameNode 通過 HTTP 的 GET 請求,從 NameNode 中獲取 FSImage 和 EditLog,將它們載入到記憶體中;

  3. SecondaryNameNode 合併 FSImage 和 EditLog,合併完成後生成新的 FSImage;

  4. SecondaryNameNode 通過 HTTP POST 請求方式,將新的 FSImage 傳送給 NameNode;

  5. NameNode 把原有的 FSImage 替換為新的 FSImage,把 edits.new 變成 edits,同時更新 fstime(即最後一個檢查點的時間戳)。

參考資料

NameNode原資料及checkpoint分析

版權宣告

作者:瘦風(https://healchow.com)

出處:部落格園-瘦風的南牆(https://www.cnblogs.com/shoufeng)

感謝閱讀,公眾號 「瘦風的南牆」 ,手機端閱讀更佳,還有其他福利和心得輸出,歡迎掃碼關注?

本文版權歸博主所有,歡迎轉載,但 [必須在頁面明顯位置標明原文連結],否則博主保留追究相關人士法律責任的權利。

相關文章