CN110245037B - 一种基于日志的Hive用户操作行为还原方法 - Google Patents

Abstract

本发明的一种基于日志的Hive用户操作行为还原方法，包括如下步骤：步骤1：对用户层服务器进行信息提取，获取HDFS路径；步骤2：根据HDFS路径进行文件层信息提取，获取数据块的详细信息；步骤3：根据数据块的详细信息进行物理层数据块提取；步骤4：数据记录查看。本发明通过构建Hive各层之间的逻辑关系，实现依据具体线索信息缩小取证工作量，并通过多证据的相互印证提高证明效力。

Description

一种基于日志的Hive用户操作行为还原方法

技术领域

本发明属于数据恢复技术领域，涉及一种基于日志的Hive用户操作行为还原方法。

背景技术

随着移动设备的普及和互联网业务的创新发展，各行各业产生的数据日益增长并不断累积。这些海量数据的产生推动了高性能云平台的发展，而Hadoop是众多云框架中较成熟、使用较广的架构。Hadoop使用数据仓库Hive存储海量的、非结构化的数据。运营人员可以通过Hive存储的海量数据挖掘出大量含有巨大价值的信息。因此在取证方面，针对Hive的取证工作至关重要，对于Hive取证工作的研究不仅可以遏制犯罪行为的继续，还能及时帮助企业、部门挽回无法估量的损失。

Hive与传统数据库不论是在底层框架还是数据结构上都是大相径庭的，在取证方面唯一共通点就是都依赖系统日志及各种元数据。国内外在Hive取证工作尤其是用户操作行为还原方面的研究极为少见。Hadoop的文件系统是HDFS，是以linux文件系统为底层构架的逻辑上的文件系统，目前还没有恢复技术将HDFS与linux常用ext3、ext4等文件系统进行关联，因此国内在HDFS数据恢复技术方面一片空白。Hive数据仓库搭建于分布式文件系统HDFS上，以Hadoop框架为基础，因其物理位置跨度范围较大，且Hive的存储数据的格式多种多样且各不相同，但本身并不提供任何存储数据格式。整个Hive数据仓库的结构依赖于元数据库，对数据的操作也会被Hive日志记录，当数据仓库发生灾难时关键数据都存在于元数据库及Hive日志，但目前国内通过元数据库及Hive日志还原用户操作行为的研究仍一片空白。因为Hive使用的存储方式不同，导致恢复的部分HFile对应底层数据块在Hive文件层面并不能直接识别，甚至部分数据块有可能是残缺的，无法通过HBase系统本身的识别机制进行顺序提取。

发明内容

本发明的目的是提供一种基于日志的Hive用户操作行为还原方法，通过构建Hive各层之间的逻辑关系，实现依据具体线索信息缩小取证工作量，并通过多证据的相互印证提高证明效力。

本发明提供一种基于日志的Hive用户操作行为还原方法，包括如下步骤：

步骤1：对用户层服务器进行信息提取，获取HDFS路径；

步骤2：根据HDFS路径进行文件层信息提取，获取数据块的详细信息；

步骤3：根据数据块的详细信息进行物理层数据块提取；

步骤4：数据记录查看。

在本发明的基于日志的Hive用户操作行为还原方法中，步骤1包括：

步骤1.1：访问用户层服务器，并采取与国家授时中心等标准时间源的对时操作；

步骤1.2：依据用户层服务器中的Hive多个配置文件获取Hive日志存放路径、连接元数据库的用户名和密码、HDFS路径、驱动、Remote方式；

步骤1.3：访问获取的Hive日志存放路径，若事先掌握时间线索则对多个Hive日志文件进行筛选；若Hive日志文件的数据量较大则进行数据清洗，只保留用户操作的相关记录；若事先掌握时间线索可以对日志文件的内容进行筛选，若发现日志文件缺失或丢失，则立即进行HDFS数据恢复；

步骤1.4：针对步骤1.3筛选出的用户操作相关记录，设定关键字，检索包含HDFS路径的相关记录并整理；

步骤1.5：连接元数据库，基于元数据表DBS、TBLS、SDS中的字段DB_ID、SD_ID进行合并，构建完整的数据表与HDFS的关系，将结果与步骤1.4得到的结果进行比对和验证。

在本发明的基于日志的Hive用户操作行为还原方法中，所述步骤1.2中若取证环境使用Remote，还应提取Mysql服务器地址及端口信息。

在本发明的基于日志的Hive用户操作行为还原方法中，步骤2包括

