北京市保障房建設官方網(wǎng)站能讓網(wǎng)絡非常流暢的軟件
元數(shù)據(jù)管理
- 元數(shù)據(jù)是什么
- 元數(shù)據(jù)管理概述
- 內(nèi)存元數(shù)據(jù)
- 元數(shù)據(jù)文件
- fsimage內(nèi)存鏡像文件
- edits log編輯日志
- namenode加載元數(shù)據(jù)文件順序
- 元數(shù)據(jù)管理相關目錄文件
- 元數(shù)據(jù)相關文件
- VERSION
- seen_txid
- 元數(shù)據(jù)文件查看(OIV,OEV)
- SecondaryNameNode介紹
- checkpoint機制
- SNN Checkpoint--觸發(fā)機制
- 元數(shù)據(jù)文件恢復
- namenode存儲多目錄
- 從SNN中恢復
元數(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,但是我們可可以將損失減小到最少