元數(shù)據(jù)是什么

• 在HDFS中，元數(shù)據(jù)主要值得是文件相關的元數(shù)據(jù)，有namenode管理維護。從廣義的角度來說，因為namenode還需要管理眾多的DataNode結(jié)點，因此DataNode的位置和健康狀態(tài)信息也屬于元數(shù)據(jù)

元數(shù)據(jù)管理概述

在hdfs中，文件相關的元數(shù)據(jù)具有兩種類型：

• 文件自身屬性信息
  文件名稱、權限、修改時間，文件大小、復制因子、數(shù)據(jù)塊大小
• 文件塊位置映射信息
  記錄文件塊和DataNode之間的映射信息，即哪個塊位于哪個結(jié)點上
  
  按照存儲形式分別為內(nèi)存元數(shù)據(jù)和元數(shù)據(jù)文件兩種，分別存在內(nèi)存和磁盤上

內(nèi)存元數(shù)據(jù)

• 為了保證用戶操作元數(shù)據(jù)交互高效，延遲低，namenode把所有的元數(shù)據(jù)都存儲在內(nèi)存中，我們叫做內(nèi)存元數(shù)據(jù)。內(nèi)存中的元數(shù)據(jù)是最完整的，包括文件自身屬性、文件塊位置映射信息
• 但是內(nèi)存的致命問題是，斷點數(shù)據(jù)丟失，數(shù)據(jù)不會持久化。因此namenode又輔佐了元數(shù)據(jù)文件來保證運輸局的安全完整

元數(shù)據(jù)文件

元數(shù)據(jù)文件有兩種：fsimage內(nèi)存鏡像文件，Edits log編輯日志

fsimage內(nèi)存鏡像文件

• 是內(nèi)存元數(shù)據(jù)的一個持久化的檢查點。但是fsimage中僅包含hadoop文件中文件自身屬性相關的元數(shù)據(jù)信息，但不包含文件塊位置的信息。文件塊位置信息只存儲在內(nèi)存中，是由DataNode啟動加入集群的時候，向DataNode進行數(shù)據(jù)塊的匯報得到的，并且后續(xù)間斷指定時間進行數(shù)據(jù)塊報告
• 持久化的動作是數(shù)據(jù)從內(nèi)存到磁盤的IO過程。會對namenode正常服務造成一定的影響，不能頻繁的進行持久化

edits log編輯日志

為了避免兩次持久化之間數(shù)據(jù)丟失的問題，又設計了edits log編輯日志文件。文件中記錄的是HDFS所有的更改操作（文件創(chuàng)建，刪除或修改）的日志，文件系統(tǒng)客戶端執(zhí)行的更改操作首先會被記錄到edits文件中

namenode加載元數(shù)據(jù)文件順序

• fsimage和edits文件都是經(jīng)過序列化的，在namenode啟動的時候，它會昂fsimage文件中的內(nèi)容加載到內(nèi)存中，之后再執(zhí)行edits文件中各項操作，是的內(nèi)存中的元數(shù)據(jù)和實際的同步，存在內(nèi)存中的元數(shù)據(jù)支持客戶端的讀操作，也是最完整的元數(shù)據(jù)
• 當客戶端對HDFS中的文件進行新增或者修改操作，操作記錄首先被計入edits日志文件中，當客戶端操作成功后，相應的元數(shù)據(jù)會更新到內(nèi)存元數(shù)據(jù)中。因為fsimage文件一般都很大（GB級別的很常見），如果所有的更新操作都往fsimage文件中添加，這樣會導致系統(tǒng)運行的十分緩慢
• HDFS這種設計實現(xiàn)著手于：一時內(nèi)存中的數(shù)據(jù)更新、查詢快，極大縮短操作響應時間；二是內(nèi)存中元數(shù)據(jù)丟失風險頗高（斷電T_T），因此輔佐元數(shù)據(jù)鏡像文件（fsimage）+編輯日志文件（edits）的備份機制進行確保元數(shù)據(jù)的安全
• namenode維護整個文件系統(tǒng)元數(shù)據(jù)。因此，元數(shù)據(jù)的準確管理，影響著HDFS提供文件存儲服務的能力

元數(shù)據(jù)管理相關目錄文件

• namenode元數(shù)據(jù)存儲目錄由參數(shù)：dfs.namenode.name.dir指定

• 格式化完成之后，將會在$hdfs.namenode.name.dir/current目錄下創(chuàng)建如下的文件：
  

• dfs.namenode.name.dir是在hdfs-site.xml文件中配置的，默認值如下
  

元數(shù)據(jù)相關文件

VERSION

