HDFS 05 – HDFS 的元數據管理（FSImage、EditLog、Checkpoint）
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 管理流程
-
SecondaryNameNode 通知 NameNode 停止使用 EditLog，暫時將新的寫操作存放到
edits.new文件； -
SecondaryNameNode 通過 HTTP 的 GET 請求，從 NameNode 中獲取 FSImage 和 EditLog，將它們載入到記憶體中；
-
SecondaryNameNode 合併 FSImage 和 EditLog，合併完成後生成新的 FSImage；
-
SecondaryNameNode 通過 HTTP POST 請求方式，將新的 FSImage 發送給 NameNode；
-
NameNode 把原有的 FSImage 替換為新的 FSImage，把 edits.new 變成 edits，同時更新 fstime（即最後一個檢查點的時間戳）。
參考資料
版權聲明
出處：部落格園-瘦風的南牆(//www.cnblogs.com/shoufeng)
感謝閱讀，公眾號 「瘦風的南牆」 ，手機端閱讀更佳，還有其他福利和心得輸出，歡迎掃碼關注🤝
本文版權歸部落客所有，歡迎轉載，但 [必須在頁面明顯位置標明原文鏈接]，否則部落客保留追究相關人士法律責任的權利。
