CN109522290A - 一种HBase数据块恢复及数据记录提取方法 - Google Patents

Abstract

本发明的一种HBase数据块恢复及数据记录提取方法，包括：构建三级映射实现从节点数据恢复，实现HDFS文件在从节点主机中的磁盘数据块的准确定位，结合传统的数据恢复方法，实现对HDFS中已删除文件的恢复；从恢复数据库中筛选HBase数据块是以Edit日志文件、fsimage日志文件及Hadoop系统服务日志记录的内容为基础将逻辑层面的HFile文件与底层的恢复出来的数据块进行关联，可筛选出HBase数据块；以数据记录的存储特征为基础，理清所有存储特征的顺序关系、逻辑关系、长度关系及分隔符识别恢复的HFile对应底层文件系统的数据块中的数据记录的位置和内容，以可读的方式按照自定义的顺序将内容输出。

Description

一种HBase数据块恢复及数据记录提取方法

技术领域

本发明属于数据恢复和提取领域，涉及一种HBase数据块恢复及数据记录提取方法。

背景技术

当前，云平台Hadoop的数据库HBase中存储的大量管理信息和用户数据，因此针对HBase的数据恢复变得十分重要。但是Hadoop的海量设备和分布式特性，使得传统的针对单机节点的数据恢复手段已经不能适应，需要针对Hadoop数据库HBase研究新的取证方法。

Hadoop的文件系统是HDFS，是以linux操作系统的文件系统为底层构架的逻辑上的文件系统，在linux系统的文件系统层面来看的话就是大小相同的block文件块，目前还没有恢复技术将HDFS与linux常用ext3、ext4等文件系统进行关联，因此在HDFS数据恢复技术方面一片空白。HBase数据库搭建于分布式文件系统HDFS上，因其物理位置跨度范围较大，且HBase的存储结构及数据存储的形态特征与传统的数据库相比完全不同。HBase通常存储数量极为庞大的数据，对于元素、对象的数据检索通常是通过提供的API在更高的逻辑层面上进行复杂算法的大数据挖掘，不需要像关系型数据库那样了解表的模式和关系信息。而当云服务器灾难出现时，通过逻辑层面的命令或者Api编程无法恢复出因数据库大合并而清除的数据记录。因为恢复的HFile对应底层数据块在HBase逻辑层面并不能直接识别，甚至部分数据块有可能是残缺的，无法通过HBase系统本身的识别机制进行顺序提取。

发明内容

为解决上述技术问题，本发明的目的是提供一种HBase数据块恢复及数据记录提取方法，实现了将存储于HDFS上的HBase数据记录在操作系统文件系统层面进行数据块的恢复，以及数据块残缺的情况下进行恢复数据记录，完全不影响HBase整个系统的运行。

本发明提供一种HBase数据块恢复及数据记录提取方法，括如下步骤：

步骤1、数据块的恢复：构建三级映射实现从节点数据恢复，从而实现HDFS文件在从节点主机中的磁盘数据块的准确定位，再结合传统的数据恢复方法，实现对HDFS中已删除文件的恢复；

步骤2、已恢复数据块的筛选：从恢复数据库中筛选HBase数据块是以Edit日志文件、fsimage日志文件以及Hadoop系统服务日志记录的内容为基础将逻辑层面的HFile文件与底层的恢复出来的数据块进行关联，即可筛选出HBase相关数据块；

步骤3、数据记录的提取：以数据记录的存储特征为基础，通过理清所有存储特征的顺序关系、逻辑关系、长度关系以及分隔符识别恢复的HFile对应底层文件系统的数据块中的数据记录的位置和内容，并以可读的方式按照自定义的顺序将内容输出。

在本发明的HBase数据块恢复及数据记录提取方法中，所述步骤1中构建三级映射实现从节点数据恢复具体包括：

(1)构建HDFS文件到HDFS文件数据块的映射：

在fsimage日志文件被删除后的2个检测点之前，以“xml”的格式保存成fsimage日志文件，根据fsimage日志文件中记录的HDFS文件和HDFS文件数据块之间所属关系，构建HDFS文件到HDFS文件数据块的映射；

如果fsimage日志文件中的内容被删除，HDFS文件的元数据信息被清除，基于edit日志中该HDFS文件被写入和删除时的操作记录提取出HDFS文件到HDFS文件数据块的映射关系；

(2)构建HDFS文件数据块到从节点主机的映射：

结合主节点中“namenode.log”服务日志和从节点中“datanode.log”服务日志的相关内容，构建HDFS文件数据块到从节点主机的映射；确定HDFS文件数据块在HDFS文件中的ID_Cl、ID_NS、ID_BP、ID_ST和IP_DN，从而定位出HDFS文件数据块在从节点的本地存储路径；

其中，ID_Cl表示集群编号、ID_NS是命名空间编号，ID_BP是块池编号、ID_ST是从节点在主节点中的注册编号、IP_DN是从节点的地址IP；

(3)构建HDFS文件数据块到从节点磁盘数据块的映射：

文件被删除后，文件目录项依然存在，根据文件目录项，确定被删除文件名称和文件的inode编号，再结合超级块和组描述符进而确定inode编号所在的数据块，最后在日志文件的备份中找到相应的extent树的元数据信息，实现extent树的重构，根据重构的extent树定位磁盘数据块，进而实现HDFS文件数据块到从节点磁盘数据块的映射；

(4)HDFS文件数据块的数据恢复：