步骤2.1：访问文件层，并采取与国家授时中心等标准时间源的对时操作；

步骤2.2：依据文件层的文件系统的配置文件内容构建平台环境拓扑结构，确定各节点IP地址，并且获取HDFS元数据在文件层中的实际存储路径；

步骤2.3：将HDFS元数据导出为xml格式，并将整个用户层信息获取过程中获取到的需要检索的时间线索、HDFS路径线索及HDFS文件名线索分别设为关键字在xml中检索，获取数据库详细信息，包括数据块id、修改时间和数据表文件名；若不存在，立即进行物理层上的HDFS数据恢复；

步骤2.4：将步骤2.3中获取到的数据块id与修改时间分别设为关键字，在Hadoop系统服务输出日志中进行检索，获取指定数据库自存在以后的被操作过的所有记录，并比对结果检查是否有重合；若有重合则验证Hadoop系统服务输出日志中的内容，若检索无果，说明Hadoop系统服务输出日志缺失、丢失或被清理，立即进行HDFS数据恢复。

在本发明的基于日志的Hive用户操作行为还原方法中，步骤3包括：

步骤3.1：依据从文件层信息获取中构建的拓扑结构图和HDFS路径信息找到目标物理层的IP地址，访问物理层，并采取与国家授时中心等标准时间源的对时操作；

步骤3.2：将物理层中对应数据块id的数据块以只读方式导入至取证环境中，若无此数据块，则应进行HDFS数据恢复，并使用二进制编辑器查看数据块的头部，确定数据块使用的数据存储格式以及压缩方式。

在本发明的基于日志的Hive用户操作行为还原方法中，步骤4包括：

步骤4.1：在线索信息较为精准，数据量较少的情况下，TextFile、SequenceFile可直接通过Hadoop系统命令进行明文输出，RCFile、ORCFile、Parquet存储格式则使用元数据重构数据结构后进行查看，若存在压缩则应针对相应的数据格式压缩方式进行对应的解压；

步骤4.2：在线索信息较模糊，数据量较多的情况下，可通过将数据重新导入至集群实验环境中，通过集群的高运算能力进行对应数据记录查看操作。

本发明的一种基于日志的Hive用户操作行为还原方法至少具有以下益效果：

1)、在建立用户层与文件层的逻辑关系过程中可以通过Hive日志记录和Hive元数据进行数据库文件在文件层面的定位，在建立文件层与物理层的逻辑关系过程中可以通过HDFS元数据文件及Hadoop系统服务输出日志进行HDFS文件在物理层的定位，提高了线索信息提取的成功率并且能通过相互印证有效规避恶意篡改数据情况的发生。

2)、Hive用户操作行为还原的整个过程依赖于用户层、文件层及物理层的多个配置文件、元数据文件及日志文件记录的内容进行，可以通过提取这些文件至实验环境下进行勘验，整个还原过程完全不影响Hadoop架构及数据仓库Hive的运行，而且整个过程几乎不会留下任何操作痕迹。

附图说明

图1是本发明划分的Hive系统构架图；

图2是用户操作行为对应的文件变化；

图3是本发明的基于日志的Hive用户操作行为还原方法图。

具体实施方式

Hadoop技术：Apache Hadoop是一款支持数据密集型分布式应用程序并以Apache2.0许可协议发布的开源软件框架。它支持在商品硬件构建的大型集群上运行的应用程序。Hadoop是根据谷歌公司发表的MapReduce和Google文件系统的论文自行实现而成。所有的Hadoop模块都有一个基本假设，即硬件故障是常见情况，应该由框架自动处理。Hadoop框架透明地为应用提供可靠性和数据移动。它实现了名为MapReduce的编程范式：应用程序被分区成许多小部分，而每个部分都能在集群中的任意节点上运行或重新运行。此外，Hadoop还提供了分布式文件系统，用以存储所有计算节点的数据，这为整个集群带来了非常高的带宽。MapReduce和分布式文件系统的设计，使得整个框架能够自动处理节点故障。它使应用程序与成千上万的独立计算的计算机和PB级的数据连接起来。现在普遍认为整个ApacheHadoop“平台”包括Hadoop内核、MapReduce、Hadoop分布式文件系统(HDFS)以及一些相关项目，有Apache Hive和Apache HBase等等。

