茍子安，張 曉，2*，吳東南，王艷秋

（1.西北工業(yè)大學計算機學院，西安 710129；2.工信部大數(shù)據(jù)存儲與管理重點實驗室（西北工業(yè)大學），西安 710129）

0 引言

隨著企業(yè)數(shù)據(jù)量的快速增長，大規(guī)模的數(shù)據(jù)處理成為一個具有挑戰(zhàn)性的問題，尤其是大數(shù)據(jù)的高性能存取，直接影響著對上層的服務質(zhì)量。Hadoop 分布式文件系統(tǒng)（Hadoop Distributed File System，HDFS）［1］是Hadoop 項目的核心子項目，是分布式計算中數(shù)據(jù)存儲管理的基礎(chǔ)。它具有高容錯性、高可靠性、高可擴展性、高吞吐率等特點，為超大數(shù)據(jù)集的應用處理和存儲帶來了許多優(yōu)勢。分析Hadoop 集群上工作負載的特性是提高分布式文件系統(tǒng)性能的關(guān)鍵。針對不同類型應用的訪問特征，分布式存儲系統(tǒng)可選擇不同的緩存策略或數(shù)據(jù)布局方式來進行性能優(yōu)化［2］。

然而，Hadoop 集群上的工作負載分析，特別是在大型的生產(chǎn)環(huán)境中，主要局限于集群的負載特征采集［3］。本文提出了一種離線的負載特征采集和分析方法，通過對HDFS 中各個節(jié)點日志的關(guān)鍵信息進行提取和處理，來描述運行在其上的多客戶端和多個應用的負載特征。由于MapReduce將任務分布在不同節(jié)點運行，任務和數(shù)據(jù)的分布，以及規(guī)模和調(diào)度的變化都會影響工作負載的特征［4］，因此基于靜態(tài)分析獲取工作負載特征的方法是不準確的，并且在混合多種應用的集群中靜態(tài)分析的方法存在更多的問題［5］。從節(jié)點日志收集到的動態(tài)數(shù)據(jù)足以準確描述工作負載，并提供應用程序輸入/輸出（Input/Output，I/O）工作負載的估計和預測。通過日志分析獲取負載特征具有3 個優(yōu)勢：1）低開銷，采用離線分析方式，不會占用HDFS 的I/O 帶寬等資源，因此不會影響到上層應用的性能，數(shù)據(jù)采集和分析的成本較低；2）高時效，HDFS 的I/O等信息會同步的反映到日志上，因此對日志的實時分析具有一定的時效性；3）易于分析，基于日志的方法對負載分析提供了一定的便捷，例如對于匯聚起來的HDFS 集群訪問信息，在日志中可以很容易地根據(jù)網(wǎng)際互連協(xié)議（Internet Protocol，IP）地址來對客戶端進行區(qū)分等。

本文的主要貢獻如下：

1）建立了一個分布式日志數(shù)據(jù)提取框架，通過在元數(shù)據(jù)節(jié)點和數(shù)據(jù)節(jié)點實時的日志處理，來提取I/O操作相關(guān)的關(guān)鍵信息。

2）建立了一個通用的模型對提取出的I/O 信息進行分析，以描述負載統(tǒng)計和時序特征，并通過與現(xiàn)有的benchmark對比驗證了模型方法的可行性與準確性。

3）說明了利用負載統(tǒng)計和時序特征進行負載均衡、智能預取等HDFS優(yōu)化的可行性。

此外，本文提出的日志分析與負載特征提取方法還可用于任務調(diào)度、緩存管理、數(shù)據(jù)分布的優(yōu)化，也可以用于HDFS集群性能實時監(jiān)控、定位熱點數(shù)據(jù)與節(jié)點等［6］。

1 背景

1.1 HDFS架構(gòu)

HDFS 是一種主/從架構(gòu)，如圖1 所示，一個HDFS 集群由一個元數(shù)據(jù)服務器（NameNode，NN）和多個數(shù)據(jù)服務器（DataNode，DN）組成。其中，NameNode 執(zhí)行例如打開、關(guān)閉、重命名等文件系統(tǒng)命名空間的相關(guān)操作、控制客戶端對文件的訪問和維護數(shù)據(jù)塊到DataNode 的映射關(guān)系等。此外，集群中的每一個數(shù)據(jù)服務器通常是一個DataNode，負責為文件系統(tǒng)客戶端的讀取和寫入請求提供服務，同時處理NameNode發(fā)來的數(shù)據(jù)塊創(chuàng)建、刪除和復制等指令。