根据三级映射的关系可得到HDFS文件到从节点磁盘数据块的映射关系；利用ext4文件系统日志可以重建extent树，从而恢复损坏的叶子节点，然后根据extent_extent数据项中记录的磁盘数据块地址并利用dd命令实现对数据项的内容提取，从而恢复出HDFS文件数据块，进而恢复出被删除的HDFS文件。

在本发明的HBase数据块恢复及数据记录提取方法中，所述步骤3中数据记录的存储特征包括：固定特征、定长特征和变长特征；

所述固定特征是指只会出现固定几种数值的特征，且只有键类属于固定特征；键类有四个固定值代表操作类型，在数据记录中只有0x04、0x0E和0x0C；

所述定长特征是指特征本身所占位数固定，但其值不固定，可以是限定位数能表达的范围内的所有可能性，其包含：键长度、值长度、行键长度、列簇名长度、时间戳；键长度和值长度固定占4倍的两个十六进制位，行键长度本身占2倍的两个十六进制位，列簇名长度占两个十六进制位，时间戳长度占8倍的两个十六进制位，其中表示特征长度的特征域是以两个十六进制位为单位表示其所负责的特征长度的；

所述变长特征是指其所占十六进制位数长度和值都可变的，包括行键、列簇名、列名和值。

在本发明的HBase数据块恢复及数据记录提取方法中，数据记录的物理存储形式为：

数据记录(键长度+值长度)＝键长度(4)+值长度(4)+行键长度(2)+行键+列簇名长度(1)+列簇名(列簇名长度)+列名+时间戳(8)+键类(1)+值(值长度)。

在本发明的HBase数据块恢复及数据记录提取方法中，所述步骤3中数据记录的提取具体为：

利用数据记录分隔符提取一条已知的数据记录，进而确定其相邻的数据记录的起始和结束位置；

利用数据记录的存储特征设置条件进行检索和甄别，完善数据记录的提取；

在正确的提取所有的数据记录后，通过数据记录的逻辑关系将数据进行可视化显示。

在本发明的HBase数据块恢复及数据记录提取方法中，确定一条已知的数据记录相邻的数据记录的起始和结束位置具体为：

对于已知记录的下一条记录，可以通过0x00后面紧跟的定长特征键长度和值长度来确定范围以提取，经过多次迭代可以将已知数据记录的后续数据记录全部以可视化的形式输出；

对于已知数据记录相邻的上一个数据记录，可以结合利用固定特征键类确定值的长度，向前检索长度为4倍两个十六进制位的值长度域，便可以固定数据记录的起始和结束位置。

在本发明的HBase数据块恢复及数据记录提取方法中，利用数据记录的存储特征设置条件进行检索和甄别具体包括：

(1)检索的存储特征为键长度域、值长度域、行键长度域或者行键：

可以直接正向提取数据记录所有特征的内容，因为前三者都是相邻的定长特征，知其一即可挖掘其他特征，而已知行键也可以逆向定位到行键长度域进而找到其他特征，其步骤与利用数据记录分隔符中的可视化操作相同；

(2)检索的存储特征为列簇名：

首先可以逆向定位列簇名长度域，然后结合倒叙识别键类和时间戳，找到列名，此时根据公式：

键长度域＝len(行键长度域+行键)+len(列簇名长度域+列簇名+列名+时间戳+键类)

行键长度域＝len(行键)

len(列簇名长度域+列簇名+列名+时间戳+键类)已知

自列簇名长度域向前通过设置行键探测域、行键长度域探测域以及键长度域探测域定位行键长度，结合行键每增加两个十六进制位键长度域就增大的逻辑关系，不断扩大行键探测域，左移行键长度域探测域和键长度域探测域，找到匹配公式数据记录；

(3)检索的存储特征为列名：

首先通过设置列簇名探测域和列簇名长度域探测域，作用于已知特征为列簇名的数据记录检索步骤中使用行键探测域和行键长度域探测域相似，区别也只有探测的特征为列簇名和列簇名长度域，列簇名长度域的长度为两个十六进制位，找到列簇名域列簇名长度域后即可套用利用列簇名检索数据记录的步骤检索提取所需数据记录；

(4)检索的存储特征为时间戳、键类：

因为列名没有对应的长度域，所以不适用之前的逻辑流程，通过设置键探测域和键长度域探测域，逆向以两个十六进制位为单位进行探测找到数据记录的起始位，然后通过利用记录分隔符中的正向定位特征的方法即可进行可视化输出；在检索列名、列簇名时也可以使用正向逻辑流程，即通过设定键长度域探测域和键域找到记录后再进行特征分析，因为正向定位的时间戳和键类都是定长特征，只需要简单的数量运算即可；

(5)检索的存储特征为值：

计算值的长度后设置值长度探测域即可快速定位值长度域的位置，然后分析数据记录的特征进行可视化输出。

本发明的一种HBase数据块恢复及数据记录提取方法至少具有以下效益效果：

1)以数据记录的存储特征为数据记录提取得基础，充分的理解记录间时序关系，在发生包括恶意操作、误操作甚至数据库大合并的灾难情况下，实现了将存储于HDFS上的HBase数据记录在操作系统文件系统层面实现数据块的恢复，打破了HBase在大合并后数据无法恢复的认识，提高了数据被彻底清除之前将关键信息固定的可能性。

2)实现过程中不需要进行逻辑层面API结构的编程，弱依靠甚至不依靠日志，因此本技术扩大了HBase数据记录提取的适用范围，实现了在数据块残缺的情况下进行恢复数据记录

