分布式存儲(chǔ)系統(tǒng)中的日志分析與負(fù)載特征提取

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

（1.西北工業(yè)大學(xué)計(jì)算機(jī)學(xué)院，西安 710129；2.工信部大數(shù)據(jù)存儲(chǔ)與管理重點(diǎn)實(shí)驗(yàn)室（西北工業(yè)大學(xué)），西安 710129）

0 引言

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

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

本文的主要貢獻(xiàn)如下：

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

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

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

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

1 背景

1.1 HDFS架構(gòu)

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

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

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

1.2 Hadoop log

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

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

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

2 相關(guān)工作

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.4 負(fù)載統(tǒng)計(jì)分析

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

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

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

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

3.5 負(fù)載時(shí)序分析

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

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

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

4 實(shí)驗(yàn)評(píng)估

4.1 實(shí)驗(yàn)基礎(chǔ)環(huán)境

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

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

4.2 模型可行性分析

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

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

4.3 模型準(zhǔn)確性驗(yàn)證

現(xiàn)使用TestDFSIO 進(jìn)行準(zhǔn)確性驗(yàn)證，為了充分驗(yàn)證本文模型的準(zhǔn)確性，分別從以下兩種情況來(lái)進(jìn)行文件的讀寫測(cè)試：1）控制文件大小不變，改變讀寫文件數(shù)；2）控制讀寫文件數(shù)不變，改變文件大小。先執(zhí)行寫入任務(wù)再執(zhí)行讀取任務(wù)，將這視為一組測(cè)試，每組測(cè)試結(jié)束后運(yùn)行模型進(jìn)行日志分析，模型分析讀寫量與benchmark 理論讀寫量的對(duì)比結(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ǔn)確地分析出了執(zhí)行MapReduce任務(wù)后的集群讀寫量，均略大于理論值是因?yàn)門estDFSIO 在進(jìn)行實(shí)際數(shù)據(jù)的寫入前，會(huì)由一個(gè)客戶端向集群io_control 目錄下寫入控制文件，在這之后其他客戶端會(huì)先從這個(gè)目錄下讀取控制文件，然后再向io_data 目錄下寫入實(shí)際的數(shù)據(jù)。對(duì)于讀取操作，也是先需要讀取控制文件，然后再進(jìn)行數(shù)據(jù)文件的讀取。此外，HDFS 在讀取文件塊時(shí)，每512 B 會(huì)生成一個(gè)4 B 的校驗(yàn)和，這意味著每讀一個(gè)128 MB 的塊會(huì)額外讀取1 MB 的校驗(yàn)和，模型可以分析出這些額外的讀寫，充分說(shuō)明了利用日志分析來(lái)進(jìn)行負(fù)載特征提取的準(zhǔn)確性。模型的執(zhí)行過(guò)程幾乎沒(méi)有時(shí)延，可以很好地適應(yīng)大數(shù)據(jù)分析的實(shí)時(shí)性。因此，從實(shí)驗(yàn)結(jié)果來(lái)看，具有一定的準(zhǔn)確性與時(shí)效性。

4.4 負(fù)載特征的獲取

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

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

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

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

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

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

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

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

4.5 模型的應(yīng)用

在緩存算法、調(diào)度策略的研究中，或是機(jī)器學(xué)習(xí)、深度學(xué)習(xí)等模型的訓(xùn)練中，往往需要trace 集來(lái)輔助研究，以作為實(shí)驗(yàn)的一個(gè)手段。在缺乏理想、可用的開源trace 的情況下，需要使用嚴(yán)謹(jǐn)?shù)膶?shí)驗(yàn)方法來(lái)制作trace集。本節(jié)描述在HDFS緩存預(yù)取研究中模型在trace 集制作上發(fā)揮的作用，以說(shuō)明模型在實(shí)際工作中的應(yīng)用價(jià)值，及其能為后續(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］在實(shí)驗(yàn)集群上復(fù)現(xiàn)來(lái)自Facebook 生產(chǎn)系統(tǒng)的真實(shí)工作負(fù)載。該工具包含5 個(gè)trace 集，本文使用的trace 集為Facebook 上包括600 個(gè)節(jié)點(diǎn)的Hadoop 跟蹤歷史記錄的公開部分，完整trace 從2009 年5 月到2009 年10 月共6 個(gè)月，大約包含100萬(wàn)個(gè)job。該trace集主要包含job的遞交時(shí)間、map和reduce 階段的數(shù)據(jù)量等，而HDFS 緩存預(yù)取研究需要不同節(jié)點(diǎn)的文件讀取時(shí)序流，因此需要將該trace 從應(yīng)用層轉(zhuǎn)化為文件系統(tǒng)層，以提供研究所需要的數(shù)據(jù)。

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

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

5 結(jié)語(yǔ)

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

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

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