HDFS 為了保證可靠性，需要對數(shù)據(jù)進行冗余備份，通常是三副本策略，即存儲一個文件塊的同時還存儲兩個冗余塊?？蛻舳嗽谧x取文件時，首先會聯(lián)系NameNode 獲取文件的元數(shù)據(jù)，包括文件塊信息以及每個塊的存儲信息等，隨后客戶端會在三副本所在DataNode 中選擇一個物理拓撲上最近的節(jié)點，與其建立傳輸控制協(xié)議（Transmission Control Protocol，TCP）連接并進行讀取。而對于文件的寫入，客戶端首先需要聯(lián)系NameNode，為待寫入的文件塊在命名空間中創(chuàng)建元數(shù)據(jù)信息，隨后，NameNode 向客戶端返回的元數(shù)據(jù)中包含應持久化存儲這個文件塊的三個DataNode 的相關(guān)信息，客戶端與之建立相應的pipeline，并將文件塊寫到管道流中的第一個DataNode 上，具體在寫入時傳輸?shù)膯挝皇莗acket，第一個DataNode 收到packet 后會傳給管道流中后續(xù)DataNode，并等待確認字符（ACKnowledge character，ACK），以此類推，當客戶端接收到最后一個packet 的ACK 后，標志著這個塊的寫入完成，并開始下一個塊的傳輸。

圖1 HDFS架構(gòu)Fig.1 HDFS architecture

1.2 Hadoop log

Hadoop的日志有很多種，主要分為Hadoop系統(tǒng)服務輸出日志和MapReduce 程序輸出日志兩大類，Hadoop 系統(tǒng)服務輸出日志是指諸如NameNode、DataNode、ResourceManager 等系統(tǒng)自帶的服務輸出的日志，MapReduce 程序輸出日志則包括作業(yè)運行日志和任務運行日志［7］。

在Hadoop 系統(tǒng)服務輸出日志中，文件系統(tǒng)元數(shù)據(jù)日志位于NameNode 節(jié)點，客戶端對分布式文件系統(tǒng)命名空間的所有修改均可以在該日志中查看到，例如，在寫入一個文件時需要在命名空間中創(chuàng)建對應的元數(shù)據(jù)信息，因此日志中可以查看到寫入該文件的客戶端IP，文件所有塊的標識（Identity Document，ID）、大小以及分布等。此外，客戶端對文件的讀寫操作也可以在元數(shù)據(jù)日志中查看到，例如，客戶端讀取文件時通過open 操作來獲取元數(shù)據(jù)，日志中則可以看到open 操作對應的客戶端IP。文件系統(tǒng)數(shù)據(jù)日志位于各個DataNode 節(jié)點上，該DataNode 上所有數(shù)據(jù)塊的I/O 信息均可以從日志中查看到，例如數(shù)據(jù)塊的詳細讀寫信息，包括塊操作的源和目的IP 地址、被操作的塊ID 和大小以及操作的持續(xù)時間等。分布式文件系統(tǒng)客戶端將日志輸出在其被調(diào)度到的Hadoop 節(jié)點上，日志中主要包含客戶端的相關(guān)配置等基礎(chǔ)運行信息，以及一些讀寫時的詳細信息等，例如讀取時聯(lián)系NameNode 獲取的文件塊分布等元數(shù)據(jù)信息。由此可見，分布式文件系統(tǒng)客戶端對整個Hadoop 集群的操作基本可以反映在Hadoop 系統(tǒng)服務輸出日志中，因此從分布式節(jié)點日志中收集的數(shù)據(jù)足以表征客戶端和集群的工作負載特征，并提供應用程序I/O工作負載的估計和預測。

此外，Hadoop 日志庫將日志分為5 個級別，分別為DEBUG、INFO、WARN、ERROR 和FATAL。這5 個級別對應的日志信息重要程度依次從低到高，Hadoop 只輸出級別不低于設(shè)定級別的日志信息。即級別設(shè)定為DEBUG 時，這5 個級別的日志信息都會被輸出。

2 相關(guān)工作

