羅文華 王志銘

（中國刑事警察學(xué)院網(wǎng)絡(luò)犯罪偵查系 遼寧 沈陽 110035）

1 引言

隨著移動設(shè)備的普及和互聯(lián)網(wǎng)業(yè)務(wù)的創(chuàng)新發(fā)展，各行各業(yè)產(chǎn)生的數(shù)據(jù)日益增長并不斷累積。這些海量數(shù)據(jù)的產(chǎn)生推動了高性能云平臺的發(fā)展，而Hadoop是眾多云框架中較成熟、使用較廣的架構(gòu)[1]。Hadoop使用數(shù)據(jù)倉庫Hive存儲海量的、非結(jié)構(gòu)化的數(shù)據(jù)。運營人員可以通過Hive存儲的海量數(shù)據(jù)挖掘出大量含有巨大價值的信息。因此在取證方面，針對Hive的取證工作至關(guān)重要，對于Hive取證工作的研究不僅可以遏制犯罪行為的繼續(xù)，還能及時幫助企業(yè)、部門挽回?zé)o法估量的損失。

Hive與傳統(tǒng)數(shù)據(jù)庫[2]不論是在底層框架還是數(shù)據(jù)結(jié)構(gòu)上都是大相徑庭的，在取證方面唯一共通點就是都依賴系統(tǒng)日志及各種元數(shù)據(jù)。國內(nèi)外在Hive取證工作尤其是用戶操作行為還原方面的研究極少，因此本文通過分析HDFS元數(shù)據(jù)、Hive日志及Hadoop系統(tǒng)服務(wù)輸出日志，構(gòu)建Hive各層之間的邏輯關(guān)系，實現(xiàn)依據(jù)具體線索信息減少取證工作量，并通過多維證據(jù)的相互印證提高證明效力。

2 Hive存儲邏輯關(guān)系

Hive整體的系統(tǒng)構(gòu)架在運營層面來看可以分為元數(shù)據(jù)庫和數(shù)據(jù)庫兩部分，但在用戶行為還原角度可以分為用戶層、文件層和物理層。具體結(jié)構(gòu)如圖1所示。

用戶層即用戶進(jìn)行Hive操作直接對應(yīng)的層面。首先用戶通過接口將操作發(fā)送給命令解釋模塊driver，driver會將命令進(jìn)行解釋，然后交由文件層處理。元數(shù)據(jù)庫單獨存放于metastore中，由傳統(tǒng)關(guān)系型數(shù)據(jù)庫進(jìn)行管理，通常為mysql，而數(shù)據(jù)就存儲于Hive數(shù)據(jù)倉庫中。在用戶操作期間會在Hive日志中詳細(xì)記錄。文件層Hadoop將用戶層driver模塊解釋的命令分解成多個任務(wù)發(fā)送給Hadoop的從節(jié)點DataNode，并將數(shù)據(jù)存儲于Hadoop的分布式文件系統(tǒng)HDFS中，而HDFS的元數(shù)據(jù)fsimage與edit負(fù)責(zé)進(jìn)行文件的管理和記錄。物理層即搭建Hadoop框架為基礎(chǔ)的底層Linux操作系統(tǒng)及其文件系統(tǒng)，HDFS架構(gòu)基于特定的節(jié)點結(jié)構(gòu)，主要包括NameNode和DataNode。HDFS通過塊的方式存儲文件，對應(yīng)到底層Linux文件系統(tǒng)就是經(jīng)過名稱編號大小相同的文件。圖2表示用戶操作行為引起Hive3層文件變化的過程及記錄變化的日志或元數(shù)據(jù)。

圖1 Hive系統(tǒng)構(gòu)架圖

圖2 用戶操作行為對應(yīng)的文件變化

要進(jìn)行用戶操作行為還原，就必須通過構(gòu)建用戶層、文件層及物理層的邏輯關(guān)系，以準(zhǔn)確地識別用戶操作行為涉及的邏輯文件和塊，取證人員可通過3層邏輯關(guān)系進(jìn)行有針對性的數(shù)據(jù)恢復(fù)和證據(jù)固定。

2.1 用戶層與文件層的邏輯關(guān)系

