首頁技術(shù)文章正文

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

更新時(shí)間:2018-10-24 來源:黑馬程序員 瀏覽量:

  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)閒simage文件一般都很大(GB級(jí)別的很常見),如果所有的更新操作都往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í)符被用來防止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ù)。

  補(bǔ)充說明:

  格式化集群的時(shí)候,可以指定集群的cluster_id,但是不能與環(huán)境中其他集群有沖突。如果沒有提供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é)者來說是非常迷惑的。它為什么會(huì)出現(xiàn)在HDFS中。從它的名字上看,它給人的感覺就像是NameNode的備份。但它實(shí)際上卻不是。

  大家猜想一下,當(dāng)HDFS集群運(yùn)行一段事件后,就會(huì)出現(xià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è)問題,我們需要一個(gè)易于管理的機(jī)制來幫助我們減小edit logs文件的大小和得到一個(gè)最新的fsimage文件,這樣也會(huì)減小在NameNode上的壓力。這跟Windows的恢復(fù)點(diǎn)是非常像的,Windows的恢復(fù)點(diǎn)機(jī)制允許我們對(duì)OS進(jìn)行快照,這樣當(dāng)系統(tǒng)發(fā)生問題時(shí),我們能夠回滾到最新的一次恢復(fù)點(diǎn)上。

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

  4. Checkpoint

  每達(dá)到觸發(fā)條件,會(huì)由secondary namenode將namenode上積累的所有edits和一個(gè)最新的fsimage下載到本地,并加載到內(nèi)存進(jìn)行merge(這個(gè)過程稱為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將下載下來的fsimage載入到內(nèi)存,然后一條一條地執(zhí)行edits文件中的各項(xiàng)更新操作,使得內(nèi)存中的fsimage保存最新,這個(gè)過程就是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ì)替換掉原來的edits文件和fsimage文件,至此剛好是一個(gè)輪回,即在NameNode中又是edits和fsimage文件。

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

  4.2. Checkpoint觸發(fā)條件

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

  

  dfs.namenode.checkpoint.period

  3600

  

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

  

  

  

  dfs.namenode.checkpoint.txns

  1000000

  

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

  

  

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



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

分享到:
在線咨詢 我要報(bào)名
和我們?cè)诰€交談!