查找:                      转第 显示法宝之窗 隐藏相关资料 下载下载 收藏收藏 打印打印 转发转发 小字 小字 大字 大字
【期刊名称】 《中国刑警学院学报》
利用日志文件实现Hive用户操作行为还原
【英文标题】 Restoration of Hive User Operation Behavior Using Log Files
【作者】 罗文华王志铭
【作者单位】 中国刑事警察学院网络犯罪侦查系{教授}中国刑事警察学院网络犯罪侦查系
【分类】 刑事侦察学
【中文关键词】 Hive;操作行为还原;逻辑关系;存储格式
【英文关键词】 Hive, Operational behavior reduction, Logical relationship, Storage format
【文章编码】 2095-7939(2019)05-0103-08
【文献标识码】 A DOI: 10.14060/j.issn.2095-7939.2019.05.014
【期刊年份】 2019年【期号】 5
【页码】 103
【摘要】

在还原云平台环境下用户行为场景,以分布式系统架构框架Hadoop为研究基础,通过解析Hadoop系统日志、分布式文件系统HDFS日志及数据仓库Hive日志和元数据,对比传统数据库用户操作行为还原方法,深入挖掘了用户在进行Hive相关操作后于Hive数据层、HDFS逻辑文件层及底层Linux常用文件系统层面引起的一系列变化规律,建立各层面之间的完整逻辑关系,进而搭建完整证据链。并对Hive使用的多种数据存储格式进行了解析,为行为还原之后的数据记录提取奠定技术基础。

【英文摘要】

Based on the architecture framework of distributed system, the Hadoop system logs, distributed file system HDFS logs, and data warehouse Hive logs and metadata are compared to the traditional database user operation behavior restoration methods, and the user sare deeply explored after Hive-related operations. A series of changes caused by Hive data layer, HDFS logical file layer and the underlying Linux common file system level, establish a complete logical relationship between each level, and then build a complete evidence chain. It also analyzes various data storage formats used by Hive, and lays a technical foundation for data record extraction after behavior restoration.

【全文】法宝引证码CLI.A.1281977    
  
  

1引言

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

Hive与传统数据库{2}不论是在底层框架还是数据结构上都是大相径庭的,在取证方面唯一共通点就是都依赖系统日志及各种元数据。国内外在Hive取证工作尤其是用户操作行为还原方面的研究极少,因此本文通过分析HDFS元数据、Hive日志及Hadoop系统服务输出日志,构建Hive各层之间的逻辑关系,实现依据具体线索信息减少取证工作量,并通过多维证据的相互印证提高证明效力。

2 Hive存储逻辑关系

Hive整体的系统构架在运营层面来看可以分为元数据库和数据库两部分,但在用户行为还原角度可以分为用户层、文件层和物理层。具体结构如图1所示。

用户层即用户进行Hive操作直接对应的层面。首先用户通过接口将操作发送给命令解释模块driver, driver会将命令进行解释,然后交由文件层处理。元数据库单独存放于Meta store中,由传统关系型数据库进行管理,通常为mysql,而数据就存储于Hive数据仓库中。在用户操作期间会在Hive日志中详细记录。文件层Hadoop将用户层driver模块解释的命令分解成多个任务发送给Hadoop的从节点Data node,并将数据存储于Hadoop的分布式文件系统HDFS中,而HDFS的元数据fsimage与edit负责进行文件的管理和记录。物理层即搭建Hadoop框架为基础的底层Linux操作系统及其文件系统,HDFS架构基于特定的节点结构,主要包括Name node和Data node。HDFS通过块的方式存储文件,对应到底层Linux文件系统就是经过名称编号大小相同的文件。图2表示用户操作行为引起Hive3层文件变化的过程及记录变化的日志或元数据。

(图略)

图1 Hive系统构架图

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

要进行用户操作行为还原,就必须通过构建用户层、文件层及物理层的逻辑关系,以准确地识别用户操作行为涉及的逻辑文件和块,取证人员可通过3层逻辑关系进行有针对性的数据恢复和证据固定。

2.1用户层与文件层的逻辑关系

建立用户层与文件层的逻辑关系,即如何通过用户操作行为找到操作所影响的文件层面的文件。用户的操作会导致HDFS文件属性的变化,并被Hive日志和元数据记录。因此用户层与文件层逻辑关系的建立可分为通过Hive日志获取相关数据库的HDFS路径信息和通过元数据库获取相关数据库的HDFS路径两种方法。

(1)通过Hive日志获取数据库线索。因不同平台环境下的Hive日志设置不同{3},取证人员可以通过Hive根目录conf目录下的属性文件hive-log4j2.properties来查看Hive日志的存放路径。文件具体内容如表1所示。