建立用戶層與文件層的邏輯關(guān)系，即如何通過用戶操作行為找到操作所影響的文件層面的文件。用戶的操作會導(dǎo)致HDFS文件屬性的變化，并被Hive日志和元數(shù)據(jù)記錄。因此用戶層與文件層邏輯關(guān)系的建立可分為通過Hive日志獲取相關(guān)數(shù)據(jù)庫的HDFS路徑信息和通過元數(shù)據(jù)庫獲取相關(guān)數(shù)據(jù)庫的HDFS路徑兩種方法。

（1）通過Hive日志獲取數(shù)據(jù)庫線索。因不同平臺環(huán)境下的Hive日志設(shè)置不同[3]，取證人員可以通過Hive根目錄conf目錄下的屬性文件hive-log4j2.properties來查看Hive日志的存放路徑。文件具體內(nèi)容如表1所示。

表1 hive-log4j2.properties主要內(nèi)容

Hive日志會在達(dá)到系統(tǒng)設(shè)定的閾值后自動保存成名為“property.hive.log.file+日期”的舊Hive日志文件，并生成名為“property.hive.log.file”的新Hive日志，其中包含了大量用戶操作的時間信息、具體操作內(nèi)容及系統(tǒng)自動輸出的記錄。Hive日志中包含用戶所有操作命令、過程及系統(tǒng)反饋等信息，取證人員可以將“command”作為關(guān)鍵字進(jìn)行用戶操作所有命令的檢索(生產(chǎn)環(huán)境需要數(shù)據(jù)清洗) ，也可以將“create”作為關(guān)鍵字檢索創(chuàng)建表的記錄。在用戶命令中就包括數(shù)據(jù)表的名稱、創(chuàng)建時間及操作涉及到的HDFS路徑等信息。在時間信息中mtime參數(shù)極為關(guān)鍵，只要進(jìn)行了數(shù)據(jù)表內(nèi)數(shù)據(jù)的增刪改操作，都會使此表在HDFS中的mtime發(fā)生變化，因此mtime是邏輯關(guān)系建立的關(guān)鍵之一。Hive日志中的時間以太平洋時間的形式記錄，而在HDFS的元數(shù)據(jù)中以時間戳的形式保存。關(guān)于日志中的HDFS路徑信息極為詳細(xì)，但是不排除日志被清除的可能，因此還有必要通過Hive元數(shù)據(jù)庫提取HDFS路徑信息。

（2）通過元數(shù)據(jù)庫建立邏輯關(guān)系。Hive元數(shù)據(jù)是存儲在 Hive 中的數(shù)據(jù)的描述信息。Hive將元數(shù)據(jù)存儲在數(shù)據(jù)庫中，默認(rèn)使用derby維護(hù)，但只能實現(xiàn)單用戶模式，而且存儲目錄不固定，不方便管理。因此在生產(chǎn)環(huán)境中是以Mysql來管理元數(shù)據(jù)庫數(shù)據(jù)的。元數(shù)據(jù)庫中共有53個表，但涉及用戶層與文件層邏輯關(guān)系建立僅需要DBS、TBLS和SDS 3個表所存的數(shù)據(jù)進(jìn)行結(jié)合，這也提高了通過元數(shù)據(jù)庫建立用戶層與文件層邏輯關(guān)系的可行性。

在串聯(lián)DBS、TBLS和SDS時應(yīng)以TBLS為核心，因為TBLS中的DB_ID、SD_ID可以分別串聯(lián)表DBS與SDS。整個邏輯關(guān)系建立及后期數(shù)據(jù)塊識別過程中涉及DBS、TBLS和SDS內(nèi)字段如表2所示。其中包括表創(chuàng)建時間、數(shù)據(jù)輸入輸出格式等字段。

表2 元數(shù)據(jù)表關(guān)鍵字段及描述

構(gòu)建用戶層與文件層的邏輯關(guān)系除了通過Hive日志和Hive元數(shù)據(jù)庫以外，還可以通過HQL中的desc命令及Hadoop的Web管理頁面通過文件瀏覽的方式查詢，但這些方式都是基于Hive元數(shù)據(jù)和HDFS元數(shù)據(jù)進(jìn)行查詢的，故在此不做詳解。

2.2 文件層與物理層的邏輯關(guān)系