3)HBase数据块恢复及数据记录提取是在操作系统的文件系统层面进行的，而且恢复的数据块可以转移至实验环境中进行数据记录的识别与提取工作，完全不影响HBase整个系统的运行。

附图说明

图1是本发明的一种HBase数据块恢复及数据记录提取方法的流程图；

图2是构建HF到HBlk的映射的流程图；

图3是current文件的目录树结构；

图4a是在“namenode.log”中记录HF的写入操作示意图；

图4b是在“datanode.log”中记录HF的删除操作示意图；

图5是Ext4的文件访问流程；

图6是本发明的三级映射的流程图；

图7是Hadoop-root-namenode-master.log日志内容；

图8是从节点中的logs日志；

图9是数据记录的特征分布；

图10是数据记录的物理存储形式。

具体实施方式

为了更好的说明本发明的技术方案，先对相关现有技术和存在的缺陷进行简要的介绍。

1)、Hadoop技术：Apache Hadoop是一款支持数据密集型分布式应用程序并以Apache 2.0许可协议发布的开源软件框架。它支持在商品硬件构建的大型集群上运行的应用程序。Hadoop是根据谷歌公司发表的MapReduce和Google文件系统的论文自行实现而成。所有的Hadoop模块都有一个基本假设，即硬件故障是常见情况，应该由框架自动处理。

Hadoop框架透明地为应用提供可靠性和数据移动。它实现了名为MapReduce的编程范式：应用程序被分区成许多小部分，而每个部分都能在集群中的任意节点上运行或重新运行。此外，Hadoop还提供了分布式文件系统，用以存储所有计算节点的数据，这为整个集群带来了非常高的带宽。MapReduce和分布式文件系统的设计，使得整个框架能够自动处理节点故障。它使应用程序与成千上万的独立计算的计算机和PB级的数据连接起来。现在普遍认为整个Apache Hadoop“平台”包括Hadoop内核、MapReduce、Hadoop分布式文件系统(HDFS)以及一些相关项目，有Apache Hive和Apache HBase等等。

2)、HBase技术：HBase是一个开源的非关系型分布式数据库(NoSQL)，它参考了谷歌的BigTable建模，实现的编程语言为Java。它是Apache软件基金会的Hadoop项目的一部分，运行于HDFS文件系统之上，为Hadoop提供类似于BigTable规模的服务。因此，它可以容错的存储海量稀疏的数据。

HBase在列上实现了BigTable论文提到的压缩算法、内存操作和布隆过滤器。HBase的表能够作为MapReduce任务的输入和输出，可以通过Java API来访问数据，也可以通过REST、Avro或者Thrift的API来访问。

虽然最近性能有了显著的提升，但HBase还不能直接取代SQL数据库。如今，它已经应用于多个数据驱动型网站，包括Facebook的消息平台。

3)、ext4恢复技术：extundelete是可以实现ext3和ext4文件系统数据恢复的软件，extundelete的删除恢复原理是利用存储在分区日志中的备份信息，重新构建extent树然后利用dd命令提取叶子节点数据项中记录的磁盘数据块内容，进而实现删除文件的数据恢复的。

现有技术存在的缺陷：

1)、Hadoop的文件系统是HDFS，是以linux文件系统为底层构架的逻辑上的文件系统，目前还没有恢复技术将HDFS与linux常用ext3、ext4等文件系统进行关联，因此国内在HDFS数据恢复技术方面一片空白。

2)、HBase数据库搭建于分布式文件系统HDFS上，因其物理位置跨度范围较大，且HBase的存储结构及数据存储的形态特征与传统的数据库相比完全不同。

3)、HBase通常存储数量极为庞大的数据，对于元素、对象的数据检索通常是通过提供的API在更高的逻辑层面上进行复杂算法的大数据挖掘，不需要像关系型数据库那样了解表的模式和关系信息。而当云服务器灾难出现时，通过逻辑层面的命令或者Api编程无法恢复出因数据库大合并而清除的数据记录。

4)、因为恢复的HFile对应底层数据块在HBase逻辑层面并不能直接识别，甚至部分数据块有可能是残缺的，无法通过HBase系统本身的识别机制进行顺序提取。

根据Hadoop元数据是证据提取的起点，元数据文件包括两种类型：fsimage和edit日志。master主节点的NameNode日志和slave从节点中的DataNode日志分别记录着主节点master和从节点slave各自云进程的具体活动，其中包括针对云文件块的创建、存储和删除的相关信息。本发明首先通过利用这些关键信息进行HBase存于HDFS的数据块恢复。

基于数据记录的存储形态及特征通过脚本工具深度挖掘无法在逻辑接口查看的在HFile、WALs及StoreFile中存在的数据记录，并按其中部分关键特征进行排序。再解决HBase文件层恢复数据块中的数据记录精准识别及提取问题。

本发明提供一种HBase数据块恢复及数据记录提取方法，包括如下步骤：

步骤1、数据块的恢复：构建三级映射实现从节点数据恢复，从而实现HDFS文件在从节点主机中的磁盘数据块的准确定位，再结合传统的数据恢复方法，实现对HDFS中已删除文件的恢复；

为了能够准确定位HDFS数据块的位置，完成HDFS的数据块恢复，本发明提出了通过构建三级映射实现从节点数据恢复的方法，第一级，HDFS文件到HDFS文件数据块的映射；第二级，HDFS文件数据块和从节点主机的映射；第三级，HDFS文件数据块到从节点磁盘数据块的映射。