Hive技术：Hive是基于Hadoop的一个数据仓库工具，可以将结构化的数据文件映射为一张数据库表，并提供完整的sql查询功能，可以将sql语句转换为MapReduce任务进行运行。其优点是学习成本低，可以通过类SQL语句快速实现简单的MapReduce统计，不必开发专门的MapReduce应用，十分适合数据仓库的统计分析。Hive整体的系统构架在运营层面来看可以分为元数据库和数据库两部分，但在用户行为还原角度可以分为用户层、文件层和物理层。具体构架如图1所示。

用户层即用户进行Hive操作直接对应的层面。首先用户通过接口将操作发送给命令解释模块driver，driver会将命令进行解释，然后交由文件层处理。Hive整体可以分为元数据库和数据仓库。元数据库单独存放于用户层中，由传统关系型数据库进行管理，通常为mysql，而数据就就存储于Hive数据仓库中。在用户操作期间会在Hive日志中详细记录。文件层Hadoop将用户层driver模块解释的命令分解成多个任务发送给Hadoop的物理层，并将数据存储于Hadoop的分布式文件系统HDFS中，而HDFS的元数据fsimage与edit负责进行文件的管理和记录。物理层即搭建Hadoop框架为基础的云环境的Linux操作系统及其文件系统，HDFS架构基于特定的节点结构，主要包括文件层和物理层。HDFS通过块的方式存储文件，对应到底层Linux文件系统就是经过名称编号的等大文件。图2表示用户操作行为引起Hive三层文件变化的过程以及记录变化的日志或元数据。要进行用户操作行为还原，就必须通过构建用户层、文件层以及物理层的逻辑联系，以准确地识别用户操作行为涉及的逻辑文件和块，取证人员可据此通过三层逻辑关系进行有针对性的数据恢复和证据固定。

如图3所示，本发明的一种基于日志的Hive用户操作行为还原方法，包括如下步骤：

步骤1：对用户层服务器进行信息提取，获取HDFS路径，具体包括：

步骤1.1：访问用户层服务器，并采取与国家授时中心等标准时间源的对时操作；

步骤1.2：依据用户层服务器中的Hive多个配置文件获取Hive日志存放路径、连接元数据库的用户名和密码、HDFS路径、驱动、Remote方式；若取证环境使用Remote，还应提取Mysql服务器地址及端口信息；

步骤1.3：访问获取的Hive日志存放路径，若事先掌握时间线索则对多个Hive日志文件进行筛选；若Hive日志文件的数据量较大则进行数据清洗，只保留用户操作的相关记录；若事先掌握时间线索可以对日志文件的内容进行筛选，若发现日志文件缺失或丢失，则立即进行HDFS数据恢复；

步骤1.4：针对步骤1.3筛选出的用户操作相关记录，设定关键字，检索包含HDFS路径的相关记录并整理；

步骤1.5：连接元数据库，基于元数据表DBS、TBLS、SDS中的字段DB_ID、SD_ID进行合并，构建完整的数据表与HDFS的关系，将结果与步骤1.4得到的结果进行比对和验证。

因不同平台环境下的Hive日志设置不同，取证人员可以通过Hive根目录conf目录下的属性文件hive-log4j2.properties来查看Hive日志的存放路径，日志中具体内容如表1。

表1 hive-log4j2.properties主要内容

Hive日志会在达到系统设定的阈值后自动保存成名为“property.hive.log.file+日期”的旧Hive日志文件，并生成名为“property.hive.log.file”的新Hive日志，其中包含了大量的用户操作的时间信息、具体操作内容以及系统自动输出的记录。Hive日志中包含用户所有操作命令、过程以及系统反馈等信息，取证人员可以将“command”作为关键词进行用户操作所有命令的检索(生产环境需要数据清洗)，也可以将“create”作为关键词检索创建表的记录。在用户命令中就包括数据表的名称、创建时间以及操作涉及到的HDFS路径等信息。

具体实施时，首先访问Hadoop配置文件目录并查看配置文件“hive-log4j2.properties”的内容，在其中找到Hive日志存放路径进行访问，将日志目录下的所有日志导出至取证环境中并依次用编辑器打开。首先通过检索命令关键词找到创建表时的日志记录内容，可以获取到数据表的创建时间，数据格式以及结构描述。然后在此条记录位置向下检索HDFS路径信息找到info表存储路径，默认格式通常为(设表名为$table_name)：“hdfs://localhost:9000/user/hive/warehouse/myhive.db/$table_name”。

与此同时还在日志中检索到涉及修改表的日志记录，通过日志记录可以获取重要的时间线索和具体操作命令内容。