建立文件層與物理層的邏輯關(guān)系，即通過HDFS路徑找到HDFS存儲文件對應(yīng)在物理層的文件塊block的ID。除了之前提到的Hadoop的管理Web頁面可以直接獲取相關(guān)內(nèi)容以外，還可以使用Hadoop命令達(dá)到同樣目的，但歸根結(jié)底還是HDFS元數(shù)據(jù)文件edit和fsimage中內(nèi)容的可視化。通過Hadoop命令行的方式可以將HDFS路徑（HDFS_dir）下所有文件對應(yīng)的block全部列舉出來，具體命令格式hdfsfsckHDFS_dir-files-block。HDFS是依據(jù)元數(shù)據(jù)進(jìn)行管理的，沒有edit和fsimage整個HDFS也是無法使用的，因此最根本的邏輯關(guān)系建立的途徑依然是通過解析HDFS元數(shù)據(jù)edit與fsimage。

（1）通過HDFS元數(shù)據(jù)建立HDFS文件與block邏輯關(guān)系。edit日志對HDFS的每次修改進(jìn)行連續(xù)記錄。為每個修改分配唯一的、單調(diào)增加的事務(wù)ID。在給定時間間隔內(nèi)啟動Hadoop或觸發(fā)檢查點時，NameNode會將最新的fsimage與edit日志之后記錄的所有事務(wù)合并，以創(chuàng)建新的事務(wù)并刪除過期的fsimage。edit日志保存了自最后一次檢查點之后所有針對HDFS文件系統(tǒng)的所有更新操作。如創(chuàng)建文件、重命名文件、移動文件、刪除目錄等。

fsimage維護(hù)命名空間的結(jié)構(gòu)和文件的屬性。例如所有權(quán)、訪問權(quán)限、時間戳和分配的塊等。HDFS支持邏輯上由inode表示的文件層次結(jié)構(gòu)。fsimage維護(hù)著HDFS整個目錄樹，HDFS文件的元數(shù)據(jù)通過inode存儲在fsimage中[4]。fsimage與edit需轉(zhuǎn)換為XML格式可查看，XML形式的fsimage文件結(jié)構(gòu)如圖3所示。

圖3 fsimage元文件結(jié)構(gòu)

在fsimage的Path中包含標(biāo)簽inode、id、type和name，其中name即文件名。在blockid中包含標(biāo)簽block、id，其中id就是block的id。取證人員在獲取HDFS路徑線索只有通過文件名在多個fsimage中檢索，即可找到block的id，之前提到過的mtime在此也可起到block篩選的作用，大幅度減少取證人員的工作量。

（2）通過Hadoop系統(tǒng)服務(wù)輸出日志驗證。在以Hadoop框架為基礎(chǔ)的云環(huán)境中的日志多種多樣，總體上可分為兩大類，即Hadoop系統(tǒng)服務(wù)輸出日志和Mapreduce輸出日志[5]。

Hadoop系統(tǒng)服務(wù)輸出的日志默認(rèn)存放路徑為${HADOOP_HOME}/logs目錄下，默認(rèn)文件后綴為“l(fā)og”；當(dāng)日志達(dá)到系統(tǒng)設(shè)定的閾值后將會切割出新的文件，切割出的文件名格式為“XXX.log.num”，后邊的num數(shù)字越大，表示日志保存時間越早。系統(tǒng)默認(rèn)保存近20個日志。日志的格式為一行一條，依次描述為日期、時間、類別、相關(guān)類和提示信息。其中類別“INFO BlockStateChange”表示文件邏輯塊狀態(tài)的變化，與操作行為密切相關(guān)，是驗證文件層與物理層的關(guān)鍵信息。

取證人員在通過建立3層的邏輯關(guān)系后最終可以在HDFS元數(shù)據(jù)中獲取到block的id，在使用Hadoop系統(tǒng)服務(wù)輸出日志中需要使用到的信息為mtime與block的id，驗證過程分為兩步進(jìn)行。第一步是將HDFS元數(shù)據(jù)中的mtime轉(zhuǎn)為太平洋時間在Hadoop系統(tǒng)服務(wù)輸出日志中檢索，將block的id設(shè)為關(guān)鍵字進(jìn)行檢索。第二步為比對第一步的兩項檢索結(jié)果，看是否存在重合。若存在則說明數(shù)據(jù)塊缺失在修改時間有所變化，驗證在Hive日志中檢索出的內(nèi)容，若無重合或未檢索到相關(guān)內(nèi)容，則說明Hive日志或Hadoop系統(tǒng)服務(wù)輸出日志可能存在缺失、丟失等災(zāi)難情況。