已有研究證明，深入了解I/O工作負載特征對于分布式系統(tǒng)的資源調(diào)度與性能調(diào)優(yōu)至關(guān)重要［8-10］，文獻［11-13］從后端磁盤陣列（Redundant Arrays of Independent Disks，RAID）控制器或文件系統(tǒng)I/O 控制器采集數(shù)據(jù)，得到應用程序的I/O 負載特征。這種采集方式無法很好地應用到Hadoop 等分布式環(huán)境中，因為實際生產(chǎn)環(huán)境的集群規(guī)模往往很大，基于硬件存儲設(shè)備的負載特征采集開銷較大、成本較高?；谠L問trace 的分析方法成本較低，并且證明是有效的，文獻［14］分析了清華大學校園云存儲系統(tǒng)Corsair 的文件系統(tǒng)快照和5 個月的訪問trace，以研究學生團體對該云存儲系統(tǒng)使用的負載特征，包括文件大小、類型和讀寫比等。但是目前在諸如Hadoop 等分布式環(huán)境中，對其底層文件系統(tǒng)的工作負載研究還不夠深入，盡管最近的一些研究［15-18］對Hadoop 生產(chǎn)環(huán)境的trace 進行采集，并對I/O工作負載和數(shù)據(jù)分布進行了表征，但僅僅與現(xiàn)有一些服務的工作負載進行了比較，得出了啟發(fā)式的規(guī)律，或是用于合成基準測試進行性能評估，沒有考慮對系統(tǒng)進行性能優(yōu)化。文獻［19-22］使用基于trace的分析方法獲取負載特征并指導集群的優(yōu)化，但是其特征的采集要么通過對Hadoop JobTracker的trace進行處理，以獲取job的遞交時間、完成時間以及job結(jié)構(gòu)等信息，要么通過對Hadoop YARN 日志進行處理，提取有關(guān)job 和task 的統(tǒng)計信息。對特征的采集僅僅專注于應用層上，負載的描述也是關(guān)于job的信息，沒有關(guān)注上層應用對底層分布式文件系統(tǒng)的影響，在負載的描述上可能不十分地準確與全面。此外，這些研究的trace 采集時間也長至幾周到幾個月不等，對系統(tǒng)的優(yōu)化沒有即時的幫助，無法適應工作負載的變化，并且研究也是先有了trace 才分析得到負載特征，這樣得出的結(jié)論和該trace的相關(guān)性較大，系統(tǒng)的優(yōu)化十分局限。

本文旨在以低開銷的trace 分析方法，先建立負載分析模型，再對分布式系統(tǒng)日志進行處理。首先，系統(tǒng)的調(diào)優(yōu)不局限于某一具體的trace，也無需長時間的采集；其次，模型可以根據(jù)集群的負載以固定的時間間隔運行，也可以按需運行，其輸出結(jié)果可以對HDFS 做到及時的反饋，以適應工作負載的變化；最后，負載特征的描述采用文件系統(tǒng)層級的信息，與應用層相比在負載的描述上更加全面，對分布式存儲系統(tǒng)的優(yōu)化更具有意義。這些在先前的研究工作中是沒有的。

3 設(shè)計與實現(xiàn)

3.1 模型架構(gòu)簡述

模型架構(gòu)如圖2 所示，共分為兩個模塊：數(shù)據(jù)收集器和數(shù)據(jù)分析器。數(shù)據(jù)收集器從NameNode 與DataNode 的日志中根據(jù)關(guān)鍵字抽取出與讀寫相關(guān)的日志記錄，并根據(jù)這些日志記錄的數(shù)據(jù)結(jié)構(gòu)提取讀寫原始數(shù)據(jù)。數(shù)據(jù)分析器對這些讀寫原始數(shù)據(jù)進行分析與計算得到負載特征，并據(jù)此進行負載描述與HDFS 優(yōu)化。具體的，數(shù)據(jù)分析器的主要功能又分為兩部分：用于指導負載均衡的負載統(tǒng)計分析與用于指導智能預取的負載時序分析。本文提出的模型利用數(shù)據(jù)庫進行中間數(shù)據(jù)交互，對HDFS 日志提供的信息進行分析，將分析結(jié)果再反饋給HDFS進行優(yōu)化，形成了一個閉環(huán)正反饋系統(tǒng)。

圖2 模型架構(gòu)Fig.2 Model architecture

3.2 日志數(shù)據(jù)結(jié)構(gòu)

本文用于描述負載特征的原始數(shù)據(jù)均采集自Hadoop 分布式節(jié)點日志，通過設(shè)置關(guān)鍵字來對日志文本進行處理，找出包含有關(guān)讀寫信息的日志記錄，并對這些結(jié)構(gòu)化日志記錄中的數(shù)據(jù)進行提取以作后續(xù)分析，下面說明數(shù)據(jù)收集器選取的每一個關(guān)鍵字并簡單描述其對應的內(nèi)容。

cmd=open NameNode日志關(guān)鍵字、DEBUG 級別、文件打開操作時生成，記錄了有關(guān)客戶端讀取的詳細信息，包括時間戳、執(zhí)行讀操作的客戶端IP、打開文件的絕對路徑等。

NameNode.create NameNode 日志關(guān)鍵字、DEBUG 級別、文件寫入前在命名空間創(chuàng)建元數(shù)據(jù)時生成，記錄了有關(guān)客戶端寫入的詳細信息，包括時間戳、寫入文件的絕對路徑、執(zhí)行寫操作的客戶端IP等。

