大家都知道hadoop是分布式離線批處理框架，主從架構(gòu),，namenode是主節(jié)點(diǎn),，datanode是從節(jié)點(diǎn)，

hadoop整體分為：

        HDFS：分布式文件存儲(chǔ)系統(tǒng)

        MapReduce：分布式離線并行計(jì)算框架

        yarn：分布式資源調(diào)度管理框架

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

　　HDFS元數(shù)據(jù),，按類型分,，主要包括以下幾個(gè)部分：

　　　　1、文件,、目錄自身的屬性信息,，例如文件名，目錄名,，修改信息等,。

　　　　2、文件記錄的信息的存儲(chǔ)相關(guān)的信息,，例如存儲(chǔ)塊信息,，分塊情況，副本個(gè)數(shù)等,。

　　　　3,、記錄 HDFS 的 Datanode 的信息,，用于 DataNode 的管理。

　　按形式分為內(nèi)存元數(shù)據(jù)和元數(shù)據(jù)文件兩種,，分別存在內(nèi)存和磁盤上,。

　　HDFS 磁盤上元數(shù)據(jù)文件分為兩類，用于持久化存儲(chǔ)：

　　fsimage 鏡像文件：是元數(shù)據(jù)的一個(gè)持久化的檢查點(diǎn),，包含 Hadoop 文件系統(tǒng)中的所有目錄和文件元數(shù)據(jù)信息,，但不包含文件塊位置的信息。文件塊位置信息只存儲(chǔ)在內(nèi)存中,，是在 datanode 加入集群的時(shí)候,，namenode 詢問 datanode 得到的，并且間斷的更新,。

　　Edits 編輯日志：存放的是 Hadoop 文件系統(tǒng)的所有更改操作（文件創(chuàng)建,，刪除或修改）的日志，文件系統(tǒng)客戶端執(zhí)行的更改操作首先會(huì)被記錄到 edits 文件中,。

　　fsimage 和 edits 文件都是經(jīng)過序列化的,，在 NameNode 啟動(dòng)的時(shí)候，它會(huì)將 fsimage文件中的內(nèi)容加載到內(nèi)存中,，之后再執(zhí)行 edits 文件中的各項(xiàng)操作,，使得內(nèi)存中的元數(shù)據(jù)和實(shí)際的同步，存在內(nèi)存中的元數(shù)據(jù)支持客戶端的讀操作,，也是最完整的元數(shù)據(jù),。

　　當(dāng)客戶端對(duì) HDFS 中的文件進(jìn)行新增或者修改操作，操作記錄首先被記入 edits 日志文件中,，當(dāng)客戶端操作成功后,，相應(yīng)的元數(shù)據(jù)會(huì)更新到內(nèi)存元數(shù)據(jù)中。因?yàn)?fsimage 文件一般都很大,，如果所有的更新操作都往 fsimage 文件中添加,，這樣會(huì)導(dǎo)致系統(tǒng)運(yùn)行的十分緩慢。

　　HDFS 這種設(shè)計(jì)實(shí)現(xiàn)于：一是內(nèi)存中數(shù)據(jù)更新,、查詢快,，極大縮短了操作響應(yīng)時(shí)間；二是內(nèi)存中元數(shù)據(jù)丟失風(fēng)險(xiǎn)頗高（斷電等）,，因此輔佐元數(shù)據(jù)鏡像文件fsimage+編輯日志文件edits的備份機(jī)制進(jìn)行確保元數(shù)據(jù)的安全,。

　　NameNode 維護(hù)整個(gè)文件系統(tǒng)元數(shù)據(jù)。因此,，元數(shù)據(jù)的準(zhǔn)確管理,，影響著 HDFS 提供文件存儲(chǔ)服務(wù)的能力。

2. 元數(shù)據(jù)目錄相關(guān)文件

1.首先當(dāng)我們搭建好hadoop集群之后我們需要格式化namenode,，以下配置文件是用來存儲(chǔ)namenode的元數(shù)據(jù)目錄