3 Hive數(shù)據(jù)存儲格式及特征

通過實現(xiàn)3層邏輯關(guān)系的建立，取證人員最終可以實現(xiàn)用戶操作行為記錄在文件層面的還原，整個過程最終指向用戶操作行為對應(yīng)的HDFS文件在Linux的文件系統(tǒng)上存儲的數(shù)據(jù)塊block，但仍未具體到數(shù)據(jù)塊存儲的數(shù)據(jù)，故仍需進(jìn)行數(shù)據(jù)塊存儲格式及特征的分析和識別。

3.1 Hive的5種數(shù)據(jù)存儲格式

Hive本身不提供數(shù)據(jù)存儲格式。其可以利用其他存儲數(shù)據(jù)的格式，存儲格式有5種：TextFile、SequenceFile、RCFile、ORCFile和Parquet。其中TextFile和SequenceFile為行式存儲，Parquet為列式存儲，RCFile及改進(jìn)版本的ORCFile為行列式存儲。行式存儲跟傳統(tǒng)關(guān)系型數(shù)據(jù)庫一樣，將數(shù)據(jù)記錄分條存儲。列式存儲則是將數(shù)據(jù)按列分割后加入識別標(biāo)記進(jìn)行存儲，可以實現(xiàn)跨越式查詢。行列式存儲則是綜合以上兩種方案，按行分割并按列存儲。針對以上多種數(shù)據(jù)存儲格式進(jìn)行恢復(fù)數(shù)據(jù)塊的識別，對于后期數(shù)據(jù)記錄的提取具有決定性的作用。Hive存儲格式的具體特點如表3所示。

表3 Hive存儲格式及特點

因為Hive是文本批處理系統(tǒng)，在向Hive中導(dǎo)入數(shù)據(jù)的格式多種多樣，比如數(shù)據(jù)源可能是二進(jìn)制格式或文本等，而Hive不需要特定的數(shù)據(jù)格式，而是利用hadoop本身InputFormat API來從各種數(shù)據(jù)源獲取數(shù)據(jù)，并使用OutputFormat API將數(shù)據(jù)存儲為不同的數(shù)據(jù)格式。所以針對不同的數(shù)據(jù)源或存儲成不同的數(shù)據(jù)格式只需不同的InputFormat和Outputformat類即可實現(xiàn)。在本文2 Hive存儲邏輯關(guān)系章中已提到通過元數(shù)據(jù)庫SDS可以查詢到數(shù)據(jù)庫數(shù)據(jù)輸入輸出的參數(shù)，這里不再詳述。

3.2 ORCFile

ORCFile在Hive使用的5種數(shù)據(jù)存儲格式中是具有最高壓縮比和效率的，除特殊情況需要使用到Parquet以外，生產(chǎn)環(huán)境中ORCFile一直占據(jù)主導(dǎo)地位，因此本文特別針對ORCFile存儲格式、存儲方式及存儲特征進(jìn)行一定程度的分析，以便取證人員在進(jìn)行后期數(shù)據(jù)記錄提取時方便展開工作。

ORCFile是RCFile經(jīng)過一些優(yōu)化后的高效存儲格式，其提供一種高效的方法來存儲Hive數(shù)據(jù)。ORCFile克服Hive了其他數(shù)據(jù)存儲格式的種種缺陷，提高了Hive的讀寫及處理數(shù)據(jù)的性能。ORCFile格式較RCFile減少了Namenode負(fù)載，同時還支持復(fù)雜數(shù)據(jù)類型、存儲索引數(shù)據(jù)，支持脫離掃描標(biāo)記進(jìn)行文件分割等優(yōu)點。

ORCFile是以二進(jìn)制方式存儲的，故無法直接讀取，一個ORCFile包含多個stripe，每一個stripe包含多條記錄，這些記錄按列進(jìn)行獨立存儲。同時ORCFile為自解析，包含許多元數(shù)據(jù)。ORCFile的文件結(jié)構(gòu)如圖4所示。

圖4 ORCFile文件結(jié)構(gòu)