HDFS_READ DataNode 日志關(guān)鍵字、DEBUG 級別、塊讀取時生成，記錄客戶端讀取該塊的詳細信息，包括時間戳、讀取塊的客戶端IP、讀取字節(jié)數(shù)（通常略大于塊的數(shù)據(jù)大小）、操作持續(xù)時間等。

HDFS_WRITE DataNode 日志關(guān)鍵字、INFO 級別、塊寫入時生成，記錄pipeline中該塊寫入的詳細信息，包括時間戳、pipeline 上游節(jié)點IP、寫入字節(jié)數(shù)（通常是塊的數(shù)據(jù)大?。?、操作持續(xù)時間等。

此外，還有一些關(guān)鍵字，例如Block* allocate 日志中包含文件名與塊ID 列表，op：AddBlockOp 日志中包含客戶端IP 與其寫入塊的ID 列表，這些對負載特征的提取也有一定的用處，可以幫助從日志數(shù)據(jù)中構(gòu)建一些必要的映射關(guān)系，因此本文在數(shù)據(jù)收集器中也加入了對它們的采集。

本研究基于DEBUG 日志級別，而Hadoop 默認的日志級別為INFO，因此數(shù)據(jù)收集器的工作需要將Hadoop 日志級別修改為DEBUG，這可能會造成集群性能的下降，本文將在4.2節(jié)詳細討論其影響。需要注意的是，可以通過將DEBUG 級別的日志在源碼上改為INFO 級，來避免對性能可能造成的影響，但是本文沒有采用這種設(shè)計，原因是這樣的設(shè)計在將模型移植到其他的集群上工作時，需要對集群源碼修改并進行編譯，操作較為復雜，使模型的可移植性變差，而修改集群日志級別僅僅需要更改配置文件中的參數(shù)即可，操作方便。此外，對源碼中日志級別的修改，一定程度上會影響調(diào)試過程，違背代碼編寫的初衷，因此本文采用了修改集群日志級別這種源碼無關(guān)的設(shè)計。

3.3 原始數(shù)據(jù)采集

模型設(shè)計為離線的工作方式，可以在一天內(nèi)以固定的時間間隔運行，其間隔可以根據(jù)系統(tǒng)負載情況進行適當?shù)恼{(diào)整，也可以按需運行，分析特定應用執(zhí)行時間范圍內(nèi)的日志信息。利用3.2節(jié)描述的NameNode和DataNode日志關(guān)鍵字，并行地對集群各個節(jié)點日志目錄下的系統(tǒng)服務輸出日志進行文本分析，可以跟蹤并獲取到具體的I/O 相關(guān)信息，將這些原始數(shù)據(jù)保存于數(shù)據(jù)庫中以做后續(xù)使用，至此便完成了模型的數(shù)據(jù)收集階段。此外，Hadoop 系統(tǒng)服務日志會不斷生成，并且舊的歷史日志會以特定格式重命名并備份，因此日志量可能會較大，本文模型會記錄各個節(jié)點上次的日志處理位置，以實現(xiàn)數(shù)據(jù)的增量收集，提高處理效率。模型運行時有兩個輸入?yún)?shù)，分別是負載分析的開始和結(jié)束時間戳，后續(xù)的數(shù)據(jù)處理階段會根據(jù)這個時間戳從數(shù)據(jù)庫提取原始數(shù)據(jù)，這樣可以根據(jù)需要分析某個特定時段的負載特征。

數(shù)據(jù)收集器根據(jù)3.2 節(jié)描述的日志記錄結(jié)構(gòu)，從NameNode 日志中提取出客戶端的讀寫信息并存儲到數(shù)據(jù)庫中。這些讀寫日志記錄是客戶端混合的，后續(xù)需要按IP 來進行區(qū)分，但考慮客戶端數(shù)目較多可能需要大量的表去存儲，因此本文將不同客戶端的讀寫原始數(shù)據(jù)按時序存入數(shù)據(jù)庫的同一張表中。該表包含五個字段：操作時間戳、客戶端IP、操作名、操作文件名稱和該文件的大小。需要注意的是，NameNode日志中無法提取出有關(guān)文件大小的信息，但是為了便于后續(xù)的負載特征計算，這里設(shè)計了這個保留字段。