當(dāng)我們格式化namenode之后會(huì)在此dfs目錄下生成元數(shù)據(jù)文件

 dfs文件夾內(nèi)保存的是關(guān)于namenode與datanode的信息

 data：文件夾保存的是datanode信息

name：文件夾保存的是namenode的信息

namesecondary：保存的是secondarynamenode信息

當(dāng)我們格式化namenode時(shí)候我們會(huì)發(fā)現(xiàn)這個(gè)路徑下會(huì)產(chǎn)生Fsimage和edits文件,，也就是說在格式化的時(shí)候會(huì)初始化鏡像文件

fsimage 和 edits 文件都是經(jīng)過序列化的,，所以我們無需查看內(nèi)容。

namespaceID/clusterID/blockpoolID 這些都是 HDFS 集群的唯一標(biāo)識(shí)符,。標(biāo)識(shí)符被用來防止 DataNodes 意外注冊(cè)到另一個(gè)集群中的 namenode 上,。這些標(biāo)識(shí)在聯(lián)邦（Federation）部署中特別重要。聯(lián)邦模式下,，會(huì)有多個(gè) NameNode 獨(dú)立工作,。每個(gè)的 NameNode 提供唯一的命名空間（namespaceID），并管理一組唯一的文件塊池（blockpoolID）,。clusterID 將整個(gè)集群結(jié)合在一起作為單個(gè)邏輯單元,，在集群中的所有節(jié)點(diǎn)上都是一樣的。

　　storageType 說明這個(gè)文件存儲(chǔ)的是什么進(jìn)程的數(shù)據(jù)結(jié)構(gòu)信息（如果是 DataNode,，storageType=DATA_NODE）,；

　　cTime NameNode 存儲(chǔ)系統(tǒng)創(chuàng)建時(shí)間，首次格式化文件系統(tǒng)這個(gè)屬性是 0,，當(dāng)文件系統(tǒng)升級(jí)之后,，該值會(huì)更新到升級(jí)之后的時(shí)間戳；

　　layoutVersion 表示 HDFS 永久性數(shù)據(jù)結(jié)構(gòu)的版本信息,，是一個(gè)負(fù)整數(shù),。

3.SecondaryNamenode

NameNode 職責(zé)是管理元數(shù)據(jù)信息,，DataNode 的職責(zé)是負(fù)責(zé)數(shù)據(jù)具體存儲(chǔ),，那么SecondaryNameNode 的作用是什么？對(duì)很多初學(xué)者來說是非常迷惑的,。它為什么會(huì)出現(xiàn)在HDFS 中,。從它的名字上看，它給人的感覺就像是 NameNode 的備份,。但它實(shí)際上卻不是,。

　　       當(dāng) HDFS 集群運(yùn)行一段事件后，就會(huì)出現(xiàn)下面一些問題：

　　　　edit logs 文件會(huì)變的很大,，怎么去管理這個(gè)文件是一個(gè)挑戰(zhàn),。

　　　　NameNode 重啟會(huì)花費(fèi)很長(zhǎng)時(shí)間，因?yàn)橛泻芏喔膭?dòng)要合并到 fsimage 文件上,。

　　　　如果 NameNode 掛掉了,，那就丟失了一些改動(dòng)。因?yàn)榇藭r(shí)的 fsimage 文件非常舊,。

　　因此為了克服這個(gè)問題,，我們需要一個(gè)易于管理的機(jī)制來幫助我們 減小 edit logs 文件的大小和得到一個(gè)最新的fsimage 文件，這樣也會(huì)減小在 NameNode 上的壓力,。這樣當(dāng)系統(tǒng)發(fā)生問題時(shí),，我們能夠回滾到最新的一次恢復(fù)點(diǎn)上,。

　　SecondaryNameNode 就是來幫助解決上述問題的，它的職責(zé)是合并 NameNode 的 editlogs 到 fsimage 文件中,。

 Checkpoint