（1）文件級元數(shù)據(jù)：包括文件的描述信息PostScript、文件meta信息（包括整個文件的統(tǒng)計信息）、所有stripe的信息和文件schema信息。

（2）stripe：一組行形成一個stripe，每次讀取文件是以行組為單位的，一般為HDFS的塊大小，其保存了每一列的索引和數(shù)據(jù)。其具體組成如下：①IndexData保存的是每一列的最大值和最小值，以及每一列所在的行。②row_index包括了該行的偏移量及改行的長度，正是因為row_index使得在讀取數(shù)據(jù)時可以跳到正確的壓縮塊位置。例如：Stream:column 0 section ROW_INDEX start:3 length 11，Stream:column 1 section ROW_INDEX start: 14 length 28。③RowData保存的實際數(shù)據(jù)。④StripeFooterstream的位置信息。

（3）row group：索引的最小單位，一個stripe中包含多個row group，默認(rèn)為10000個值組成。

（4）stream：一個stream表示文件中一段有效的數(shù)據(jù)，包括索引和數(shù)據(jù)兩類。索引stream保存每一個row group的位置和統(tǒng)計信息，數(shù)據(jù)stream包括多種類型的數(shù)據(jù)，具體需要哪幾種是由該列類型和編碼方式?jīng)Q定。

Hive中提供了更詳細(xì)的查看ORCFile元數(shù)據(jù)的工具 orcfiledump，orcfiledump將元數(shù)據(jù)以json格式返回，通過這些元數(shù)據(jù)可以幫助取證人員在后期數(shù)據(jù)記錄提取的過程中所需要的關(guān)鍵信息，只有獲取了這些關(guān)鍵信息，取證人員才可以進(jìn)一步挖掘恢復(fù)數(shù)據(jù)塊中的數(shù)據(jù)，重構(gòu)數(shù)據(jù)結(jié)構(gòu)并填充數(shù)據(jù)，以可視化形式將數(shù)據(jù)記錄輸出[6]。

4 Hive用戶操作行為記錄還原方法

基于日志文件的Hadoop數(shù)據(jù)倉庫Hive用戶操作行為還原方法的最大特點在于將Hive分為3層架構(gòu)，并通過建立用戶層、文件層和物理層之間的邏輯關(guān)系實現(xiàn)用戶操作行為的還原。在建立邏輯關(guān)系過程中實現(xiàn)了多條途徑一種效果的線索獲取方式，可以針對線索信息進(jìn)行印證以提高可信度。

4.1 Metastore信息提取

（1）使用提供的用戶名/密碼或遠(yuǎn)程訪問Metastore服務(wù)器，并采取與國家授時中心等標(biāo)準(zhǔn)時間源的對時操作。

（2）依據(jù)Metastore服務(wù)器中的Hive多個配置文件獲取Hive日志存放路徑、連接元數(shù)據(jù)庫的用戶名和密碼、HDFS路徑、驅(qū)動、Remote方式等。若取證環(huán)境使用Remote，還應(yīng)提取Mysql服務(wù)器地址及端口信息。

（3）訪問在步驟（2）中獲取的Hive日志存放路徑，若事先掌握時間線索可以對多個Hive日志文件進(jìn)行篩選。若Hive日志數(shù)據(jù)量較大應(yīng)進(jìn)行數(shù)據(jù)清洗，只保留用戶操作的相關(guān)記錄，若事先掌握時間線索可以對日志內(nèi)容進(jìn)行篩選。若發(fā)現(xiàn)日志文件缺失或丟失，應(yīng)立即進(jìn)行HDFS數(shù)據(jù)恢復(fù)。

（4）針對在步驟（3）篩選出的用戶操作相關(guān)記錄設(shè)定關(guān)鍵字檢索包含HDFS路徑的相關(guān)記錄并整理。

（5）連接元數(shù)據(jù)庫，通過將元數(shù)據(jù)表DBS、TBLS、SDS中的基于字段DB_ID、SD_ID進(jìn)行合并，構(gòu)建完整的數(shù)據(jù)表與HDFS的關(guān)系，將結(jié)果與步驟（4）得到的結(jié)果進(jìn)行比對和驗證。若有具體表的需求，可在步驟（4）（5）獲取的信息中檢索。

