Hadoop NameNode元數據相關文件目錄解析
在《Hadoop NameNode元數據相關文件目錄解析》文章中提到NameNode的$dfs.namenode.name.dir/current/文件夾的幾個文件:
1 |
current/ |
2 |
|-- VERSION |
3 |
|-- edits_* |
4 |
|-- fsimage_0000000000008547077 |
5 |
|-- fsimage_0000000000008547077.md5 |
6 |
`-- seen_txid |
其中存在大量的以edits開頭的文件和少量的以fsimage開頭的文件。那麽這兩種文件到底是什麽,有什麽用?下面對這兩中類型的文件進行詳解。在進入下面的主題之前先來搞清楚edits和fsimage文件的概念:
(1)、fsimage文件其實是Hadoop文件系統元數據的一個永久性的檢查點,其中包含Hadoop文件系統中的所有目錄和文件idnode的序列化信息;
(2)、edits文件存放的是Hadoop文件系統的所有更新操作的路徑,文件系統客戶端執行的所以寫操作首先會被記錄到edits文件中。
fsimage和edits文件都是經過序列化的,在NameNode啟動的時候,它會將fsimage文件中的內容加載到內存中,之後再執行edits文件中的各項操作,使得內存中的元數據和實際的同步,存在內存中的元數據支持客戶端的讀操作。
NameNode起來之後,HDFS中的更新操作會重新寫到edits文件中,因為fsimage文件一般都很大(GB級別的很常見),如果所有的更新操作都往fsimage文件中添加,這樣會導致系統運行的十分緩慢,但是如果往edits文件裏面寫就不會這樣,每次執行寫操作之後,且在向客戶端發送成功代碼之前,edits文件都需要同步更新。如果一個文件比較大,使得寫操作需要向多臺機器進行操作,只有當所有的寫操作都執行完成之後,寫操作才會返回成功,這樣的好處是任何的操作都不會因為機器的故障而導致元數據的不同步。
fsimage包含Hadoop文件系統中的所有目錄和文件idnode的序列化信息;對於文件來說,包含的信息有修改時間、訪問時間、塊大小和組成一個文件塊信息等;而對於目錄來說,包含的信息主要有修改時間、訪問控制權限等信息。fsimage並不包含DataNode的信息,而是包含DataNode上塊的映射信息,並存放到內存中,當一個新的DataNode加入到集群中,DataNode都會向NameNode提供塊的信息,而NameNode會定期的“索取”塊的信息,以使得NameNode擁有最新的塊映射。因為fsimage包含Hadoop文件系統中的所有目錄和文件idnode的序列化信息,所以如果fsimage丟失或者損壞了,那麽即使DataNode上有塊的數據,但是我們沒有文件到塊的映射關系,我們也無法用DataNode上的數據!所以定期及時的備份fsimage和edits文件非常重要!
在前面我們也提到,文件系統客戶端執行的所以寫操作首先會被記錄到edits文件中,那麽久而久之,edits會非常的大,而NameNode在重啟的時候需要執行edits文件中的各項操作,那麽這樣會導致NameNode啟動的時候非常長!在下篇文章中我會談到在Hadoop 1.x版本和Hadoop 2.x版本是怎麽處理edits文件和fsimage文件的。
Hadoop NameNode元數據相關文件目錄解析