其中datanode主要負責資料的儲存，namenode主要負責三個功能，分別是(1)管理元資料  (2)維護目錄樹 (3)響應客戶請求

首先介紹下，元資料格式

hdfs在外界看來就是普通的檔案系統，可以通過路徑進行資料的訪問等操作，但在實際過程儲存中，卻是分佈在各個節點上。如上圖所示，是一條元資料，/test/a.log 是在hdfs檔案系統中的路徑，3是這個檔案的副本數(副本數可以通過在配置檔案中的配置來修改的)。在hdfs中，檔案是進行分塊儲存的，如果檔案過大，就要分成多塊儲存，每個塊在檔案系統中儲存3個副本，以上圖為例，就是分成blk_1和blk_2兩個塊，每個塊在實際的節點中有3個副本，比如blk_1的3個副本分別儲存在h0，h1，h3中。

現在由此引出一個問題，namenode中的元資料是儲存在哪裡的？首先，我們做個假設，如果儲存在namenode節點的磁碟中，因為經常需要進行隨機訪問，還有響應客戶請求，必然是效率過低。因此，元資料需要存放在記憶體中。但如果只存在記憶體中，一旦斷點，元資料丟失，整個叢集就無法工作了！！！因此必須在磁碟中有備份，在磁碟中的備份就是fsImage，存放在namenode節點對應的磁碟中。這樣又會帶來新的問題，當在記憶體中的元資料更新時，如果同時更新fsImage，就會導致效率過低，但如果不更新，就會發生一致性問題，一旦namenode節點斷點，就會產生資料丟失。因此，引入edits.log檔案(只進行追加操作，效率很高)。每當元資料有更新或者新增元資料時，修改記憶體中的元資料並追加到edits.log中。這樣，一旦namenode節點斷電，可以通過fsImage和edits.log的合併，合成元資料。但是，如果長時間新增資料到edit.log中，會導致該檔案資料過大，效率降低，而且一旦斷電，恢復元資料需要的時間過長。因此，需要定期進行fsImage和edits.log的合併，如果這個操作有namenode節點完成，又會效率過低。因此，引入一個新的節點secondaryNamenode，專門用於fsImage和edits.log的合併。

檢查點處理過程的具體步驟如下

1)namenode節點每隔一定時間請求secondaryNamenode合併操作

2)secondaryNamenode請求namenode進行edits.log的滾動，這樣新的編輯操作就能夠進入新的檔案中

3)secondaryNamenode從namenode中下載fsImage和edits.log

4)secondaryNamenode進行fsImage和edits.log的合併,成為fsImage.checkpoint檔案

5)namenode下載合併後的fsImage.checkpoin檔案

6)將fsImage.checkpoint和edits.new命名為原來的檔名(這樣之後fsImage和記憶體中的元資料只差edits.new)

具體的過程如下圖所示