概念定义1：定义Hadoop集群联盟

(1)Hadoop集群中master主节点定义为：

NN＝{ID_Cl,ID_NS,ID_BP,IP_NN} (1)

其中，ID_Cl表示集群编号，ID_NS是命名空间编号，ID_BP是块池编号，IP_NN是NN的地址IP。

(2)Hadoop集群中的slave从节点定义为：

DN＝{ID_Cl,ID_ST,H_Blk,IP_DN} (2)

其中，ID_ST是slave从节点在smaster主节点中的注册编号，H_Blk是Hadoop集群的文件块，IP_DN是DN的地址IP。

(3)HDFS文件定义为：

HF＝{HF_size,HF_inode,HF_usrn,HF_repli} (3)

其中，HF_size表示HDFS中文件的大小，HF_inode表示文件的inode号，HF_usrn表示文件的用户名，HF_repli表示文件的备份因子数。

(4)HDFS文件数据块定义为：

H_Blk＝{ID_Blk,GT_Blk} (4)

其中，ID_Blk是H_Blk的文件块号，GT_Blk是H_Blk的生成时间戳。

(5)多个master主节点的Hadoop集群，即Hadoop联盟集群的定义为：

FH＝{{NN₁,...,NN_n},{DN₁,...,DN_m}} (5)

其中，n是NN在FH中的个数，m是DN在FH中的个数。

概念定义2：Ext4文件系统

(6)Ext4的inode节点被定义为：

E_inode＝{E_isize,E_extent} (6)

其中，E_isize是文件的大小，E_extent是extent树。

(7)Ext4中文件目录项被定义为：

D＝{D_inode,D_fname} (7)

其中，D_inode是目录项中包含文件的inode号，D_fname是目录项中的文件名。

(8)Ext4的磁盘数据块被定义为：

E_block＝{E_bstart,E_blen} (8)

其中，E_bstart是叶子节点中磁盘数据块的起始地址，E_blen是起始地址后磁盘数据块的数量。

三级映射的描述：

(1)HDFS文件到HDFS文件数据块的映射，即HF到H_Blk的映射：

实现HF恢复的核心就是实现H_Blk的恢复，而实现H_Blk的恢复，首先要建立HF和H_Blk之间的映射关系。HF被分割成若干H_Blk，HDFS再将这些H_Blk分配到不同的DN中，因此要唯一确定各个DN中H_Blk的所属情况，需要通过一个新集合T来表示H_Blk的所示情况，新集合T被定义为：

T＝{HF_inode,ID_Blk,GT_Blk} (9)

因此HF到H_Blk的映射被描述为：

FT-H:T→H_Blk (10)

(2)HDFS文件数据块到从节点主机的映射，即H_Blk到DN的映射；

master主节点中的“Hadoop-root-namenode-主机名.log”(以下称“namenode.log”)记录主节点的详细服务信息以及其守护进程namenode和各从节点slave的守护进程datanode之间的通信过程。slave从节点中的“Hadoop-root-datanode-主机名.log”(以下称“datanode.log”)中详细地记录本节点的工作过程以及其跟master主节点的进程namenode之间和其他slave从节点的进程datanode之间的通信过程。因此通过查阅主节点和从节点中的这两类服务日志中的内容，可以获得H_Blk与DN之间的映射关系，从而建立H_Blk与DN之间的映射，因此H_Blk到DN的映射被描述为：

FH-DN:H_Blk→IP_DN (11)

(3)HDFS文件数据块到从节点磁盘数据块的映射，即H_Blk到E_block的映射：

在Ext4文件系统中，主机通过递归和遍历的方式定位H_Blk的E_block在磁盘中的位置，在查找E_block的过程中，D和E_inode是准确定位E_block的关键元数据文件，通过查找D和E_inode中的相关信息，实现对E_block的定位。H_Blk和E_block的映射被描述为：

FH-E:H_Blk→E_block (12)

基于三级映射的数据恢复方法实现HF恢复，就要构建HF到E_block的完整映射关系。步骤1中三级映射的构建及实现从节点数据恢复具体如下：

(1)构建HDFS文件到HDFS文件数据块的映射：

在HDFS中执行删除操作后，删除操作将被记录在某些edit日志文件中。因为HDFS通常只保留两个最新的fsimage日志文件，更新的fsimage日志文件直接清除已删除文件的元数据。因此在fsimage日志文件被删除后的2个检测点之前，要及时以“xml”的格式保存fsimage日志文件，根据fsimage日志文件中记录的HDFS文件和HDFS文件数据块之间所属关系，构建HDFS文件到HDFS文件数据块的映射。如果fsimage日志文件中的内容被删除，HDFS文件的元数据信息被清除，基于edit日志中该HDFS文件被写入和删除时的操作记录提取出HDFS文件到HDFS文件数据块的映射关系。HF到H_Blk的映射构建过程如图2所示。

(2)构建HDFS文件数据块到从节点主机的映射：

DataNode存储块文件的本地路径由HDFS-site.xml中的“DFS.Data.dir”属性来确定，该路径的中文件目录结构如图3所示。“BP-11543…4056”表示块池的标识符。“finalized”和“rbw”都包含用于块存储的目录结构，“finalized”包含已完成的块文件，“rbw”表示正在写入的副本。块文件和相应的保存MD5校验的“.meta”文件被保存在finalized目录。“VERSION”存储IDNS和其他标识信息。

