本篇文章大概2353字,阅读时间大约6分钟
介绍HDFS的元数据管理机制,说明fsimage文件和edits的作用,给出解析fsimage文件和edits文件的demo
HDFS是一个分布式存储服务,是Hadoop生态的存储基石。核心的服务包含两个:
HDFS可以认为是一个图书馆,DataNode则是书架,而NameNode就是寻找到需要书籍的图书馆管理系统。
1
NameNode如何管理元数据
存储数据的方式来看,要么放到内存中,要么放到磁盘上。HDFS作为一个分布式存储服务,需要处理客户端大量的CRUD请求
综上,HDFS采用了内存+磁盘的方式进行元数据的管理,即内存->NameNode节点内存,磁盘->Fsimage文件。并且为了保证元数据在增删改操作下,内存和磁盘中元数据的一致性及操作效率,NameNode引入了edits文件记录HDFS元数据的增删改操作。
HDFS元数据管理流程图(NameNode + 2NN)
Namenode会记录客户端的元数据增删改操作请求,记录操作日志,更新滚动日志。
2NN工作流程:
这里可以看出2NN并不是NN的一个热备,只是减轻了NN的元数据合并开销。2NN不是热备,不是热备,不是热备。
2
Fsimage&Edits文件解析
为什么要解析fsimage和edits文件?
CDH集群在HDFS配置中查一下dfs.name.dir配置的目录,该目录文件如下
Fsimage文件解析
hdfs oiv命令 - Offline Image Viewer
使用指定的processor解析hdfs的fsimage文件
# 基本使用
hdfs oiv -i fsimage文件 -o 文件输出路径 -p 文件类型
# 解析为XML
hdfs oiv -i fsimage_0000000000000000229 -o /tmp/fsimage.xml -p XML
# 解析为csv文件
hdfs oiv -i fsimage_0000000000000000229 -o /tmp/fsimage.csv -p Delimited
截取一个inode
<inode>
<id>16388</id>
<type>FILE</type>
<name>test.txt</name>
<replication>3</replication>
<mtime>1593600792202</mtime>
<atime>1593600790816</atime>
<preferredBlockSize>134217728</preferredBlockSize>
<permission>root:supergroup:0644</permission>
<blocks>
<block>
<id>1073741825</id>
<genstamp>1001</genstamp>
<numBytes>11</numBytes>
</block>
</blocks>
<storagePolicyId>0</storagePolicyId>
</inode>
可以发现fsimage文件记录了数据块的相关信息(做集群小文件分析并不用XML)
Edits文件解析
hdfs oev命令 - Offline edits viewer
# 基本使用
hdfs oev -i edits文件 -o 文件输出路径 -p 文件类型
# 解析为XML
hdfs oev -i edits_0000000000000000229-0000000000000000229 -o /tmp/edits.xml -p XML
截取文件
<?xml version="1.0" encoding="UTF-8"?>
<EDITS>
<EDITS_VERSION>-63</EDITS_VERSION>
<RECORD>
<OPCODE>OP_START_LOG_SEGMENT</OPCODE>
<DATA>
<TXID>229</TXID>
</DATA>
</RECORD>
</EDITS>
这里特别需要注意的是OPCODE标签,记录的是操作的类型,通过修改edits文件恢复hdfs误删除数据的原理,也是将OPCODE标签的删除操作改为其他安全的操作,然后还原成二进制的edits文件并进行替换