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)

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

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

相關文章