用户在HDFS中对HF的写入、删除等操作时会在edit日志中记录下来。在“namenode.log”只记录HF的写入操作，如图4a。但相应的“datanode.log”中还会将该HF的删除操作都记录下来，具体内容如图4b。

结合主节点中“namenode.log”服务日志和从节点中“datanode.log”服务日志的相关内容，H_Blk到DN的映射，进而确定H_Blk在FH中IDCl、IDNS、IDBP、IDST和IPDN，从而定位出H_Blk在从节点的本地存储路径。

(3)构建HDFS文件数据块到从节点磁盘数据块的映射：

因为Ext4文件系统继承了Ext3文件系统特性，所以Ext4的文件访问流程和Ext3的基本相同，Ext4的文件访问流程如图5所示。

由图5可知，要访问文件的本地磁盘数据必须要定位叶子节点，但是Ext4在文件被删除后，文件的E_extent的完整性遭到破坏，要想实现H_Blk到E_block的映射的构建，首先必须要实现E_extent的重构。

文件被删除后，文件目录项依然存在，根据文件目录项，确定被删除文件名称和文件的inode编号，再结合超级块和组描述符进而确定inode编号所在的数据块，最后在日志文件的备份中找到相应的extent树(E_extent)的元数据信息，实现extent树的重构，根据重构的extent树定位磁盘数据块，进而实现HDFS文件数据块到从节点磁盘数据块的映射。

(4)HDFS文件数据块的数据恢复：

三级映射理清HF和E_block的逻辑关系，从而为云平台从节点的电子取证提供取证思路，也为从节点的数据恢复构建系统性的取证方法。根据三级映射的关系可得到HF到E_block的映射图，如图6所示。

根据三级映射的关系可得到HDFS文件到从节点磁盘数据块的映射关系，利用ext4文件系统日志可以重建extent树，从而恢复损坏的叶子节点，然后根据extent_extent数据项中记录的磁盘数据块地址并利用dd命令实现对数据项的内容提取，从而恢复出HDFS文件数据块，进而恢复出被删除的HDFS文件。

步骤2、已恢复数据块的筛选：从恢复数据库中筛选HBase数据块是以Edit日志、fsimage文件以及Hadoop系统服务日志记录的内容为基础将逻辑层面的HFile文件与底层的恢复出来的数据块进行关联，即可筛选出HBase相关数据块；

通过步骤1HBase数据块的恢复，所恢复出来的HDFS数据块数量极为巨大，要进行HBase数据记录的提取，就需要依靠Hadoop的元数据和日志经过层层筛选。(本发明旨在针对因HBase大合并而被彻底清除的数据块中数据记录进行提取，因此依靠WALs进行数据记录的重放的操作暂且不提。)

HBase数据块的筛选工作依赖Edit日志、fsimage以及Hadoop系统服务日志。Edit日志对HDFS的每次修改进行连续记录。为每个修改分配唯一的、单调增加的事务ID。在给定时间间隔内启动Hadoop或触发检查点时，主节点进程NameNode会将最新的fsimage与edit日志之后记录的所有事务合并，以创建新的事务并删除过期的fsimage。Edit日志保存了自最后一次检查点之后所有针对HDFS文件系统的所有更新操作。fsimage维护命名空间的结构和文件的属性，即维护着HDFS整个目录树，HDFS文件的元数据通过inode存储在fsimage中。

Hadoop中有很多种日志，大致分为两大类，即Hadoop系统服务输出日志和Mapreduce程序输出来的日志。NameNode、DataNode等系统自带服务输出的日志默认存放路径为${HADOOP_HOME}/logs目录下，默认文件后缀为“log”；当日志达到一定的大小(由扩展名为properties文件配置)将会切割出新的文件，切割出的文件名类似于“XXX.log.数字”，后边的数字越大，表示日志越旧。默认情况下，保存前20个日志文件。此种日志的格式最为简单，一行一条，日志格式依次描述为日期、时间、类别、相关类和提示信息。其中，类别“INFO BlockStateChange”如图7所示，表示文件逻辑块状态的变化，与操作行为密切相关，此类信息尤为值得关注。

此外，主节点上的日志文件记录全面信息，其中包括从节点产生的一些错误信息。而从节点中的日志主要记录完成的task任务信息。主节点和从节点中都存在2种日志，分别以log和out作后缀，每一个守护进程都会产生这2种日志，如图8所示。log日志文件通过log4j记录的，大部分应用程序的日志消息都写道该日志中，故障诊断的首要步骤就是检测该文件。out日志文件记录标准的输出和标准错误日志，由于大多日志均使用log4j输出至log日志文件中，因此此文件很小或者为空，系统仅保留5个这类日志。

以上Edit日志、fsimage以及Hadoop系统服务日志记录的内容可以将逻辑层面的HFile文件与底层的恢复出来的数据块进行关联，然后即可快速筛选出HBase相关数据块。

步骤3、数据记录的提取：以数据记录的存储特征为基础，通过理清所有存储特征的顺序关系、逻辑关系、长度关系以及分隔符识别恢复的HFile对应底层文件系统的数据块中的数据记录的位置和内容，并以可读的方式按照自定义的顺序将内容输出，所述步骤3中数据记录的提取具体为：

利用数据记录分隔符提取一条已知的数据记录，进而确定其相邻的数据记录的起始和结束位置；

利用数据记录的存储特征设置条件进行检索和甄别，完善数据记录的提取；

