更新時間:2018-10-24 來源:黑馬程序員 瀏覽量:
1. 元數據管理概述
HDFS元數據,按類型分,主要包括以下幾個部分:
1、文件、目錄自身的屬性信息,例如文件名,目錄名,修改信息等。
2、文件記錄的信息的存儲相關的信息,例如存儲塊信息,分塊情況,副本個數等。
3、記錄HDFS的Datanode的信息,用于DataNode的管理。
按形式分為內存元數據和元數據文件兩種,分別存在內存和磁盤上。
HDFS磁盤上元數據文件分為兩類,用于持久化存儲:
fsimage 鏡像文件:是元數據的一個持久化的檢查點,包含Hadoop文件系統(tǒng)中的所有目錄和文件元數據信息,但不包含文件塊位置的信息。文件塊位置信息只存儲在內存中,是在 datanode加入集群的時候,namenode詢問datanode得到的,并且間斷的更新。
Edits 編輯日志:存放的是Hadoop文件系統(tǒng)的所有更改操作(文件創(chuàng)建,刪除或修改)的日志,文件系統(tǒng)客戶端執(zhí)行的更改操作首先會被記錄到edits文件中。
fsimage和edits文件都是經過序列化的,在NameNode啟動的時候,它會將fsimage文件中的內容加載到內存中,之后再執(zhí)行edits文件中的各項操作,使得內存中的元數據和實際的同步,存在內存中的元數據支持客戶端的讀操作,也是最完整的元數據。
當客戶端對HDFS中的文件進行新增或者修改操作,操作記錄首先被記入edits日志文件中,當客戶端操作成功后,相應的元數據會更新到內存元數據中。因為fsimage文件一般都很大(GB級別的很常見),如果所有的更新操作都往fsimage文件中添加,這樣會導致系統(tǒng)運行的十分緩慢。
HDFS這種設計實現(xiàn)著手于:一是內存中數據更新、查詢快,極大縮短了操作響應時間;二是內存中元數據丟失風險頗高(斷電等),因此輔佐元數據鏡像文件(fsimage)+編輯日志文件(edits)的備份機制進行確保元數據的安全。
NameNode維護整個文件系統(tǒng)元數據。因此,元數據的準確管理,影響著HDFS提供文件存儲服務的能力。
2. 元數據目錄相關文件
在Hadoop的HDFS首次部署好配置文件之后,并不能馬上啟動使用,而是先要對文件系統(tǒng)進行格式化。需要在NameNode(NN)節(jié)點上進行如下的操作:
$HADOOP_HOME/bin/hdfs namenode –format
在這里要注意兩個概念,一個是文件系統(tǒng),此時的文件系統(tǒng)在物理上還不存在;二就是此處的格式化并不是指傳統(tǒng)意義上的本地磁盤格式化,而是一些清除與準備工作。
格式化完成之后,將會在$dfs.namenode.name.dir/current目錄下創(chuàng)建如下的文件結構,這個目錄也正是namenode元數據相關的文件目錄:
其中的dfs.namenode.name.dir是在hdfs-site.xml文件中配置的,默認值如下:
dfs.namenode.name.dir屬性可以配置多個目錄,各個目錄存儲的文件結構和內容都完全一樣,相當于備份,這樣做的好處是當其中一個目錄損壞了,也不會影響到Hadoop的元數據,特別是當其中一個目錄是NFS(網絡文件系統(tǒng)Network File System,NFS)之上,即使你這臺機器損壞了,元數據也得到保存。
下面對$dfs.namenode.name.dir/current/目錄下的文件進行解釋。
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集群的唯一標識符。標識符被用來防止DataNodes意外注冊到另一個集群中的namenode上。這些標識在聯(lián)邦(federation)部署中特別重要。聯(lián)邦模式下,會有多個NameNode獨立工作。每個的NameNode提供唯一的命名空間(namespaceID),并管理一組唯一的文件塊池(blockpoolID)。clusterID將整個集群結合在一起作為單個邏輯單元,在集群中的所有節(jié)點上都是一樣的。
storageType說明這個文件存儲的是什么進程的數據結構信息(如果是DataNode,storageType=DATA_NODE);
cTime NameNode存儲系統(tǒng)創(chuàng)建時間,首次格式化文件系統(tǒng)這個屬性是0,當文件系統(tǒng)升級之后,該值會更新到升級之后的時間戳;
layoutVersion表示HDFS永久性數據結構的版本信息,是一個負整數。
補充說明:
格式化集群的時候,可以指定集群的cluster_id,但是不能與環(huán)境中其他集群有沖突。如果沒有提供cluster_id,則會自動生成一個唯一的ClusterID。
$HADOOP_HOME/bin/hdfs namenode -format -clusterId
seen_txid
$dfs.namenode.name.dir/current/seen_txid非常重要,是存放transactionId的文件,format之后是0,它代表的是namenode里面的edits_*文件的尾數,namenode重啟的時候,會按照seen_txid的數字,循序從頭跑edits_0000001~到seen_txid的數字。所以當你的hdfs發(fā)生異常重啟的時候,一定要比對seen_txid內的數字是不是你edits最后的尾數。
Fsimage & edits
$dfs.namenode.name.dir/current目錄下在format的同時也會生成fsimage和edits文件,及其對應的md5校驗文件。
3. secondary namenode
NameNode職責是管理元數據信息,DataNode的職責是負責數據具體存儲,那么SecondaryNameNode的作用是什么?對很多初學者來說是非常迷惑的。它為什么會出現(xiàn)在HDFS中。從它的名字上看,它給人的感覺就像是NameNode的備份。但它實際上卻不是。
大家猜想一下,當HDFS集群運行一段事件后,就會出現(xiàn)下面一些問題:
l edit logs文件會變的很大,怎么去管理這個文件是一個挑戰(zhàn)。
l NameNode重啟會花費很長時間,因為有很多改動要合并到fsimage文件上。
l 如果NameNode掛掉了,那就丟失了一些改動。因為此時的fsimage文件非常舊。
因此為了克服這個問題,我們需要一個易于管理的機制來幫助我們減小edit logs文件的大小和得到一個最新的fsimage文件,這樣也會減小在NameNode上的壓力。這跟Windows的恢復點是非常像的,Windows的恢復點機制允許我們對OS進行快照,這樣當系統(tǒng)發(fā)生問題時,我們能夠回滾到最新的一次恢復點上。
SecondaryNameNode就是來幫助解決上述問題的,它的職責是合并NameNode的edit logs到fsimage文件中。
4. Checkpoint
每達到觸發(fā)條件,會由secondary namenode將namenode上積累的所有edits和一個最新的fsimage下載到本地,并加載到內存進行merge(這個過程稱為checkpoint),如下圖所示:
4.1. Checkpoint詳細步驟
l NameNode管理著元數據信息,其中有兩類持久化元數據文件:edits操作日志文件和fsimage元數據鏡像文件。新的操作日志不會立即與fsimage進行合并,也不會刷到NameNode的內存中,而是會先寫到edits中(因為合并需要消耗大量的資源),操作成功之后更新至內存。
l 有dfs.namenode.checkpoint.period和dfs.namenode.checkpoint.txns 兩個配置,只要達到這兩個條件任何一個,secondarynamenode就會執(zhí)行checkpoint的操作。
l 當觸發(fā)checkpoint操作時,NameNode會生成一個新的edits即上圖中的edits.new文件,同時SecondaryNameNode會將edits文件和fsimage復制到本地(HTTP GET方式)。
l secondarynamenode將下載下來的fsimage載入到內存,然后一條一條地執(zhí)行edits文件中的各項更新操作,使得內存中的fsimage保存最新,這個過程就是edits和fsimage文件合并,生成一個新的fsimage文件即上圖中的Fsimage.ckpt文件。
l secondarynamenode將新生成的Fsimage.ckpt文件復制到NameNode節(jié)點。
l 在NameNode節(jié)點的edits.new文件和Fsimage.ckpt文件會替換掉原來的edits文件和fsimage文件,至此剛好是一個輪回,即在NameNode中又是edits和fsimage文件。
l 等待下一次checkpoint觸發(fā)SecondaryNameNode進行工作,一直這樣循環(huán)操作。
4.2. Checkpoint觸發(fā)條件
Checkpoint操作受兩個參數控制,可以通過core-site.xml進行配置:
dfs.namenode.checkpoint.period
3600
兩次連續(xù)的checkpoint之間的時間間隔。默認1小時
dfs.namenode.checkpoint.txns
1000000
最大的沒有執(zhí)行checkpoint事務的數量,滿足將強制執(zhí)行緊急checkpoint,即使尚未達到檢查點周期。默認設置為100萬。
從上面的描述我們可以看出,SecondaryNamenode根本就不是Namenode的一個熱備,其只是將fsimage和edits合并。其擁有的fsimage不是最新的,因為在他從NameNode下載fsimage和edits文件時候,新的更新操作已經寫到edit.new文件中去了。而這些更新在SecondaryNamenode是沒有同步到的!當然,如果NameNode中的fsimage真的出問題了,還是可以用SecondaryNamenode中的fsimage替換一下NameNode上的fsimage,雖然已經不是最新的fsimage,但是我們可以將損失減小到最少!
作者
:黑馬程序員大數據培訓學院
首發(fā):http://cloud.itheima.com