开弓没有回头箭

表1 hive-log4j2.properties主要内容

┌──────────────────┬─────────────────┐
│参数名               │参数释义             │
├──────────────────┼─────────────────┤
│Property .hive.log.dir       │Hive日志存放路径         │
├──────────────────┼─────────────────┤
│property.hive.log.file       │Hive日志名            │
└──────────────────┴─────────────────┘

Hive日志会在达到系统设定的阈值后自动保存成名为“property.hive.log.file+日期”的旧Hive日志文件,并生成名为“property.hive.log.file”的新Hive日志,其中包含了大量用户操作的时间信息、具体操作内容及系统自动输出的记录。Hive日志中包含用户所有操作命令、过程及系统反馈等信息,取证人员可以将“command”作为关键字进行用户操作所有命令的检索(生产环境需要数据清洗),也可以将“create”作为关键字检索创建表的记录。在用户命令中就包括数据表的名称、创建时间及操作涉及到的HDFS路径等信息。在时间信息中mtime参数极为关键,只要进行了数据表内数据的增删改操作,都会使此表在HDFS中的mtime发生变化,因此mtime是逻辑关系建立的关键之一。Hive日志中的时间以太平洋时间的形式记录,而在HDFS的元数据中以时间戳的形式保存。关于日志中的HDFS路径信息极为详细,但是不排除日志被清除的可能,因此还有必要通过Hive元数据库提取HDFS路径信息。

(2)通过元数据库建立逻辑关系。Hive元数据是存储在Hive中的数据的描述信息。Hive将元数据存储在数据库中,默认使用derby维护,但只能实现单用户模式,而且存储目录不固定,不方便管理。因此在生产环境中是以Mysql来管理元数据库数据的。元数据库中共有53个表,但涉及用户层与文件层逻辑关系建立仅需要DBS、TBLS和SDS 3个表所存的数据进行结合,这也提高了通过元数据库建立用户层与文件层逻辑关系的可行性。

在串联DBS、TBLS和SDS时应以TBLS为核心,因为TBLS中的DB—ID、SD—ID可以分别串联表DBS与SDS。整个逻辑关系建立及后期数据块识别过程中涉及DBS、TBLS和SDS内字段如表2所示。其中包括表创建时间、数据输入输出格式等字段。

表2元数据表关键字段及描述

┌──────────┬────────────┬─────────────┐
│元数据表名     │字段          │字段描述         │
├──────────┼────────────┼─────────────┤
│DBS         │DB—ID         │数据库ID         │
│          ├────────────┼─────────────┤
│          │DESC          │数据库描述        │
├──────────┼────────────┼─────────────┤
│TBLS        │TBL—ID         │表ID           │
│          ├────────────┼─────────────┤
│          │CREATE—TIME      │创建时间         │
│          ├────────────┼─────────────┤
│          │DB—ID         │数据库ID         │
│          ├────────────┼─────────────┤
│          │SD_ID          │序列化配置信息      │
│          ├────────────┼─────────────┤
│          │TBL_NAME        │表名           │
├──────────┼────────────┼─────────────┤
│SDS         │SD_ID          │存储信息ID        │
│          ├────────────┼─────────────┤
│          │INPUT_FORMAT      │文件输入格式       │
│          ├────────────┼─────────────┤
│          │IS_COMPRESSED      │是否压缩         │
│          ├────────────┼─────────────┤
│          │LOCATION        │数据表HDFS路径      │
│          ├────────────┼─────────────┤
│          │OUTPUT—FORMAT     │文件输出格式       │
└──────────┴────────────┴─────────────┘

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

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

(1)通过HDFS元数据建立HDFS文件与block逻辑关系。edit日志对HDFS的每次修改进行连续记录。为每个修改分配唯一的、单调增加的事务ID。在给定时间间隔内启动Hadoop或触发检查点时, Name Node会将最新的fsimage与edit日志之后记录的所有事务合并,以创建新的事务并删除过期的fsimagecedit日志保存了自最后一次检查点之后所有针对HDFS文件系统的所有更新操作。如创建文件、重命名文件、移动文件、删除目录等。

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

(图略)

图3 fsimage元文件结构

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

(2)通过Hadoop系统服务输出日志验证。在以Hadoop框架为基础的云环境中的日志多种多样,总体上可分为两大类,即Hadoop系统服务输出日志和Mapreduce输出日志{5}。

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

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

3 Hive数据存储格式及特征