在正确的提取所有的数据记录后，通过数据记录的逻辑关系将数据进行可视化显示。

数据库及数据文件的恢复目的是为了给数据记录提取创造前提条件，但因为数据在HDFS都是以文件块的形式存储的，产生和删除速度在生产环境中极为巨大，因此发生已经删除的文件块被覆盖的概率也是因情况而定的，对于损坏的文件块的数据记录提取成为信息固定的最后一道关卡。

HBase可以在shell下查看系统本身的HFile，但是不能查看使用通过命令上传上去的HFile文件，而且也只能查看没有被删除的数据记录，其唯一的作用就是通过筛选条件检索出没被删除的线索记录，缩减对删除记录进行恢复和提取的时间周期。

HBase自身提供了两个工具hfile和wal，对传统数据记录的提取起到关键性作用，hfile和wal是可以通过命令行的方式将HDFS上的HFile格式的文件和WAL文件通过可视化的方式输出显示，而且对于HFile和WAL的文件块也能直接显示，这给数据记录的提取提供了大大的便利。通过搭建的实验环境在不影响信息固定及法律效力的情况下将恢复的文件块上传到HDFS直接通过这两个工具就可以提取，不需要任何复杂的技术手段。但这两个工具的最大缺陷就是无法对损坏的文件块进行数据记录的提取，所以无法满足所有数据记录的提取需求。因此需要基于存储特征逻辑关系进行数据记录的提取。

HBase数据记录存储于分布式文件系统HDFS中，所以HBase数据记录存储的形态在操作系统层面参考HDFS的存储模式，存储为HDFS数据块，且HBase并没有对数据进行加密，仍可以通过数据记录的存储特征进行识别提取。数据记录得特征分布如图9所示：

提取记录的关键目标是将每条数据记录完整的提取出来，包含数据记录的所有特征。所以数据记录的存储特征就是检验数据记录完整性的标准，也是进行数据记录提取的着手方向。

HBase数据记录的存储特征可以分为三种类型：固定特征、定长特征和变长特征。每条数据记录之间也有确定的分隔特征，每条数据记录都会以0x00来分隔，通过理清所有存储特征之间的顺序关系、逻辑关系、长度关系来准确的识别已经恢复得HFile对应底层文件系统得数据块中存在得所有完整的数据记录，进行准确的提取并按照自定义关键字特征进行排序显示。

固定特征是指只会出现固定几种数值的特征，且只有键类属于固定特征；键类有四个固定值代表操作类型，在数据记录中只有0x04、0x0E和0x0C。

定长特征是指特征本身所占位数固定，但其值不固定，可以是限定位数能表达的范围内的所有可能性，其包含：键长度、值长度、行键长度、列簇名长度、时间戳；键长度和值长度固定占4倍的两个十六进制位，行键长度本身占2倍的两个十六进制位，列簇名长度占两个十六进制位，时间戳长度占8倍的两个十六进制位，其中表示特征长度的特征域是以两个十六进制位为单位表示其所负责的特征长度的。

变长特征是指其所占十六进制位数长度和值都可变的，包括行键、列簇名、列名和值。

如图10是一条完整的Put操作的数据记录，包含了所有可能出现的数据记录存储特征。图10中的列簇名长度位9，则列簇名的长度就是9倍的两个十六进制位。

因此，通过一个公式可以直观的将图10中的记录表示出来：(单位为两个十六进制位)，即图10中的数据记录的物理存储形式为：

数据记录(键长度+值长度)＝键长度(4)+值长度(4)+行键长度(2)+行键+列簇名长度(1)+列簇名(列簇名长度)+列名+时间戳(8)+键类(1)+值(值长度)。

之所以列名的长度没有数据记录的特征进行表示是因为在HBase设计中考虑到可以通过其他所有字段进行运算可以获得，对于数据记录的提取来说列名的提取也是以其他数据记录存储特征的全部提取为前提的，因此必然是最后一步。

利用每条数据记录都是通过0x00分隔的，这样的话只需通过一条已知的数据记录便可以确定相邻数据记录的起始或者结束位置。对于已知记录的下一条记录，可以通过0x00后面紧跟的定长特征键长度和值长度来确定范围以提取，经过多次迭代可以将已知数据记录的后续数据记录全部以可视化的形式输出。

对于已知数据记录相邻的上一个数据记录，可以结合利用固定特征键类确定值的长度，向前检索长度为4倍两个十六进制位的值长度域，便可以固定数据记录的起始和结束位置。

但只是如此利用数据记录的分隔符来进行数据记录的提取并不完善，首先在提取已知数据记录的前序记录时，有可能会在变长、定长特征中出现与键类、值长度域相同的内容，造成这个问题的原因可以通过数据记录的存储特征设置条件进行甄别解决，如核实键类前面八倍的两个十六进制位是不是正确的时间戳格式。

在正确的提取所有的数据记录后，通过数据记录的逻辑关系将数据进行可视化显示。首先可以通过定长特征中的键长度域、值长度域定位行键长度域，再正向依次定位行键、列簇名长度域和列簇名。再通过键长度域的值确定键的长度范围，最后的两个十六进制位一定是键类，正向定位值，逆向定位时间戳，结合前面找到的列簇最后定位列名。

因此，需要利用数据记录的存储特征设置条件进行检索和甄别。通过数据记录分隔符提取所有数据记录，但是提取的内容数量庞大，要进行数据记录的检索必须将所有的数据记录提取后再进行检索，而对于某些特征的检索完全可以跳过这一步，直接利用特征逻辑关系找到匹配数据记录。这样就可以实现先检索特征，后提取数据记录的操作，节省了大量的运算资源，因为通过这种方式我们只需要提取出所需的记录而不需要对每条数据记录都进行识别。