• namespaceID/clusterID/blockpollID
  這些都是HDFS集群的唯一標識符。標識符被用來防止DataNodes意外注冊到另一個集群中的namenode上。這些寶石在聯(lián)邦（federation）部署中特別重要。聯(lián)邦模式下，會有多個namenode獨立工作。每個namenode提供惟一的命名空阿靜（namespaceID），并管理一組唯一的文件塊池（blockpoolID）。clusterID將整個集群結(jié)合在一起作為單個邏輯單元，在集群中所有節(jié)點上都是一樣的。
• storageType
  說明這個文件存儲的是什么進程的數(shù)據(jù)結(jié)構信息。如果是DataNode節(jié)點，storageType=DATA_NODE
• cTime
  namenode存儲系統(tǒng)創(chuàng)建時間，首次格式化文件系統(tǒng)這個屬性是0，當問文件系統(tǒng)升級之后的時間戳
• layoutVersion
  HDFS元數(shù)據(jù)格式的版本。HDFS升級時會進行更新
  

seen_txid

• 包含上一次checkpoint時的最后一個事務ID，這不是namenode接受的最后一個事務ID
• seen_txid內(nèi)容不會在每個事務性操作生都更新，只會在checkpoint時更新
• namenode啟動時會檢查seen_txid文件，以驗證它至少可以加載該數(shù)目的事務。如果無法驗證加載事務，namenode將終止啟動
  

元數(shù)據(jù)文件查看（OIV,OEV）

• fsimage文件是hadoop文件系統(tǒng)元數(shù)據(jù)的一個永久性的檢查點，包含hadoop文件系統(tǒng)中的所有目錄和文件idnode的序列化信息；對于文件來說，包含的信息有修改的時間、訪問時間、塊大小和組成一個文件塊信息等；而對于目錄來說，包含的主要有修改時間，訪問控制權限等信息
• oiv是offline image viewer的縮寫，可將hdfs fsimage文件的內(nèi)容轉(zhuǎn)儲為人類可讀的格式
• 常用命令：hdfs oiv -i fsiamge_00000000000050 -p XML -o fsimage.xml
  
• edits log文件存放的是hadoop文件系統(tǒng)所有更新的操作記錄日志
• 文件系統(tǒng)客戶端執(zhí)行的所有寫操作首先會被記錄到edits文件中
• oev是offline edits viewer（離線edits查看器）的縮寫，該工具不需要hadoop集群處于運行狀態(tài)
• 命令：hdfs oev -i edits_0000000000000000090-00000000000000000000089 -o edits.xml
• 在輸出文件中，每個RECORD記錄了一次操作，示例如下：
  

SecondaryNameNode介紹

• SNN可以減小edits logs文件的大小和得到一個最新的fsimage文件，這樣也會減小在namenode上的壓力

checkpoint機制

1.checkpoint核心是把fsimage與edits log合并生成一個新的fsimage的過程，然后NN會生成一個新的編輯日志文件：edits new，便于記錄后續(xù)操作記錄
2. SNN會將舊的edits log文件和上次fsimage復制到自己本地（使用HTTP GET方式）
3. SNN首先將fsimage載入到內(nèi)存，然后一條一條的執(zhí)行edits文件中的操作，使得內(nèi)存中的fsimage不斷更新，這個過程就是edits和fsimage文件合并。合并結(jié)束，SNN將內(nèi)存中的數(shù)據(jù)dump生成一個新的fsimage文件
4. SNN將新生的Fimage new文件復制到NN節(jié)點。至此剛好是一個輪回，等待下一次checkpoint觸發(fā)secondarynamenode進行工作，一直這樣循環(huán)操作

SNN Checkpoint–觸發(fā)機制

• core-site.xml
  dfs.namenode.checkpoint.period=3600 //兩次連續(xù)的checkpoint之間的時間間隔。默認一小時
  dfs.namenode.checkpoint.txns=1000000 //最大沒有執(zhí)行checkpoint事務的數(shù)量，滿足將強制執(zhí)行緊急checkpoint，及時尚未達到檢查點周期。默認100萬事務數(shù)量

元數(shù)據(jù)文件恢復

namenode存儲多目錄

• namenode元數(shù)據(jù)存儲目錄由參數(shù):dfs.namenode.name.dir
• dfs.namenode.name.dir屬性可以配置多個目錄，各個目錄存儲的文件結(jié)構和內(nèi)容都完全一樣，相當于備份，這樣做的好處就是當其中一個目錄壞了，也不會影響到hadoop的元數(shù)據(jù)，特別是當其中一個目錄是NFS（網(wǎng)絡文件系統(tǒng)network filesystem）之上，及時你這臺機器損壞了，元數(shù)據(jù)也得到保存

從SNN中恢復

• SNN 在checkpoint的收會將fsimage和edits log下載到自己本機上本地存儲目錄下。并且在checkpoint之后也不會刪除
• 如果NN中的fsimage真的出問題了，還是可以用SNN中的fsimage替換一下NN中的fsimage，雖然已經(jīng)不是最新的fsimage，但是我們可可以將損失減小到最少