在進入下面的主題之前想來搞清楚edits和fsimage文件的概念：
1，fsimage文件其實是hadoop文件系統元數據的一個永久性的檢查點，其中包含hadoop文件系統中的所有目錄和文件idnode的序列化信息。
2，edits文件存放的是hadoop文件系統的所有更新操作的路徑，文件系統客戶端執行的所有寫操作首先會被記錄到edits文件中。
元數據的介紹：
元數據的分類
按形式分類：內存元數據和元數據文件；它們的存在的位置分別為：內存和磁盤上。其中內存元數據主要是hdfs文件目錄的管理；元數據文件則用於持久化存儲。
按類型分，元數據主要包括：
1、文件、目錄自身的屬性信息，例如文件名，目錄名，修改信息等。
2、文件記錄的信息的存儲相關的信息，例如存儲塊信息，分塊情況，副本個數等。
3、記錄HDFS的Datanode的信息，用於DataNode的管理。
內存元數據主要fsimage，而通過checkpoint功能備份的也主要是內存的元數據。
fsimage和edits文件都是經過序列化的，在NameNode啟動的時候，他會將fsimage文件中的內容加載到內存中，之后再執行edits文件中的各項操作，使得內存中的元數據和實際
的同步，存在內存中的元數據支持客戶端的讀操作。
NameNode起來之后，HDFS的更新操作會重新寫到edits文件中，因為fsimage文件一般都很大（GB級別的很常見），如果所有的更新操作都往fsimage文件中添加，這樣會導致系統運行
的十分緩慢。但如果往edits文件里面寫就不會這樣，因此，客戶端對hdfs進行寫文件時首先被記錄在edits文件中，edits修改時元數據也會更新，每次hdfs更新時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啟動的時間會很長，由此，定期地合並fsimage和edits文件的內容，然后清空edits文件是非常重要的。
完成合並的是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。
secondarynamenode在合並edits和fsimage時需要消耗的內存和namenode差不多，所以一般把namenode和secondarynamenode放在不同的機器上。
fs.checkpoint.period:默認是一個小時
fs.checkpoint.size:edits達到一定大小時也會出發合並。