对于根据不同已知特征进行数据记录的检索的逻辑流程是不同的，因此对于检索数据记录流程逻辑的设计也不同：

(1)检索的存储特征为键长度域、值长度域、行键长度域或者行键：

可以直接正向提取数据记录所有特征的内容，因为前三者都是相邻的定长特征，知其一即可挖掘其他特征，而已知行键也可以逆向定位到行键长度域进而找到其他特征，其步骤与利用数据记录分隔符中的可视化操作相同；

(2)检索的存储特征为列簇名：

首先可以逆向定位列簇名长度域，然后结合倒叙识别键类和时间戳，找到列名，此时根据公式：

键长度域＝len(行键长度域+行键)+len(列簇名长度域+列簇名+列名+时间戳+键类)

行键长度域＝len(行键)

len(列簇名长度域+列簇名+列名+时间戳+键类)已知

自列簇名长度域向前通过设置行键探测域、行键长度域探测域以及键长度域探测域定位行键长度，结合行键每增加两个十六进制位键长度域就增大的逻辑关系，不断扩大行键探测域，左移行键长度域探测域和键长度域探测域，找到匹配公式数据记录；

(3)检索的存储特征为列名：

首先通过设置列簇名探测域和列簇名长度域探测域，作用于已知特征为列簇名的数据记录检索步骤中使用行键探测域和行键长度域探测域相似，区别也只有探测的特征为列簇名和列簇名长度域，列簇名长度域的长度为两个十六进制位，找到列簇名域列簇名长度域后即可套用利用列簇名检索数据记录的步骤检索提取所需数据记录；

(4)检索的存储特征为时间戳、键类：

因为列名没有对应的长度域，所以不适用之前的逻辑流程，可以通过设置键探测域和键长度域探测域，逆向以两个十六进制位为单位进行探测找到数据记录的起始位，然后通过利用记录分隔符中的正向定位特征的方法即可进行可视化输出；在检索列名、列簇名时也可以使用正向逻辑流程，即通过设定键长度域探测域和键域找到记录后再进行特征分析，因为正向定位的时间戳和键类都是定长特征，只需要简单的数量运算即可，比如已知键长度＝len(行键长度域+列簇名长度域+时间戳+键类)+len(行键+列簇名+列名)＝12+len(变长特征)，把键探测域最小设置为14(列名不一定存在)即可逆向定位键长度域找到起始位置；

(5)检索的存储特征为值：

计算值的长度后设置值长度探测域即可快速定位值长度域的位置，然后分析数据记录的特征进行可视化输出。

基于固定特征、定长特征、变长特征以及每条数据记录之间确定的分隔特征，通过理清所有存储特征之间的顺序关系、逻辑关系、长度关系来准确的识别已经恢复得HFile对应底层文件系统得数据块中存在得所有完整的数据记录，进行准确的提取并按照自定义关键字特征进行排序显示。

以上所述仅为本发明的较佳实施例，并不用以限制本发明的思想，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (7)

1.一种HBase数据块恢复及数据记录提取方法，其特征在于，包括如下步骤：

步骤1、数据块的恢复：构建三级映射实现从节点数据恢复，从而实现HDFS文件在从节点主机中的磁盘数据块的准确定位，再结合传统的数据恢复方法，实现对HDFS中已删除文件的恢复；

步骤2、已恢复数据块的筛选：从恢复数据库中筛选HBase数据块是以Edit日志文件、fsimage日志文件以及Hadoop系统服务日志记录的内容为基础将逻辑层面的HFile文件与底层的恢复出来的数据块进行关联，即可筛选出HBase相关数据块；

步骤3、数据记录的提取：以数据记录的存储特征为基础，通过理清所有存储特征的顺序关系、逻辑关系、长度关系以及分隔符识别恢复的HFile对应底层文件系统的数据块中的数据记录的位置和内容，并以可读的方式按照自定义的顺序将内容输出。

2.如权利要求1所述的HBase数据块恢复及数据记录提取方法，其特征在于，所述步骤1中构建三级映射实现从节点数据恢复具体包括：

(1)构建HDFS文件到HDFS文件数据块的映射：

在fsimage日志文件被删除后的2个检测点之前，以“xml”的格式保存成fsimage日志文件，根据fsimage日志文件中记录的HDFS文件和HDFS文件数据块之间所属关系，构建HDFS文件到HDFS文件数据块的映射；

如果fsimage日志文件中的内容被删除，HDFS文件的元数据信息被清除，基于edit日志中该HDFS文件被写入和删除时的操作记录提取出HDFS文件到HDFS文件数据块的映射关系；

(2)构建HDFS文件数据块到从节点主机的映射：

结合主节点中“namenode.log”服务日志和从节点中“datanode.log”服务日志的相关内容，构建HDFS文件数据块到从节点主机的映射；确定HDFS文件数据块在HDFS文件中的ID_Cl、ID_NS、ID_BP、ID_ST和IP_DN，从而定位出HDFS文件数据块在从节点的本地存储路径；其中，ID_Cl表示集群编号、ID_NS是命名空间编号，ID_BP是块池编号、ID_ST是从节点在主节点中的注册编号、IP_DN是从节点的地址IP；