4.2 Namenode信息提取

（1）使用提供的用戶名/密碼現(xiàn)場或遠(yuǎn)程訪問管理者主機，并采取與國家授時中心等標(biāo)準(zhǔn)時間源的對時操作。

（2）依Namenode中的文件系統(tǒng)的配置文件內(nèi)容構(gòu)建平臺環(huán)境拓?fù)浣Y(jié)構(gòu)，確定各節(jié)點IP地址。并且獲取HDFS元數(shù)據(jù)在集群中的實際存儲路徑。

（3）將HDFS元數(shù)據(jù)導(dǎo)出為XML格式，并將整個Metastore信息獲取過程中獲取到的需要檢索的時間線索、HDFS路徑線索及HDFS文件名線索分別設(shè)為關(guān)鍵字在XMLl中檢索，獲取數(shù)據(jù)id、修改時間和數(shù)據(jù)表文件名。若不存在，則說明文件已經(jīng)被刪除，應(yīng)立即進(jìn)行DataNode節(jié)點上的HDFS數(shù)據(jù)恢復(fù)[7]。

（4）將步驟（3）中獲取到的block_id與mtime分別設(shè)為關(guān)鍵字在Hadoop系統(tǒng)服務(wù)輸出日志中進(jìn)行檢索，獲取指定block自存在以后的被操作過的所有記錄，并比對結(jié)果檢查是否有重合。若有重合則驗證Hadoop系統(tǒng)服務(wù)輸出日志中的內(nèi)容。若檢索無果，說明Hadoop系統(tǒng)服務(wù)輸出日志缺失、丟失或被清理，應(yīng)立即進(jìn)行HDFS數(shù)據(jù)恢復(fù)。

4.3 Datanode信息獲取

（1）依據(jù)從Namenode信息獲取中構(gòu)建的拓?fù)浣Y(jié)構(gòu)圖和HDFS路徑信息找到目標(biāo)Datanode的IP地址，使用提供的用戶名/密碼現(xiàn)場或遠(yuǎn)程訪問Datanode，并采取與國家授時中心等標(biāo)準(zhǔn)時間源的對時操作。

（2）將Datanode中對應(yīng)block_id的數(shù)據(jù)塊以只讀方式導(dǎo)入至取證環(huán)境中。若無此block，則應(yīng)進(jìn)行HDFS數(shù)據(jù)恢復(fù)，并使用二進(jìn)制編輯器查看block的頭部，確定block使用的數(shù)據(jù)存儲格式以及壓縮方式。

4.4 數(shù)據(jù)記錄查看

（1）在線索信息較為精準(zhǔn)，數(shù)據(jù)量較少的情況下，TextFile、SequenceFile可以直接通過Hadoop系統(tǒng)命令進(jìn)行明文輸出。其他3種數(shù)據(jù)存儲格式則可以使用元數(shù)據(jù)重構(gòu)數(shù)據(jù)結(jié)構(gòu)后進(jìn)行查看。若存在壓縮，則應(yīng)針對相應(yīng)的數(shù)據(jù)格式壓縮方式進(jìn)行對應(yīng)的解壓。

（2）在線索信息較模糊，數(shù)據(jù)量較多的情況下，可以通過將數(shù)據(jù)重新導(dǎo)入至集群取證環(huán)境中，通過集群的高運算能力進(jìn)行對應(yīng)數(shù)據(jù)記錄查看操作。

5 實驗驗證

5.1 實驗環(huán)境

為驗證Hive用戶操作行為還原方法，通過VMwareWorkstation搭建了以Hadoop框架為基礎(chǔ)的偽分布虛擬機作為實驗環(huán)境。主機配置為：Intel（R） Core（TM） i7-7660U CPU @ 2.50GHz 2.50Ghz；237GB硬盤驅(qū)動；操作系統(tǒng)，Windows10專業(yè)版 64-bit。虛擬機配置為：Intel（R） Core（TM） i7-7660U CPU @ 2.50GHz 2.50Ghz；20GB硬盤驅(qū)動；操作系統(tǒng)，Ubuntu17.04 64-bit；內(nèi)存：2GB。Hadoop配置：Hadoop-2.8.1；塊大?。?28MB。

5.2 實驗過程

