大數(shù)據(jù)離線階段Day9之HDFS元數(shù)據(jù)管理機(jī)制

　　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詢問(wèn)datanode得到的，并且間斷的更新。

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

　　fsimage和edits文件都是經(jīng)過(guò)序列化的，在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)閒simage文件一般都很大(GB級(jí)別的很常見(jiàn))，如果所有的更新操作都往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)文件

　　在Hadoop的HDFS首次部署好配置文件之后，并不能馬上啟動(dòng)使用，而是先要對(duì)文件系統(tǒng)進(jìn)行格式化。需要在NameNode(NN)節(jié)點(diǎn)上進(jìn)行如下的操作：

　　$HADOOP_HOME/bin/hdfs namenode –format

　　在這里要注意兩個(gè)概念，一個(gè)是文件系統(tǒng)，此時(shí)的文件系統(tǒng)在物理上還不存在;二就是此處的格式化并不是指?jìng)鹘y(tǒng)意義上的本地磁盤格式化，而是一些清除與準(zhǔn)備工作。

　　格式化完成之后，將會(huì)在$dfs.namenode.name.dir/current目錄下創(chuàng)建如下的文件結(jié)構(gòu)，這個(gè)目錄也正是namenode元數(shù)據(jù)相關(guān)的文件目錄：

　　其中的dfs.namenode.name.dir是在hdfs-site.xml文件中配置的，默認(rèn)值如下：

　　dfs.namenode.name.dir屬性可以配置多個(gè)目錄，各個(gè)目錄存儲(chǔ)的文件結(jié)構(gòu)和內(nèi)容都完全一樣，相當(dāng)于備份，這樣做的好處是當(dāng)其中一個(gè)目錄損壞了，也不會(huì)影響到Hadoop的元數(shù)據(jù)，特別是當(dāng)其中一個(gè)目錄是NFS(網(wǎng)絡(luò)文件系統(tǒng)Network File System，NFS)之上，即使你這臺(tái)機(jī)器損壞了，元數(shù)據(jù)也得到保存。

　　下面對(duì)$dfs.namenode.name.dir/current/目錄下的文件進(jìn)行解釋。

　　VERSION

　　namespaceID=934548976

　　clusterID=CID-cdff7d73-93cd-4783-9399-0a22e6dce196

　　cTime=0

　　storageType=NAME_NODE

　　blockpoolID=BP-893790215-192.168.24.72-1383809616115

　　layoutVersion=-47

　　namespaceID/clusterID/blockpoolID 這些都是HDFS集群的唯一標(biāo)識(shí)符。標(biāo)識(shí)符被用來(lái)防止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說(shuō)明這個(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ù)。

　　補(bǔ)充說(shuō)明：

　　格式化集群的時(shí)候，可以指定集群的cluster_id，但是不能與環(huán)境中其他集群有沖突。如果沒(méi)有提供cluster_id，則會(huì)自動(dòng)生成一個(gè)唯一的ClusterID。

　　$HADOOP_HOME/bin/hdfs namenode -format -clusterId

　　seen_txid

　　$dfs.namenode.name.dir/current/seen_txid非常重要，是存放transactionId的文件，format之后是0，它代表的是namenode里面的edits_*文件的尾數(shù)，namenode重啟的時(shí)候，會(huì)按照seen_txid的數(shù)字，循序從頭跑edits_0000001~到seen_txid的數(shù)字。所以當(dāng)你的hdfs發(fā)生異常重啟的時(shí)候，一定要比對(duì)seen_txid內(nèi)的數(shù)字是不是你edits最后的尾數(shù)。

　　Fsimage & edits

　　$dfs.namenode.name.dir/current目錄下在format的同時(shí)也會(huì)生成fsimage和edits文件，及其對(duì)應(yīng)的md5校驗(yàn)文件。

　　3. secondary namenode

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

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

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

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

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

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

　　SecondaryNameNode就是來(lái)幫助解決上述問(wèn)題的，它的職責(zé)是合并NameNode的edit logs到fsimage文件中。

　　4. Checkpoint

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

　　4.1. Checkpoint詳細(xì)步驟

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

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

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

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

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

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

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

　　4.2. Checkpoint觸發(fā)條件

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

　　dfs.namenode.checkpoint.period

　　3600

　　兩次連續(xù)的checkpoint之間的時(shí)間間隔。默認(rèn)1小時(shí)

　　dfs.namenode.checkpoint.txns

　　1000000

　　最大的沒(méi)有執(zhí)行checkpoint事務(wù)的數(shù)量，滿足將強(qiáng)制執(zhí)行緊急checkpoint，即使尚未達(dá)到檢查點(diǎn)周期。默認(rèn)設(shè)置為100萬(wàn)。

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

作者 ：黑馬程序員大數(shù)據(jù)培訓(xùn)學(xué)院
首發(fā)：http://cloud.itheima.com