在DataNode端，按時序提取出該節(jié)點的塊讀寫信息并存入數(shù)據(jù)庫中，每個DataNode維護一張表來保存該信息。該表包含四個字段：操作時間戳、操作名、操作塊ID和操作數(shù)據(jù)大小。對于HDFS寫操作，操作數(shù)據(jù)大小即為該數(shù)據(jù)塊的大小，利用這一點，通過日志數(shù)據(jù)建立塊ID到塊大小的映射以及文件名到塊ID的映射來獲取文件大小，以填充上述保留字段。當然，使用HDFS的du子命令也可以獲取文件大小，但是本研究的目的是設(shè)計一個離線分析工具，在線對HDFS進行du操作，當文件數(shù)目較多時會對集群的性能造成影響。對于HDFS讀操作，操作數(shù)據(jù)大小偏大于該數(shù)據(jù)塊的實際大小，因為在塊讀取時，HDFS會為數(shù)據(jù)塊生成校驗和信息，因此這個操作數(shù)據(jù)大小僅可用來計算和讀取量有關(guān)的負載特征。最后，整個系統(tǒng)模型統(tǒng)一維護一張表，該表僅有兩個字段：Hadoop設(shè)備IP和該節(jié)點提取的最后一條日志記錄的時間戳，下次該節(jié)點直接提取該時間戳之后的日志記錄中的數(shù)據(jù)，以加速數(shù)據(jù)收集過程。

3.4 負載統(tǒng)計分析

負載統(tǒng)計分析的目的是對HDFS 集群進行負載均衡，因此，需要了解客戶端與集群的負載統(tǒng)計情況，利用這些統(tǒng)計數(shù)據(jù)去充分描述負載。在負載統(tǒng)計特征選取時，對于客戶端來說，選取的特征應盡可能反映客戶端的基本讀寫類型及其對集群讀寫負載的影響等。而對于集群，應盡可能反映整個集群的讀寫承載情況以及各個節(jié)點的負載變化等。在客戶端與集群兩方面進行負載統(tǒng)計特征選取，有助于較為準確、全面地了解集群的承載情況及其可能發(fā)生的變化。此外，在進行特征選取時，要盡可能從不同的角度去進行描述，以免冗余。具體負載統(tǒng)計特征的選取及其描述見表1。

表1 負載統(tǒng)計特征Tab.1 Workload statistical characteristics

為了獲取上述負載統(tǒng)計特征，數(shù)據(jù)分析器首先需要處理NameNode日志中提取出的客戶端文件讀寫信息，區(qū)分客戶端并獲取不同客戶端的讀寫時序流。其次，處理從DataNode 日志中提取出的塊讀寫信息，獲取文件塊在集群中的讀寫分布。最后也是最重要的，需要根據(jù)日志中提取出的原始數(shù)據(jù)建立一些必要的映射關(guān)系，例如文件名到塊ID 的映射、文件到文件大小的映射等，這些映射關(guān)系就像橋梁，連接NameNode 與DataNode 日志中分析出的信息，從而得到負載統(tǒng)計特征。通過建立映射來進行分析的優(yōu)勢是可以準確得出負載統(tǒng)計特征的數(shù)值，例如HDFS 的寫入中pipeline 上游節(jié)點接收數(shù)據(jù)后會寫往下游節(jié)點，因此下游節(jié)點的DataNode 日志中該數(shù)據(jù)塊寫入的源IP 即為上游節(jié)點的IP 地址，但是這次寫入操作并不能計算在上游節(jié)點客戶端的寫入中，而通過NameNode 日志可以分析出具體某一個客戶端寫入的所有文件名稱，通過文件名到塊ID 的映射以及每個DataNode 上的塊寫入信息，可以準確得到這個客戶端在集群上的寫入分布以及寫入總量。

數(shù)據(jù)分析器可以通過分析日志直接得到不同客戶端的文件讀寫流、文件讀寫分布、文件讀寫量以及不同DataNode 上的讀寫承載，以這些負載特征數(shù)據(jù)為基礎(chǔ)，數(shù)據(jù)分析器可以計算輸出表1 所描述的所有負載統(tǒng)計特征，例如通過客戶端的文件讀寫流可以計算出該客戶端的每秒讀寫次數(shù)（Input/Output Operations Per Second，IOPS）等。此外，數(shù)據(jù)分析器可以通過分析集群的讀寫承載來進行負載均衡，例如某個節(jié)點讀取承載過多時，說明該節(jié)點存儲的文件塊較多，可以通過HDFS 的balancer 子命令使集群數(shù)據(jù)自動遷移達到均衡，一定程度上降低該節(jié)點的讀取負擔［23］，另一方面，可以結(jié)合客戶端的負載統(tǒng)計特征，當某個客戶端在該節(jié)點讀取較多時，上層MapReduce 應用程序可以將該讀取任務適當調(diào)度到文件塊所在的其他節(jié)點上，以此來達到負載均衡。

3.5 負載時序分析