整個實驗過程參考本文4 Hive用戶操作行為記錄還原方法章節(jié)進(jìn)行，因?qū)嶒灜h(huán)境搭建為偽分布式結(jié)構(gòu)，因此方法中的構(gòu)建拓?fù)浣Y(jié)構(gòu)及使用Remote連接Metestore并未在實驗過程中體現(xiàn)。整個用戶操作行為還原方法可參考圖5。

（1） 數(shù)據(jù)準(zhǔn)備。首先在Linux本地存放一個text數(shù)據(jù)文件“info.txt“，其次進(jìn)入shell通過命令創(chuàng)建數(shù)據(jù)庫“myhive”，創(chuàng)建存儲格式為TextFile的數(shù)據(jù)表“info”，并將info.txt的內(nèi)容導(dǎo)入數(shù)據(jù)庫中，最后將id為29的數(shù)據(jù)記錄刪除。

（2）MetaStore信息提取。首先訪問Hadoop配置文件目錄并查看配置文件“hive-log4j2.properties”的內(nèi)容，在其中找到Hive日志存放路徑進(jìn)行訪問，將日志目錄下的所有日志導(dǎo)出至取證環(huán)境中并依次用編輯器打開。通過檢索“createtableinfo”找到創(chuàng)建表info時的日志記錄內(nèi)容，可以獲取到數(shù)據(jù)表的創(chuàng)建時間，數(shù)據(jù)格式及結(jié)構(gòu)描述。在此條記錄位置向下檢索HDFS路徑信息找到info表存儲路徑為“hdfs://localhost:9000/user/hive/warehouse/myhive.db/info”。與此同時還在日志中檢索到涉及修改表info的日志記錄,通過此條記錄說明用戶在太平洋時間2019-02-21 19:05:51運行命令將info表中id為29的記錄刪除。其次查看配置文件hivesite.xml并找到標(biāo)簽＜name＞對應(yīng)內(nèi)容為“javax.jdo.option.ConnectionPassword”和“javax.jdo.option.ConnectionUserName”的＜property＞標(biāo)簽，并分別獲取兩個標(biāo)簽下對應(yīng)標(biāo)簽＜value＞的值，即登陸負(fù)責(zé)管理元數(shù)據(jù)的Mysql數(shù)據(jù)庫的登陸用戶名與密碼。并在＜name＞標(biāo)簽內(nèi)容為“javax.jdo.option.ConnectionURL”的標(biāo)簽＜property＞下提取到標(biāo)簽＜value＞值，即登陸元數(shù)據(jù)庫的地址。因此使用用戶名和密碼連接Mysql數(shù)據(jù)庫地址，并使用查詢命令將元數(shù)據(jù)表DBS、TBLS、SDS中的基于字段DB_ID、SD_ID進(jìn)行信息合并，最終獲得數(shù)據(jù)表info對應(yīng)的HDFS路徑信息與在Hive日志中獲取的內(nèi)容相同，說明內(nèi)容準(zhǔn)確無誤。

（3）Namenode信息提取。因?qū)嶒灜h(huán)境為偽分布式，Hadoop的Namenode、Datanode及Hive的Metastore都在一臺虛擬機中，故省略通過用戶名/密碼訪問及拓?fù)浣Y(jié)構(gòu)構(gòu)建等步驟。

首先訪問Namenode存放配置文件的目錄并打開hdfs-site.xml，獲取內(nèi)容如圖6所示。

可知HDFS元數(shù)據(jù)存放目錄為“/usr/local/Hadoop/hdfs/name”，訪問此目錄并將fsimage文件通過HDFS命令轉(zhuǎn)換為XML文件并使用編輯器打開，因在Metastore中獲取的HDFS路徑中包含文件名，故在fsimage.xml中檢索“＜name＞info＜/name＞”，找到HDFS目錄info對應(yīng)的相關(guān)記錄如圖7所示。

圖7 fsimage中關(guān)于數(shù)據(jù)表info的內(nèi)容

說明info文件確實存在于HDFS文件系統(tǒng)中，且修改時間轉(zhuǎn)換為太平洋時間為2019-02-21 19:05:55，在Hive日志檢索時曾檢測到刪除id為29記錄的命令運行時間為2019-02-21 19:05:51，而文件的修改時間為2019-02-21 19:05:55，經(jīng)查詢hive日志發(fā)現(xiàn)系統(tǒng)在2019-02-21 19:05:51運行刪除記錄命令并在2019-02-21 19:05:55完成命令執(zhí)行過程，且info表在之后并無數(shù)據(jù)增刪改的過程。

