namenode 中的元資料是儲存在**的？
首先，我們做個假設，如果儲存在 namenode 節點的磁碟中，因為經常需要進行隨機訪問，還有響應客戶請求，必然是效率過低。因此，元資料需要存放在記憶體中。但如果只存在記憶體中，一旦斷電，元資料丟失，整個集群就無法工作了。因此產生在磁碟中備份元資料的fsimage。這樣又會帶來新的問題，當在記憶體中的元資料更新時，如果同時更新 fsimage，就會導致效率過低，但如果不更新，就會發生一致性問題，一旦 namenode 節點斷電，就會產生資料丟失。因此，引入 edits 檔案(只進行追加操作，效率很高)。每當元資料有更新或者新增元資料時，修改記憶體中的元資料並追加到 edits 中。這樣，一旦 namenode 節點斷電，可以通
過 fsimage 和 edits 的合併，合成元資料。
但是，如果長時間新增資料到 edits 中，會導致該檔案資料過大，效率降低，而且一旦斷電，恢復元資料需要的時間過長。因此，需要定期進行 fsimage 和 edits 的合併，如果這個操作由namenode節點完成，又會效率過低。因此，引入乙個新的節點secondarynamenode，專門用於 fsimage 和 edits 的合併。
NameNode資料管理機制
namenode是整個檔案系統的管理節點。它維護著整個檔案系統的檔案目錄樹，檔案 目錄的元資訊和每個檔案對應的資料塊列表。接收使用者的操作請求 檔案包括 fsimage 元資料映象檔案。儲存某一時段namenode記憶體元資料資訊。edits 操作日誌檔案。fstime 儲存最近一次checkpoi...
hadoop之namenode檢查點機制
namenode使用兩個檔案來保留其命名空間 fsimage，它是命名空間和編輯的最新檢查點，是自檢查點以來命名空間更改的日誌 日誌 當namenode啟動時，它會合併fsimage和edits journal以提供檔案系統元資料的最新檢視。namenode然後用新的hdfs狀態覆蓋fsimage並...
NameNode元資料管理機制
1.使用者上傳檔案的的過程 解析 使用者向nn申請上傳檔案 nn將分配的dn資訊記錄追加在edit.log的檔案中 nn將分配的dn資訊返回給客戶端 客戶端將檔案上傳到各個節點上 客戶端將上傳成功的資訊返回給nn節點，nn將edit.log檔案中的內容寫入記憶體中，一次上傳檔案的操作完成了 當edi...