Hadoop中NameNode元數據的原理是什么

本篇文章為大家展示了Hadoop中NameNode元數據的原理是什么，內容簡明扼要并且容易理解，絕對能使你眼前一亮，通過這篇文章的詳細介紹希望你能有所收獲。

在對NameNode節點進行格式化時，調用了FSImage的saveFSImage()方法和FSEditLog.createEditLogFile()存儲當前的元數據。Namenode主要維護兩個文件，一個是fsimage，一個是editlog。

fsimage ：保存了最新的元數據檢查點，包含了整個HDFS文件系統的所有目錄和文件的信息。對于文件來說包括了數據塊描述信息、修改時間、訪問時間等；對于目錄來說包括修改時間、訪問權限控制信息(目錄所屬用戶，所在組)等。簡單的說，Fsimage就是在某一時刻，整個hdfs 的快照，就是這個時刻hdfs上所有的文件塊和目錄，分別的狀態，位于哪些個datanode，各自的權限，各自的副本個數等。

注意：Block的位置信息不會保存到fsimage，Block保存在哪個DataNode（由DataNode啟動時上報）。

editlog ：主要是在NameNode已經啟動情況下對HDFS進行的各種更新操作進行記錄，HDFS客戶端執行所有的寫操作都會被記錄到editlog中。

讀取元數據：
啟動NameNode節點時，又要從鏡像和編輯日志中讀取元數據。

寫入元數據：
在NameNode運行時會將內存中的元數據信息存儲到所指定的文件，即${dfs.name.dir}/current目錄下的fsimage文件，此外還會將另外一部分對NameNode更改的日志信息存儲到${dfs.name.dir}/current目錄下的edits文件中。fsimage文件和edits文件可以確定NameNode節點當前的狀態，這樣在NameNode節點由于突發原因崩潰時，可以根據這兩個文件中的內容恢復到節點崩潰前的狀態，所以對NameNode節點中內存元數據的每次修改都必須保存下來。但是如果每次都保存到fsimage文件中，這樣效率就特別低效，所以引入編輯日志文件edits，保存對對元數據的修改信息，也就是fsimage文件保存NameNode節點中某一時刻內存中的元數據（即目錄樹），edits保存這一時刻之后的對元數據的更改信息。

鏡像的保存：

 SecondaryNameNode：主要由兩個作用，一是鏡像備份（不是NN的備份，但可以做備份），二是日志與鏡像的定期合并。

第一步：將hdfs更新記錄寫入一個新的文件——edits.new。
第二步：將fsimage和editlog通過http協議發送至secondary namenode。
第三步：將fsimage與editlog合并，生成一個新的文件——fsimage.ckpt。這步之所以要在secondary namenode中進行，是因為比較耗時，如果在namenode中進行，或導致整個系統卡頓。
第四步：將生成的fsimage.ckpt通過http協議發送至namenode。
第五步：重命名fsimage.ckpt為fsimage，edits.new為edits。

第六步：等待下一次checkpoint觸發SecondaryNameNode進行工作，一直這樣循環操作。

注：checkpoint觸發的條件可以在core-site.xml文件中進行配置。fs.checkpoint.period表示多長時間記錄一次hdfs的鏡像。默認是1小時。fs.checkpoint.size表示一次記錄多大的size，默認64M。例如如下：
<property> 
<name>fs.checkpoint.period</name> 
<value>3600</value> 
<description>The number of seconds between two periodic checkpoints. 
</description> 
</property> 

<property> 
<name>fs.checkpoint.size</name> 
<value>67108864</value> 
<description>The size of the current edit log (in bytes) that triggers 
a periodic checkpoint even if the fs.checkpoint.period hasn't expired. 
</description> 
</property>

上述內容就是Hadoop中NameNode元數據的原理是什么，你們學到知識或技能了嗎？如果還想學到更多技能或者豐富自己的知識儲備，歡迎關注億速云行業資訊頻道。