然后查看配置文件“hive-site.xml”并找到标签<name>所对应的内容为“javax.jdo.option.ConnectionPassword”和“javax.jdo.option.ConnectionUserName”的<property>标签，并分别获取两个标签下对应标签<value>的值，即登陆负责管理元数据的Mysql数据库的登陆用户名与密码。并在<name>标签内容为“javax.jdo.option.ConnectionURL”的标签<property>下提取到标签<value>值，即登陆元数据库的地址。因此使用用户名和密码连接Mysql数据库地址，并使用查询命令将元数据表DBS、TBLS、SDS中的基于字段DB_ID、SD_ID进行信息合并，最终获得数据表对应的HDFS路径信息与在Hive日志中获取的内容，如若相同，则说明信息准确无误，否则可能存在数据缺失或被篡改的情况，需要进一步分析。

步骤2：根据HDFS路径进行文件层信息提取，获取数据块的详细信息，具体包括：

步骤2.1：访问文件层，并采取与国家授时中心等标准时间源的对时操作；

步骤2.2：依据文件层的文件系统的配置文件内容构建平台环境拓扑结构，确定各节点IP地址，并且获取HDFS元数据在文件层中的实际存储路径；

步骤2.3：将HDFS元数据导出为xml格式，并将整个用户层信息获取过程中获取到的需要检索的时间线索、HDFS路径线索及HDFS文件名线索分别设为关键字在xml中检索，获取数据库详细信息，包括数据块id、修改时间和数据表文件名；若不存在，立即进行物理层上的HDFS数据恢复；

步骤2.4：将步骤2.3中获取到的数据块id与修改时间分别设为关键字，在Hadoop系统服务输出日志中进行检索，获取指定数据库自存在以后的被操作过的所有记录，并比对结果检查是否有重合；若有重合则验证Hadoop系统服务输出日志中的内容，若检索无果，说明Hadoop系统服务输出日志缺失、丢失或被清理，立即进行HDFS数据恢复。

在时间信息中修改时间mtime极为关键，只要进行了数据表内数据的增删改操作，都会使此表在HDFS中的修改时间mtime发生变化，因此修改时间mtime是逻辑关系建立的关键之一。Hive日志中的时间以太平洋时间的形式记录，而在HDFS的元数据中以时间戳的形式保存。关于日志中的HDFS路径信息极为详细，但是不排除日志被清除的可能，因此有必要通过Hive元数据库提取HDFS路径信息。

构建用户层与文件层的逻辑关系除了通过Hive日志和Hive元数据库以外，还可以通过HQL中的desc命令以及Hadoop的Web管理页面通过文件浏览的方式查询，但这些方式都是基于Hive元数据和HDFS元数据进行查询的，故在此不做详解。

具体实施时，首先访问文件层存放配置文件的目录并打开hdfs-site.xml，可从文件中获得HDFS元数据存放目录为，默认格式通常为：“/usr/local/Hadoop/hdfs/name”。访问此目录并将fsimage文件通过HDFS命令转换为XML文件并使用编辑器打开，因在Metastore中获取的HDFS路径中包含文件名，故在fsimage.xml中检索“<name>$table_name</name>”，查找HDFS目录$table_name对应的相关记录

通过在fsimage.xml检索后若确实存在相关记录，说明$table_name文件确实存在于HDFS文件系统中，且修改时间格式为时间戳，转换为太平洋时间设为T1，在Hive日志检索时曾检测到命令运行时间为T2，而文件的修改时间为T3，通过判断T3与T1和T2的关系可以判断命令运行过程。通常一条命令执行过程若修改了数据，则时间之间的关系为”T2<T1＝T3”。

步骤3：根据数据块的详细信息进行物理层数据块提取，具体包括：

步骤3.1：依据从文件层信息获取中构建的拓扑结构图和HDFS路径信息找到目标物理层的IP地址，访问物理层，并采取与国家授时中心等标准时间源的对时操作；

步骤3.2：将物理层中对应数据块id的数据块以只读方式导入至取证环境中，若无此数据块，则应进行HDFS数据恢复，并使用二进制编辑器查看数据块的头部，确定数据块使用的数据存储格式以及压缩方式。

建立文件层与物理层的逻辑关系即通过HDFS路径找到HDFS存储文件对应在物理层的数据块id。除了之前提到的Hadoop的管理Web页面可以直接获取相关内容以外，还可以使用Hadoop命令达到同样目的，但归根结底还是HDFS元数据文件edit和fsimage中内容的可视化。通过Hadoop命令行的方式可以将HDFS路径(HDFS_dir)下所有文件对应的数据块全部列举出来，具体命令格式为：hdfs fsck HDFS_dir-files-block。HDFS是依据元数据进行管理的，没有edit和fsimage整个HDFS也是无法使用的，因此最根本的逻辑关系建立的途径依然是通过解析HDFS元数据edit与fsimage。

