接下來看一些具體的東西。
從形式上講，元資料可分為記憶體元資料和元資料檔案兩種。其中namenode在記憶體中維護整個檔案系統的元資料映象，用於hdfs的管理；元資料檔案則用於持久化儲存。
namenode將檔案系統的元資料以不同的檔案儲存在本地磁碟中，其中最重要的兩個檔案是fsimage 和edits。不懂fsimage和edits可以看這邊。和資料庫一樣，fsimage包含檔案系統元資料的完整快照，而edits僅包含元資料的增量修改。通俗地理解是這樣的：由於所有的元資料位於記憶體，其大小隨檔案系統的規模增大而增大，如果每次都將整個記憶體元資料匯出磁碟，將會帶來很大的系統開銷，所以hdfs在實現時，沒有採用定期匯出元資料的方法，而是採用元資料映象檔案（fsimage）+日誌檔案（edits）的備份機制，其中映象檔案是某一時刻記憶體元資料的真實組織情況，而日誌檔案則記錄了該時刻以後所有的元資料操作 。
這樣的機制存在乙個問題：namenode在為集群提供服務時可能無法提供足夠的資源----cpu或ram來支援此運算。為了解決這一問題，引入了次namenode
接下來是namenode和次namenode的互動示意圖：
預設情況下，該過程每小時發生一次，或者當namenode的edits檔案大小達到預設的64mb時也會被觸發。儘管後面我們會研究如何改變這些配置，但通常來說無需改變。在新版本的hadoop中，通過使用預定義的事務次數而不是檔案大小來觸發該過程。
元資料管理
大資料倉儲越來越重視元資料的管理，但是元資料怎麼管理，還處於探索階段。這樣帶來的弊端顯而易見，就是1 及時性達不到，2 準確性達不到，3 同步性也達不到。它只是結項的必交的文件而已。二 越來越多的角色的人使用數倉，迫切需要乙個介面展示具體指的意思，業務統計口徑等，用乙個web介面展示，但是後端還是e...
元資料管理
元資料管理的核心功能如下 在操作方式上分為自動採集和手動採集兩種 同時，提供採集日誌資訊的檢視，檢查採集是否成功。檢視採集日誌可以查詢到採集任務的如下資訊 開始時間 任務狀態 結束時間 過程日誌，採集的數量等等。元資料採集完成後，儲存在資料庫中，支撐包括元資料統計 查詢 血緣分析 影響性分析 資料資...
基於屬性和連線的檔案系統元資料管理方法
傳統檔案系統結構對於檔案間的關聯以及基於內容的元資料支援度不足，通常都是將面向檔案的元資料資訊儲存在單獨的資料庫或者磁碟上，要受到結構上固有的限制，並且無法支援使用者自定義的檔案關聯資訊。為了解決這個問題，提出了一種新型檔案系統linking file system lifs 能夠支援使用者定義或者...