（4）Datanode信息提取及數(shù)據(jù)記錄查詢。要提取Datanode中的數(shù)據(jù)塊就必須獲取具體表所存儲block的id號并進(jìn)行檢索。在進(jìn)行Namenode信息提取時已在fsimage中獲取到目錄info的相關(guān)記錄，而在此條記錄位置向下順延即可找到在HDFS目錄info下面所存儲的數(shù)據(jù)表數(shù)據(jù)文件的相關(guān)記錄。據(jù)此在fsimage中info目錄的相關(guān)記錄下找到數(shù)據(jù)塊記錄，在記錄標(biāo)簽＜id＞中獲得info表的數(shù)據(jù)文件000000_0的block_id為“1073741868”，加上數(shù)據(jù)塊編號前綴即可組成在物理層對應(yīng)的數(shù)據(jù)塊名稱為“blk_1073741868”。因為每個數(shù)據(jù)表的數(shù)據(jù)文件默認(rèn)命名規(guī)則是一樣的，因此存在多表同塊名的情況，若一表多塊或需獲取多表數(shù)據(jù)塊都需通過fsiamge中的inode結(jié)構(gòu)，而通過WEBUI則簡化了這一過程。

通過瀏覽器訪問Namenode的IP地址與端口號50070組成的URL，在文件瀏覽頁面菜單可以直接獲取HDFS文件對應(yīng)的數(shù)據(jù)塊信息，其原理即通過解析HDFS元數(shù)據(jù)文件中的inode等信息直接將塊信息可視化顯示出來。圖8即數(shù)據(jù)表info對應(yīng)的數(shù)據(jù)塊信息。

圖8 WEBUI查詢數(shù)據(jù)塊id

通過Hadoop配置文件獲取到Namenode節(jié)點的Hadoop系統(tǒng)服務(wù)輸出日志的目錄并用編輯器打開。直接搜索塊名“blk_1073741868”發(fā)現(xiàn)有且僅有一條時間為“2019-02-21 19:05:53”表示塊分配（allocate）的記錄，在Namenode信息獲取過程中曾得知在時間“2019-02-21 19:05:51”至“19:05:55”期間為執(zhí)行刪除id為29的數(shù)據(jù)記錄的命令，而因為Hive一次寫入多次讀取的特性，刪除數(shù)據(jù)記錄的方式為將數(shù)據(jù)記錄全部提取并重新寫入，因此必然會導(dǎo)致數(shù)據(jù)塊的變化，而新數(shù)據(jù)塊“blk_1073741868”則分配給不包含id為29的數(shù)據(jù)記錄。因此Hadoop系統(tǒng)服務(wù)輸出日志中的內(nèi)容也正印證了從Metastore與Datanode中獲取信息的正確性。通過結(jié)合配置文件最終找到數(shù)據(jù)塊存放目錄，并將數(shù)據(jù)塊提取至實驗環(huán)境中。因為實驗中使用的數(shù)據(jù)存儲格式為TextFile，因此可以直接將數(shù)據(jù)塊使用任何文本編輯器打開即可查看其中的所有數(shù)據(jù)記錄。

6 結(jié)語

在大數(shù)據(jù)時代Hadoop框架的適用范圍不斷擴大，Hive作為Hadoop框架的數(shù)據(jù)倉庫存儲數(shù)據(jù)價值極大，為適應(yīng)國內(nèi)外對于在Hive取證尤其是用戶操作行為還原方面的需求，本文以Hive為研究核心，將Hive分為用戶層、文件層與物理層，通過分析各種日志及HDFS元數(shù)據(jù)提出了針對Hive用戶操作行為的還原方法，同時在方法設(shè)計中考慮到證據(jù)鏈的完整性，通過多種方法互相印證的方式提高證明效力，并通過實驗證明方法的可行性。本文將繼續(xù)完善用戶操作行為還原方法，針對多種數(shù)據(jù)存儲格式的數(shù)據(jù)記錄提取展開研究，使用戶操作行為還原方法更好的貼近實戰(zhàn)。