Edit日志对HDFS的每次修改进行连续记录。为每个修改分配唯一的、单调增加的事务id。在给定时间间隔内启动Hadoop或触发检查点时，文件层会将最新的fsimage与edit日志之后记录的所有事务合并，以创建新的事务并删除过期的fsimage。Edit日志保存了自最后一次检查点之后所有针对HDFS文件系统的所有更新操作，比如：创建文件、重命名文件、移动文件、删除目录等。

fsimage维护命名空间的结构和文件的属性，例如所有权、访问权限、时间戳和分配的块等等。HDFS支持逻辑上由inode表示的文件层次结构。fsimage维护着HDFS整个目录树，HDFS文件的元数据通过inode存储在fsimage中。fsimage与edit需转换为XML格式可查看查看。

在fsimage的Path中包含标签inode、id、type和name，其中name即文件名。在数据块id中包含标签数据块和id，其中id就是数据块的id。取证人员在获取HDFS路径线索只有通过文件名在多个fsimage中检索即可找到数据块的id，之前提到过的修改时间mtime在此也可起到数据块筛选的作用，大幅度减少取证人员的工作量。

在以Hadoop框架为基础的云环境中的日志多种多样，总体上可分为两大类，即Hadoop系统服务输出日志和Mapreduce输出日志。

Hadoop系统服务输出的日志默认存放路径为${HADOOP_HOME}/logs目录下，默认文件后缀为“log”；当日志达到系统设定的阈值后将会切割出新的文件，切割出的文件名格式为“XXX.log.num”，后边的num数字越大，表示日志保存时间越早。系统默认保存近20个日志。日志的格式为一行一条，依次描述为日期、时间、类别、相关类和提示信息。其中类别“INFO BlockStateChange”表示文件逻辑块状态的变化，与操作行为密切相关，是验证文件层与物理层的关键信息。

取证人员在通过建立三层的逻辑关系后最终可以在HDFS元数据中获取到数据块的id，在使用Hadoop系统服务输出日志中需要使用到的信息为修改时间mtime与数据块的id，验证过程分为两步进行。第一步是将HDFS元数据中的修改时间mtime转为太平洋时间在Hadoop系统服务输出日志中检索，将数据块的id设为关键字进行检索。第二步为比对第一步的两项检索结果，看是否存在重合。若存在则说明数据块缺失在修改时间有所变化，验证在hive日志中检索出的内容，若无无重合或未检索到相关内容，则说明hive日志或Hadoop系统服务输出日志可能存在缺失、丢失等灾难情况。

具体实施时，要提取物理层中的数据块就必须获取具体表所存储block的id号并进行检索。在进行文件层信息提取时已在fsimage中获取到目录$table_name的相关记录，而在此条记录位置向下顺延即可找到在HDFS目录$table_name下面所存储的数据表数据文件的相关记录。据此在fsimage中$table_name目录的相关记录下找到数据块记录，在记录标签<id>中获得$table_name表的数据文件的block_id设为”$block_id”，加上数据块编号前缀即可组成在物理层对应的数据块名称为“blk_$block_id”。因为每个数据表的数据文件默认命名规则是一样的，因此存在多表同块名的情况，若一表多块或需获取多表数据块都需通过fsiamge中的inode结构，也可以通过WEB UI简便查询。

通过浏览器访问文件层的IP地址与端口号50070组成的URL，在文件浏览页面菜单可以直接获取HDFS文件对应的数据块信息，其原理即通过解析HDFS元数据文件中的inode等信息直接将块信息可视化显示出来。

数据删除命令与数据添加修改不同，因为Hive一次写入多次读取的特性，删除数据记录的方式为将数据记录全部提取并重新写入，所以必然会导致数据块的变化。在针对数据删除命令还原用户操作行为的过程中，首先通过Hadoop配置文件获取到文件层的Hadoop系统服务输出日志的目录并用编辑器打开。直接搜索块名“blk_$block_id”可以检索到时间为T4的表示块分配(allocate)的记录，在文件层信息获取过程中已检索到T2至T1期间为执行需要还原操作行为的命令执行的时间区间，而新数据块则分配给不包含被删除的数据记录，因此时间关系应为：T2<T4<T1。因此Hadoop系统服务输出日志中的内容也正印证了从客户层与物理层中获取信息的正确性。通过结合配置文件最终找到数据块存放目录，并将数据块提取至实验环境中进行进一步的数据提取操作。