通过实现3层逻辑关系的建立,取证人员最终可以实现用户操作行为记录在文件层面的还原,整个过程最终指向用户操作行为对应的HDFS文件在Linux的文件系统上存储的数据块block,但仍未具体到数据块存储的数据,故仍需进行数据块存储格式及特征的分析和识别。

3.1 Hive的5种数据存储格式

表3 Hive存储格式及特点

┌────┬───┬─────┬──────────────────────┐
│存储格式│存储方│压缩格式 │特点                    │
│    │式  │     │                      │
├────┼───┼─────┼──────────────────────┤
│Text Fil│行存储│本身无压缩│存储占用空间最大,且引用压缩方式后的Text Fil│
│e    │   │,可结合Gz│e无法进行分割和合并,而且Text File的查询效率│
│    │   │ip、Bzip2 │低,但具有较高加载速度,可直接存储。    │
│    │   │、 Snappy │                      │
├────┼───┼─────┼──────────────────────┤
│Sequence│行存储│none、 rec│存储占用空间较大,经压缩后的文件可以分割和合│
│ File  │   │ord (默认)│并,具有较高查询效率,本身需要通过Text File │
│    │   │、block  │文件转化来加载。与Text File的区别在于Sequenc│
│    │   │     │e File是以二进制方式存储的,同时支持文件切割│
│    │   │     │分片。数据本身由Header、Record(Key、Value)、│
│    │   │     │Sync等存储特征组成。可直接通过hadoopfs -text│
│    │   │     │$file命令进行数据记录的可视化提取。     │
├────┼───┼─────┼──────────────────────┤
│RC File │行列存│自行压缩 │存储空间最小,查询的效率最高,需要通过Text F│
│    │储  │     │ile文件转化来加载,加载的速度最低,但压缩快 │
│    │   │     │,快速列存取。其本身的读取方式再读记录时涉及│
│    │   │     │很少的block,读取需要的列只需读取每个row gro│
│    │   │     │up的头部定义。但是再全量读取方面较Sequencefi│
│    │   │     │le提升效果并不明显。数据本身由Header、Record│
│    │   │     │(Key、Value)等存储特征组成。        │
├────┼───┼─────┼──────────────────────┤
│ORC File│行列存│自行压缩 │压缩快,快速列存取,是RC File的改良版本。相 │
│    │储  │     │比RC File, ORC File减少Name node负载,支持复│
│    │   │     │杂类型、存储索引数据、脱离扫描标记进行文件分│
│    │   │     │割等优点。以二进制方式存储,一个ORC File包含│
│    │   │     │多个stripe,一个stripe包含多条数据记录,记录│
│    │   │     │按列进行独立存储。ORC File为自解析,包含诸多│
│    │   │     │元数据。                  │
├────┼───┼─────┼──────────────────────┤
│Parquet │列存储│自行压缩 │相对于PRC, Parquet压缩比较低,查询效率较低,│
│    │   │     │不支持update、insert和ACID.但是Parquet支持Im│
│    │   │     │pala查询引擎。

  ······

法宝用户,请登录后查看全部内容。
还不是用户?点击单篇购买;单位用户可在线填写“申请试用表”申请试用或直接致电400-810-8266成为法宝付费用户。
【注释】                                                                                                     
【参考文献】

{1}罗文华,王志铭.基于存储形态及特征的HBase数据库灾难恢复机制研究[J].信息网络安全,2018(9):42-47.

{2}刘奇志. Oracle数据库的调查取证方法研究[J].中国刑警学院学报,2008(2):28-30.

{3}王建辉.基于Hive的日志分析系统的实现与优化[D].南京:南京邮电大学,2017:6-16.

{4}翟永东. Hadoop分布式文件系统(HDFS)可靠性的研究与优化[D].武汉:华中科技大学,2011:7-23.

{5}马宇超.基于分布式系统的海量日志数据库优化技术研究[D].北京:北京邮电大学,2016:5-11.

{6}姜凤燕,姜瑾,姜吉婷.基于大数据环境的电子取证研究[J].信息网络安全,2016(9):60-63.

{7}罗文华,王俊,孙媛媛.基于云服务端的节点多层次数据协同分析研究[J].信息网络安全,2018(3):39-45.

©北大法宝:(www.pkulaw.cn)专业提供法律信息、法学知识和法律软件领域各类解决方案。北大法宝为您提供丰富的参考资料,正式引用法规条文时请与标准文本核对
欢迎查看所有产品和服务。法宝快讯:如何快速找到您需要的检索结果?    法宝V5有何新特色?
扫码阅读
本篇【法宝引证码CLI.A.1281977      关注法宝动态:  

法宝联想
【相似文献】

热门视频更多