負載時序分析的目的是進行智能預取，鑒于HDFS的讀取等操作大多是在文件層級上的，因此本文選擇客戶端的文件讀取流作為負載時序特征的一部分，同時數(shù)據(jù)分析器也會更加細粒度地給出客戶端按時序、跨節(jié)點的塊讀取流，以適應更多的智能預取算法。為了得到客戶端的負載時序特征，數(shù)據(jù)分析器同樣需要用到NameNode 日志中提取出的客戶端文件讀寫信息，以從不同客戶端的讀寫時序流中獲取其文件讀取流。而按時序、跨節(jié)點的塊讀取流則可以從DataNode 的塊讀取日志中分析得到，如3.2 節(jié)中所述，“HDFS_READ”日志中詳細包含了某個客戶端從某個節(jié)點上讀取的塊ID及時間戳。

數(shù)據(jù)分析器可以通過對客戶端負載時序特征進行文件訪問模式分析得出文件預取信息，并顯式調(diào)用HDFS集中式緩存管理指令對文件塊進行緩存［24］，這是HDFS自身提供的一種顯式緩存機制，允許用戶根據(jù)存儲路徑指定HDFS中的文件或目錄并將其緩存在內(nèi)存中，NameNode通知存儲該文件數(shù)據(jù)塊的DataNode 將數(shù)據(jù)塊緩存在進程Java 虛擬機（Java Virtual Machine，JVM）的堆外內(nèi)存中，MapReduce 應用程序可以根據(jù)從NameNode查詢到的元數(shù)據(jù)獲取緩存塊的分布，隨后再次發(fā)生緩存文件的讀取時，可以將客戶端調(diào)度到緩存塊所在的節(jié)點上，通過調(diào)用HDFS 源碼中提供的零拷貝函數(shù)，直接從內(nèi)存中獲取所需數(shù)據(jù)塊，一定程度上提升客戶端的讀取效率。

此外，數(shù)據(jù)分析器也可以結(jié)合所獲取的負載統(tǒng)計與時序特征來進行智能預取，例如可以通過負載統(tǒng)計特征來對客戶端進行分類，為不同訪問模式的客戶端選取不同的緩存策略，對HDFS 分布式日志的后續(xù)跟蹤分析中，如果發(fā)現(xiàn)了客戶端訪問模式的匹配，則可以用相應的預取模型對其負載時序特征中的文件訪問流進行分析，從而得出需要主動緩存的預取文件。在本文提出的模型中，數(shù)據(jù)分析器除了文件級別的負載時序特征，還給出了更加細粒度的按時序、跨節(jié)點的塊級別負載時序特征，因此使得智能預取的策略選擇更加靈活和普適，并且緩存預取不會僅僅局限于文件層級。

4 實驗評估

4.1 實驗基礎(chǔ)環(huán)境

實驗搭建的Hadoop 集群共由6 臺服務器組成，包括1 個NameNode、4 個DataNode 和1 個沒有存儲數(shù)據(jù)的DFSClient 節(jié)點，Hadoop 版本為2.9.0。NameNode 所在的服務器的型號為Sugon S650，CPU 為AMD Opteron 6212，CPU 頻率為2.6 GHz，核心數(shù)為16 核，內(nèi)存大小為64 GB，硬盤大小為1.7 TB。DataNode 與DFSClient 的節(jié)點配置與NameNode 相比，除了內(nèi)存大小不同以外其他均相同，每個DataNode 的內(nèi)存為40 GB，DFSClient 則為48 GB。除此之外，機器的操作系統(tǒng)為Ubuntu16.04，linux內(nèi)核版本為4.4.0-124-generic。

實驗使用了兩個benchmark，分別為TestDFSIO 和HiBench。其中：TestDFSIO 是Hadoop 自帶的基準測試組件，其jar 包版本同Hadoop，也為2.9.0；HiBench 為Intel 開發(fā)的大數(shù)據(jù)基準測試套件，實驗使用的HiBench 版本為7.0。此外，本章所有的實驗，benchmark 均在DFSClient 節(jié)點上執(zhí)行，以模擬更加真實的場景。

4.2 模型可行性分析

本文模型要求Hadoop 集群日志設(shè)置為DEBUG 級別，而集群在不同日志級別下性能可能會有所不同，因為日志級別設(shè)置得越低，集群在進行讀寫時就會輸出越多的日志，因此需要在兩種不同的日志級別下對集群進行性能分析。使用TestDFSIO 進行文件的讀寫測試，因為多個小文件的讀寫會進行多次的元數(shù)據(jù)查詢、命名空間創(chuàng)建等，會輸出更多的日志，因此本實驗主要進行多個小文件的讀寫性能測試?？刂莆募笮?28 MB，讀寫文件數(shù)從4 增大到64，測試結(jié)果見圖3，從中可以看出，更改Hadoop 集群的日志級別，對MapReduce多個小文件的讀寫任務執(zhí)行時間影響不大，因此提出的模型具有一定的可行性。

圖3 不同日志級別讀寫性能對比Fig.3 Comparison of read and write performance at different log levels

4.3 模型準確性驗證