步骤4：数据记录查看，具体为：

步骤4.1：在线索信息较为精准，数据量较少的情况下，TextFile、SequenceFile可直接通过Hadoop系统命令进行明文输出，RCFile、ORCFile、Parquet存储格式则使用元数据重构数据结构后进行查看，若存在压缩则应针对相应的数据格式压缩方式进行对应的解压；

步骤4.2：在线索信息较模糊，数据量较多的情况下，可通过将数据重新导入至集群实验环境中，通过集群的高运算能力进行对应数据记录查看操作。

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

Claims (3)

1.一种基于日志的Hive用户操作行为还原方法，其特征在于，包括如下步骤：

步骤1：对用户层服务器进行信息提取，获取HDFS路径；

步骤2：根据HDFS路径进行文件层信息提取，获取数据块的详细信息；

步骤3：根据数据块的详细信息进行物理层数据块提取；

步骤4：数据记录查看；

步骤1包括：

步骤1.1：访问用户层服务器，并采取与标准时间源的对时操作；

步骤1.2：依据用户层服务器中的Hive多个配置文件获取Hive日志存放路径、连接元数据库的用户名和密码、HDFS路径、驱动、Remote方式；

步骤1.3：访问获取的Hive日志存放路径，若事先掌握时间线索则对多个Hive日志文件进行筛选；若Hive日志文件的数据量较大则进行数据清洗，只保留用户操作的相关记录；若事先掌握时间线索对日志文件的内容进行筛选，若发现日志文件缺失或丢失，则立即进行HDFS数据恢复；

步骤1.4：针对步骤1.3筛选出的用户操作相关记录，设定关键字，检索包含HDFS路径的相关记录并整理；

步骤1.5：连接元数据库，基于元数据表DBS、TBLS、SDS中的字段DB_ID、SD_ID进行合并，构建完整的数据表与HDFS的关系，将结果与步骤1.4得到的结果进行比对和验证；

步骤2包括：

步骤2.1：访问文件层，并采取与标准时间源的对时操作；

步骤2.2：依据文件层的文件系统的配置文件内容构建平台环境拓扑结构，确定各节点IP地址，并且获取HDFS元数据在文件层中的实际存储路径；

步骤2.3：将HDFS元数据导出为xml格式，并将整个用户层信息获取过程中获取到的需要检索的时间线索、HDFS路径线索及HDFS文件名线索分别设为关键字在xml中检索，获取数据库详细信息，包括数据块id、修改时间和数据表文件名；若不存在，立即进行物理层上的HDFS数据恢复；

步骤2.4：将步骤2.3中获取到的数据块id与修改时间分别设为关键字，在Hadoop系统服务输出日志中进行检索，获取指定数据库自存在以后的被操作过的所有记录，并比对结果检查是否有重合；若有重合则验证Hadoop系统服务输出日志中的内容，若检索无果，说明Hadoop系统服务输出日志缺失、丢失或被清理，立即进行HDFS数据恢复；

步骤3包括：

步骤3.1：依据从文件层信息获取中构建的拓扑结构图和HDFS路径信息找到目标物理层的IP地址，访问物理层，并采取与标准时间源的对时操作；

步骤3.2：将物理层中对应数据块id的数据块以只读方式导入至取证环境中，若无此数据块，则应进行HDFS数据恢复，并使用二进制编辑器查看数据块的头部，确定数据块使用的数据存储格式以及压缩方式。

2.如权利要求1所述的基于日志的Hive用户操作行为还原方法，其特征在于，所述步骤1.2中若取证环境使用Remote，还应提取Mysql服务器地址及端口信息。

3.如权利要求1所述的基于日志的Hive用户操作行为还原方法，其特征在于，步骤4具体为：

步骤4.1：在线索信息较为精准，数据量较少的情况下，TextFile、SequenceFile可直接通过Hadoop系统命令进行明文输出，RCFile、ORCFile、Parquet 存储格式则使用元数据重构数据结构后进行查看，若存在压缩则应针对相应的数据格式压缩方式进行对应的解压；

步骤4.2：在线索信息较模糊，数据量较多的情况下，可通过将数据重新导入至集群实验环境中，通过集群的高运算能力进行对应数据记录查看操作。

Images