(3)构建HDFS文件数据块到从节点磁盘数据块的映射：

文件被删除后，文件目录项依然存在，根据文件目录项，确定被删除文件名称和文件的inode编号，再结合超级块和组描述符进而确定inode编号所在的数据块，最后在日志文件的备份中找到相应的extent树的元数据信息，实现extent树的重构，根据重构的extent树定位磁盘数据块，进而实现HDFS文件数据块到从节点磁盘数据块的映射；

(4)HDFS文件数据块的数据恢复：

根据三级映射的关系可得到HDFS文件到从节点磁盘数据块的映射关系；利用ext4文件系统日志可以重建extent树，从而恢复损坏的叶子节点，然后根据extent_extent数据项中记录的磁盘数据块地址并利用dd命令实现对数据项的内容提取，从而恢复出HDFS文件数据块，进而恢复出被删除的HDFS文件。

3.如权利要求1所述的HBase数据块恢复及数据记录提取方法，其特征在于，所述步骤3中数据记录的存储特征包括：固定特征、定长特征和变长特征；

所述固定特征是指只会出现固定几种数值的特征，且只有键类属于固定特征；键类有四个固定值代表操作类型，在数据记录中只有0x04、0x0E和0x0C；

所述定长特征是指特征本身所占位数固定，但其值不固定，可以是限定位数能表达的范围内的所有可能性，其包含：键长度、值长度、行键长度、列簇名长度、时间戳；键长度和值长度固定占4倍的两个十六进制位，行键长度本身占2倍的两个十六进制位，列簇名长度占两个十六进制位，时间戳长度占8倍的两个十六进制位，其中表示特征长度的特征域是以两个十六进制位为单位表示其所负责的特征长度的；

所述变长特征是指其所占十六进制位数长度和值都可变的，包括行键、列簇名、列名和值。

4.如权利要求3所述的HBase数据块恢复及数据记录提取方法，其特征在于，数据记录的物理存储形式为：

数据记录(键长度+值长度)＝键长度(4)+值长度(4)+行键长度(2)+行键+列簇名长度(1)+列簇名(列簇名长度)+列名+时间戳(8)+键类(1)+值(值长度)。

5.如权利要求4所述的HBase数据块恢复及数据记录提取方法，其特征在于，所述步骤3中数据记录的提取具体为：

利用数据记录分隔符提取一条已知的数据记录，进而确定其相邻的数据记录的起始和结束位置；

利用数据记录的存储特征设置条件进行检索和甄别，完善数据记录的提取；

在正确的提取所有的数据记录后，通过数据记录的逻辑关系将数据进行可视化显示。

6.如权利要求5所述的HBase数据块恢复及数据记录提取方法，其特征在于，确定一条已知的数据记录相邻的数据记录的起始和结束位置具体为：

对于已知记录的下一条记录，可以通过0x00后面紧跟的定长特征键长度和值长度来确定范围以提取，经过多次迭代可以将已知数据记录的后续数据记录全部以可视化的形式输出；

对于已知数据记录相邻的上一个数据记录，可以结合利用固定特征键类确定值的长度，向前检索长度为4倍两个十六进制位的值长度域，便可以固定数据记录的起始和结束位置。

7.如权利要求5所述的HBase数据块恢复及数据记录提取方法，其特征在于，利用数据记录的存储特征设置条件进行检索和甄别具体包括：

(1)检索的存储特征为键长度域、值长度域、行键长度域或者行键：

可以直接正向提取数据记录所有特征的内容，因为前三者都是相邻的定长特征，知其一即可挖掘其他特征，而已知行键也可以逆向定位到行键长度域进而找到其他特征，其步骤与利用数据记录分隔符中的可视化操作相同；

(2)检索的存储特征为列簇名：

首先可以逆向定位列簇名长度域，然后结合倒叙识别键类和时间戳，找到列名，此时根据公式：

键长度域＝len(行键长度域+行键)+len(列簇名长度域+列簇名+列名+时间戳+键类)

行键长度域＝len(行键)

len(列簇名长度域+列簇名+列名+时间戳+键类)已知

自列簇名长度域向前通过设置行键探测域、行键长度域探测域以及键长度域探测域定位行键长度，结合行键每增加两个十六进制位键长度域就增大的逻辑关系，不断扩大行键探测域，左移行键长度域探测域和键长度域探测域，找到匹配公式数据记录；

(3)检索的存储特征为列名：

首先通过设置列簇名探测域和列簇名长度域探测域，作用于已知特征为列簇名的数据记录检索步骤中使用行键探测域和行键长度域探测域相似，区别也只有探测的特征为列簇名和列簇名长度域，列簇名长度域的长度为两个十六进制位，找到列簇名域列簇名长度域后即可套用利用列簇名检索数据记录的步骤检索提取所需数据记录；

(4)检索的存储特征为时间戳、键类：

因为列名没有对应的长度域，所以不适用之前的逻辑流程，通过设置键探测域和键长度域探测域，逆向以两个十六进制位为单位进行探测找到数据记录的起始位，然后通过利用记录分隔符中的正向定位特征的方法即可进行可视化输出；在检索列名、列簇名时也可以使用正向逻辑流程，即通过设定键长度域探测域和键域找到记录后再进行特征分析，因为正向定位的时间戳和键类都是定长特征，只需要简单的数量运算即可；

(5)检索的存储特征为值：

计算值的长度后设置值长度探测域即可快速定位值长度域的位置，然后分析数据记录的特征进行可视化输出。