現(xiàn)使用TestDFSIO 進行準確性驗證，為了充分驗證本文模型的準確性，分別從以下兩種情況來進行文件的讀寫測試：1）控制文件大小不變，改變讀寫文件數(shù)；2）控制讀寫文件數(shù)不變，改變文件大小。先執(zhí)行寫入任務再執(zhí)行讀取任務，將這視為一組測試，每組測試結(jié)束后運行模型進行日志分析，模型分析讀寫量與benchmark 理論讀寫量的對比結(jié)果如圖4所示，其中：圖4（a）控制文件大小為128 MB，分別改變讀寫文件數(shù)為8、16、32和64；圖4（b）控制讀寫文件數(shù)為10，分別改變文件大小為128 MB、256 MB、512 MB和1 024 MB。

從結(jié)果可以看出，模型準確地分析出了執(zhí)行MapReduce任務后的集群讀寫量，均略大于理論值是因為TestDFSIO 在進行實際數(shù)據(jù)的寫入前，會由一個客戶端向集群io_control 目錄下寫入控制文件，在這之后其他客戶端會先從這個目錄下讀取控制文件，然后再向io_data 目錄下寫入實際的數(shù)據(jù)。對于讀取操作，也是先需要讀取控制文件，然后再進行數(shù)據(jù)文件的讀取。此外，HDFS 在讀取文件塊時，每512 B 會生成一個4 B 的校驗和，這意味著每讀一個128 MB 的塊會額外讀取1 MB 的校驗和，模型可以分析出這些額外的讀寫，充分說明了利用日志分析來進行負載特征提取的準確性。模型的執(zhí)行過程幾乎沒有時延，可以很好地適應大數(shù)據(jù)分析的實時性。因此，從實驗結(jié)果來看，具有一定的準確性與時效性。

4.4 負載特征的獲取

下面使用模型來分析HiBench微基準Sort的執(zhí)行過程，說明模型在具體應用下獲取到的負載統(tǒng)計與時序特征。微基準數(shù)據(jù)量參數(shù)設(shè)置為“huge”，實際進行排序的數(shù)據(jù)量大小約為3 132.73 MB。需要注意的是，benchmark 雖然是在DFSClient節(jié)點執(zhí)行的，但是TestDFSIO 和HiBench 均為MapReduce 應用，也就是說，集群存在多個客戶端進行并發(fā)讀寫，這些客戶端分布在集群的不同DataNode上。

圖4 不同讀寫參數(shù)下的準確性驗證結(jié)果Fig.4 Accuracy verification results at different read and write parameters

首先，對于各個客戶端的負載統(tǒng)計特征，模型分析結(jié)果如表2、3 所示，其中日志跟蹤時間為93.39 s。其次，對于HDFS集群的負載統(tǒng)計特征，跟蹤時間內(nèi)模型的分析結(jié)果如下：平均讀文件大小136.65 MB；平均寫文件大小1 174.78 MB；集群吞吐率236.39 MB/s。此外，各個DataNode 節(jié)點的讀寫承載見圖5。

圖5 集群各節(jié)點讀寫承載情況Fig.5 Read and write load status of different nodes in the cluster

表2 客戶端負載統(tǒng)計特征分析結(jié)果Tab.2 Client workload statistical characteristics analysis results

表3 客戶端讀寫分布 單位：MBTab.3 Client read and write distribution unit：MB

至于負載時序特征，分為文件層級的客戶端文件讀取流和塊層級的按時序、跨節(jié)點的客戶端塊讀取流兩部分，模型的部分分析結(jié)果如表4、5所示。

表4 客戶端（172.19.2.172）文件讀取流Tab.4 Client（172.19.2.172）file reading stream

4.5 模型的應用

在緩存算法、調(diào)度策略的研究中，或是機器學習、深度學習等模型的訓練中，往往需要trace 集來輔助研究，以作為實驗的一個手段。在缺乏理想、可用的開源trace 的情況下，需要使用嚴謹?shù)膶嶒灧椒▉碇谱鱰race集。本節(jié)描述在HDFS緩存預取研究中模型在trace 集制作上發(fā)揮的作用，以說明模型在實際工作中的應用價值，及其能為后續(xù)分析提供什么樣的數(shù)據(jù)。

表5 客戶端（172.19.2.172）塊讀取流Tab.5 Client（172.19.2.172）block reading stream

