HDFS的元資料資訊FSimage以及edits和secondaryNN的作用
1、 FSImage與edits詳解
當架構如下圖所示時：
<property> <name>dfs.namenode.name.dir</name> <value>file:///export/servers/hadoop-2.6.0-cdh5.14.0/hadoopDatas/namenodeDatas</value> </property> <property> <name>dfs.namenode.edits.dir</name> <value>file:///export/servers/hadoop-2.6.0-cdh5.14.0/hadoopDatas/dfs/nn/edits</value> </property>
edits
客戶端對hdfs進行寫檔案時會首先被記錄在edits檔案中。 edits修改時元資料也會更新。 每次hdfs更新時edits先更新後客戶端才會看到最新資訊。
fsimage
fsimage:是namenode中關於元資料的映象，一般稱為檢查點。 fsimage是namenode的完整的映象，內容很大，如果每次都載入到記憶體的話生成樹狀拓撲結構，會非常耗記憶體和CPU。所以，一般開始時對namenode的操作都放在edits中。 fsimage內容包含了namenode管理下的所有datanode中檔案及檔案block及block所在的datanode的元資料資訊。隨著edits內容增大，就需要在一定時間點和fsimage合併。
2、FSimage檔案當中的檔案資訊檢視
使用命令hdfs oiv
cd /export/servers/hadoop-2.6.0-cdh5.14.0/hadoopDatas/namenodeDatas/current
hdfs oiv -i fsimage_0000000000000000864 -p XML -o hello.xml
3、edits當中的檔案資訊檢視
檢視命令 hdfs oev
cd /export/servers/hadoop-2.6.0-cdh5.14.0/hadoopDatas/dfs/nn/edits
hdfs oev -i edits_0000000000000000865-0000000000000000866 -o myedit.xml -p XML
4、secondarynameNode如何輔助管理FSImage與Edits檔案
①：secnonaryNN通知NameNode切換editlog ②：secondaryNN從NameNode中獲得FSImage和editlog(通過http方式) ③：secondaryNN將FSImage載入記憶體，然後開始合併editlog，合併之後成為新的fsimage ④：secondaryNN將新的fsimage發回給NameNode ⑤：NameNode用新的fsimage替換舊的fsimage
完成合並的是secondarynamenode，會請求namenode停止使用edits,暫時將新寫操作放入一個新的檔案中（edits.new)。 secondarynamenode從namenode中通過http get獲得edits，因為要和fsimage合併，所以也是通過http get 的方式把fsimage載入到記憶體，然後逐一執行具體對檔案系統的操作，與fsimage合併，生成新的fsimage，然後把fsimage傳送給namenode，通過http post的方式。namenode從secondarynamenode獲得了fsimage後會把原有的fsimage替換為新的fsimage,把edits.new變成edits。同時會更新fstime。 hadoop進入安全模式時需要管理員使用dfsadmin的save namespace來建立新的檢查點。 secondarynamenode在合併edits和fsimage時需要消耗的記憶體和namenode差不多，所以一般把namenode和secondarynamenode放在不同的機器上。
配置檔案core-site.xml 進行引數配置，一般保持預設： fs.checkpoint.period: 表示多長時間記錄一次hdfs的映象，預設是一個小時（3600s) fs.checkpoint.size: 表示一次記錄多大的size，edits達到一定大小時也會觸發合併（預設64MB)
參考文件：http://archive.cloudera.com/cdh5/cdh/5/hadoop-2.6.0-cdh5.14.0/hadoop-project-dist/hadoop-hdfs/HdfsEditsViewer.html