　　每達(dá)到觸發(fā)條件,，會(huì)由 secondary namenode 將 namenode 上積累的所有 edits 和一個(gè)最新的 fsimage 下載到本地，并加載到內(nèi)存進(jìn)行 merge（這個(gè)過程稱為 checkpoint）,，如下圖所示：

• NameNode 管理著元數(shù)據(jù)信息,，其中有兩類持久化元數(shù)據(jù)文件：edits 操作日志文件和fsimage 元數(shù)據(jù)鏡像文件。新的操作日志不會(huì)立即與 fsimage 進(jìn)行合并,，也不會(huì)刷到NameNode 的內(nèi)存中,，而是會(huì)先寫到 edits 中(因?yàn)楹喜⑿枰拇罅康馁Y源)，操作成功之后更新至內(nèi)存,。

• 有 dfs.namenode.checkpoint.period 和 dfs.namenode.checkpoint.txns 兩個(gè)配置,，只要達(dá)到這兩個(gè)條件任何一個(gè)，secondarynamenode 就會(huì)執(zhí)行 checkpoint 的操作,。

• 當(dāng)觸發(fā) checkpoint 操作時(shí),，NameNode 會(huì)生成一個(gè)新的 edits 即上圖中的 edits.new 文件，同時(shí) SecondaryNameNode 會(huì)將 edits 文件和 fsimage 復(fù)制到本地（HTTP GET 方式）,。

• secondarynamenode 將下載下來的 fsimage 載入到內(nèi)存,，然后一條一條地執(zhí)行 edits 文件中的各項(xiàng)更新操作，使得內(nèi)存中的 fsimage 保存最新,，這個(gè)過程就是edits 和fsimage文件合并,，生成一個(gè)新的 fsimage 文件即上圖中的 Fsimage.ckpt 文件。

• secondarynamenode 將新生成的 Fsimage.ckpt 文件復(fù)制到 NameNode 節(jié)點(diǎn),。

• 在 NameNode 節(jié)點(diǎn)的 edits.new 文件和 Fsimage.ckpt 文件會(huì)替換掉原來的 edits 文件和 fsimage 文件,，至此剛好是一個(gè)輪回，即在 NameNode 中又是 edits 和 fsimage 文件,。

• 等待下一次 checkpoint 觸發(fā) SecondaryNameNode 進(jìn)行工作,，一直這樣循環(huán)操作。

•  Checkpoint 觸發(fā)條件

  　　Checkpoint 操作受兩個(gè)參數(shù)控制,，可以通過 core-site.xml 進(jìn)行配置：

• <property>
  　　<name>dfs.namenode.checkpoint.period</name>
  　　<value>3600</value>
  　　<description>
  　　　　兩次連續(xù)的 checkpoint 之間的時(shí)間間隔,。默認(rèn) 1 小時(shí)
  　　</description>
  </property>
  <property>
  　　<name>dfs.namenode.checkpoint.txns</name>
  　　<value>1000000</value>
  　　<description>
  　　　　最大的沒有執(zhí)行 checkpoint 事務(wù)的數(shù)量，滿足將強(qiáng)制執(zhí)行緊急 checkpoint,，即使
  　　　　尚未達(dá)到檢查點(diǎn)周期,。默認(rèn)設(shè)置為 100 萬。
  　　</description>
  </property>

         從上面的描述我們可以看出,，SecondaryNamenode 根本就不是 Namenode 的一個(gè)熱備,，其只是將 fsimage 和 edits 合并。其擁有的 fsimage 不是最新的，因?yàn)樵谒麖?NameNode 下載 fsimage 和 edits 文件時(shí)候,，新的更新操作已經(jīng)寫到 edit.new 文件中去了,。而這些更新在 SecondaryNamenode 是沒有同步到的！當(dāng)然,， 如果 NameNode 中的 fsimage 真的出問題了,，還是可以用SecondaryNamenode 中的 fsimage 替換一下NameNode 上的 fsimage ，雖然已經(jīng)不是最新的 fsimage ,，但是我們可以將損失減小到最少