本文使用SWIM（Statistical Workload Injector for MapReduce）［25］在實驗集群上復現(xiàn)來自Facebook 生產(chǎn)系統(tǒng)的真實工作負載。該工具包含5 個trace 集，本文使用的trace 集為Facebook 上包括600 個節(jié)點的Hadoop 跟蹤歷史記錄的公開部分，完整trace 從2009 年5 月到2009 年10 月共6 個月，大約包含100萬個job。該trace集主要包含job的遞交時間、map和reduce 階段的數(shù)據(jù)量等，而HDFS 緩存預取研究需要不同節(jié)點的文件讀取時序流，因此需要將該trace 從應用層轉(zhuǎn)化為文件系統(tǒng)層，以提供研究所需要的數(shù)據(jù)。

本文首先使用SWIM工具以較低的開銷在實驗Hadoop環(huán)境上重現(xiàn)上述Facebook trace，該工具依照原trace 中的時間和數(shù)據(jù)大小不斷向Hadoop 遞交job。根據(jù)需要，本實驗將job 執(zhí)行所需的數(shù)據(jù)平均文件大小設(shè)置為32 MB，總文件數(shù)為1 501。在腳本執(zhí)行完畢后，即獲取到了job 執(zhí)行完畢后GB 級別的Hadoop 日志，接著使用模型對這些日志進行負載時序分析，以獲取不同節(jié)點的讀取時序流，部分分析結(jié)果如表6 所示。根據(jù)統(tǒng)計結(jié)果顯示，僅前1 000 個job 運行時間約為9 h 38 min，訪問文件次數(shù)約為21 000個，足以證明文本提出的模型在復雜應用中的工作價值。

表6 執(zhí)行Facebook trace時172.19.2.172部分文件讀取流Tab.6 Some 172.19.2.172 file reading stream when executing Facebook trace

5 結(jié)語

本文面向HDFS，提出了一個基于分布式文件系統(tǒng)日志的負載特征提取模型，模型分為兩個模塊：數(shù)據(jù)收集器和數(shù)據(jù)分析器。數(shù)據(jù)收集器從NameNode 與DataNode 的日志中根據(jù)關(guān)鍵字抽取出與讀寫相關(guān)的日志記錄，并根據(jù)這些日志記錄的數(shù)據(jù)結(jié)構(gòu)提取讀寫原始數(shù)據(jù)。數(shù)據(jù)分析器對這些讀寫原始數(shù)據(jù)進行分析與計算得到負載特征，并據(jù)此進行負載描述與HDFS優(yōu)化。實驗結(jié)果表明，本文提出的模型具有一定的可行性與準確性，且可以較為詳細地給出負載統(tǒng)計與時序特征，具有低開銷、高時效、易于分析等優(yōu)點，可以用來指導合成具有相同特征的工作負載、熱點數(shù)據(jù)監(jiān)測、系統(tǒng)的緩存預取優(yōu)化等。

本文的研究重點在于探究以什么樣的關(guān)鍵字可以從分布式存儲系統(tǒng)日志中準確地跟蹤到I/O信息，并且提出一個通用的模型來對集群在不同工作負載下的特征進行描述，最后開發(fā)出實際的系統(tǒng)原型來為下一步的工作打下基礎(chǔ)。因此本文在3.4 與3.5 節(jié)提出描述負載特征的模型后只是簡單給出了利用分析結(jié)果進行HDFS 性能優(yōu)化的思路，具體優(yōu)化策略的研究將作為未來的工作。此外，在后續(xù)的研究中發(fā)現(xiàn)有利用Web 日志構(gòu)建預測模型進行Web 文檔預取的應用［26］。利用日志的更新進行模型自適應調(diào)參，也顯現(xiàn)出了在不斷變化的工作負載下保持較好的預測準確率的優(yōu)勢［27］。但是，缺乏基于分布式文件系統(tǒng)日志進行預取模型構(gòu)建的研究。本文的工作是后續(xù)拓展工作的基礎(chǔ)，基于本文提出的日志分析與負載特征提取方法，下一步研究將利用分布式文件系統(tǒng)的歷史日志來構(gòu)建基于機器學習的預取模型，并且使用后續(xù)日志的增量更新來自適應地對模型進行調(diào)參，達到對HDFS 熱點文件的預取，提升Hadoop上層應用性能的目的。

最后關(guān)于模型分析結(jié)果的可視化展示，目前原型的設(shè)計是在獲取負載特征后，對于負載統(tǒng)計特征使用Python 的可視化庫將其展示出來，包括客戶端的統(tǒng)計特征，集群的讀寫文件大小、吞吐率以及各個DataNode 的讀寫承載分布等。而關(guān)于負載時序特征，鑒于客戶端文件和塊的讀取流內(nèi)容較多，并且這部分結(jié)果將作為智能預取模型的輸入，因此本文目前將其以文本的形式進行保存。此外，現(xiàn)有的可視化原型系統(tǒng)還可通過AJAX（Asynchronous Javascript And XML）等技術(shù)實現(xiàn)基于Web的監(jiān)控系統(tǒng)，在此不再贅述。