劉世緣，李云春,，陳 晨，楊海龍

(1.北京航空航天大學計算機學院,北京 100191;2.北京航空航天大學網絡空間安全學院,北京 100191)

1 引言

大數(shù)據(jù)技術廣泛應用于搜索、社交、金融、醫(yī)療和能源等諸多領域，當前，全球數(shù)據(jù)量飛速增長，根據(jù)國際權威機構Statista的統(tǒng)計和預測，預計到2035年，全球數(shù)據(jù)產生量預計達到2 142 ZB。以往應用程序可以使用傳統(tǒng)數(shù)據(jù)庫對數(shù)據(jù)進行存儲，但使用傳統(tǒng)數(shù)據(jù)庫的存儲方式已很難滿足大數(shù)據(jù)應用的需求[1]，因此研究人員設計了一些可以解決大數(shù)據(jù)存儲問題的系統(tǒng)和解決方案。例如，Hadoop分布式文件系統(tǒng)HDFS(Hadoop Distributed File System)[2]、GlusterFS[3]和Ceph[4]等。大數(shù)據(jù)應用從這些分布式文件系統(tǒng)中讀寫數(shù)據(jù)，從而實現(xiàn)對大量數(shù)據(jù)的分析處理，這也表明分布式文件系統(tǒng)的存儲性能會直接影響大數(shù)據(jù)應用程序的性能，使得分布式文件系統(tǒng)處于十分重要的位置。通過對分布式文件系統(tǒng)進行性能評測，可以指導大數(shù)據(jù)開發(fā)人員分析及定位大數(shù)據(jù)應用性能瓶頸，提高數(shù)據(jù)利用率。因此，對分布式文件系統(tǒng)進行性能分析和評測，進而優(yōu)化分布式存儲以及大數(shù)據(jù)應用的性能，具有重要的研究和應用意義。

分布式文件系統(tǒng)通常利用多個節(jié)點來提高系統(tǒng)的吞吐量，保證系統(tǒng)的高可用，實現(xiàn)數(shù)據(jù)容錯，這增加了對分布式文件系統(tǒng)進行性能評測及分析的難度。在以往的工作中，通常使用基準測試的方式來對不同大數(shù)據(jù)框架進行性能評測[5]，或者采用插樁并分析軌跡(trace)文件的方式對分布式文件系統(tǒng)進行性能分析。這2種方法采用的分析角度不同，并沒有形成合理的評測體系來評價大數(shù)據(jù)分布式存儲系統(tǒng)。同時，以往的性能評測方法僅針對分布式文件系統(tǒng)本身進行測試分析，而大數(shù)據(jù)應用與大數(shù)據(jù)基準測試程序對分布式文件系統(tǒng)的使用模式并不相同。

針對上述背景及存在的問題，本文提出一種主動測試與被動測試相結合的大數(shù)據(jù)存儲系統(tǒng)性能評測體系結構。在主動性能評測方面，對大數(shù)據(jù)存儲系統(tǒng)主動發(fā)起性能測試，分析大數(shù)據(jù)存儲系統(tǒng)的基準性能指標，從應用層、分布式文件系統(tǒng)層和基礎IO層得出大數(shù)據(jù)存儲系統(tǒng)的基準性能。在被動性能評測方面，通過分析運行在大數(shù)據(jù)存儲系統(tǒng)之上的大數(shù)據(jù)應用，分析大數(shù)據(jù)應用程序低效的原因，并根據(jù)大數(shù)據(jù)應用程序不同的低效表現(xiàn)，從低效任務、低效算子和低效函數(shù)3個層次對運行在大數(shù)據(jù)存儲系統(tǒng)之上的大數(shù)據(jù)應用的性能瓶頸進行分析。本文依據(jù)提出的大數(shù)據(jù)存儲系統(tǒng)性能評測方法體系結構對HDFS進行了性能評測分析，從不同層次給出了分析結果。

2 相關工作

對大數(shù)據(jù)存儲系統(tǒng)進行性能分析在業(yè)界有著廣泛的研究，但國內對大數(shù)據(jù)存儲系統(tǒng)的性能分析主要停留在應用配置層面和資源監(jiān)控層面，缺少對存儲系統(tǒng)的多層次、全面的性能分析方法。文獻[6]認為Hadoop的應用程序性能主要由4個因素決定：Hadoop執(zhí)行的應用程序、應用程序的輸入、Hadoop集群的資源和Hadoop的配置參數(shù),其中,應用程序無法進行自動優(yōu)化，數(shù)據(jù)輸入也無法優(yōu)化，Hadoop的集群資源無法改變，只有Hadoop配置是可以優(yōu)化的，所以作者只考慮了Hadoop配置的影響。文獻[7]對Spark低效算子進行了研究，雖然通過插樁方式得到了Spark算子粒度的性能信息，但并未分析低效算子產生的原因。

而大多數(shù)的國外研究則是對存儲系統(tǒng)進行細粒度的分析，例如面向性能事件的插樁工具，Magpie[8]和Dapper[9]都需要對源代碼修改并進行預插樁后得到性能軌跡數(shù)據(jù)。XRay[10]是Google提出的一個函數(shù)調用軌跡分析系統(tǒng)，可以輸出循環(huán)計數(shù)、時間戳和足夠的元數(shù)據(jù)。另外，文獻[5,11]對大數(shù)據(jù)系統(tǒng)的基準測試進行了較為詳細的綜述，但均為大數(shù)據(jù)框架具體的性能指標的采集及評測。文獻[12]雖然對現(xiàn)有的基準測試工具的特點進行了對比分析，但仍未提出對大數(shù)據(jù)存儲系統(tǒng)進行性能評測的體系。

上述研究雖然對具體的性能評測方式給予了詳盡的分析，但仍缺少對大數(shù)據(jù)存儲系統(tǒng)性能評測體系的研究。為此，本文面向大數(shù)據(jù)存儲系統(tǒng)，在細粒度的性能分析基礎上，構建了一種多層次的主動與被動相結合的大數(shù)據(jù)存儲系統(tǒng)性能評測體系結構，來對大數(shù)據(jù)存儲系統(tǒng)進行多角度的測試，為基于大數(shù)據(jù)存儲系統(tǒng)的大數(shù)據(jù)應用開發(fā)人員提供全面的性能評測方案與指導。

Figure 1 A storage system evaluation architecture with active & passive performance evaluation methods for big data applications

3 大數(shù)據(jù)存儲系統(tǒng)性能評測方法體系結構

為了針對大數(shù)據(jù)存儲系統(tǒng)形成系統(tǒng)的評測方法及評測理論，本文提出了主動測試與被動測試相結合的、面向大數(shù)據(jù)應用特性的存儲系統(tǒng)性能評測體系結構，如圖 1所示。

在主動性能評測方法方面，本文可以在應用層、分布式文件系統(tǒng)層和基礎IO層對大數(shù)據(jù)存儲系統(tǒng)進行多層次的性能基準測試，為測試人員提供全面、統(tǒng)一的基準測試程序。通過多層次主動評測方法，對大數(shù)據(jù)存儲系統(tǒng)主動發(fā)起性能測試，可以了解大數(shù)據(jù)存儲系統(tǒng)的基本性能信息。本文對應用層的經典領域、搜索引擎、機器學習、圖計算、數(shù)學領域和數(shù)據(jù)查詢共6個領域，超過20個應用進行大數(shù)據(jù)存儲系統(tǒng)的性能測試。在分布式文件系統(tǒng)層，本文集成了開源測試工具，形成統(tǒng)一的程序入口和輸出報告。在基礎IO層，可以針對具體的存儲設備進行隨機寫、順序寫、隨機讀和順序讀測試。

在被動性能評測方法方面，本文關注大數(shù)據(jù)存儲系統(tǒng)的重要性能指標[12]，并將系統(tǒng)性能指標依據(jù)特征劃分為4類，即離散特征、數(shù)值特征、資源特征和時間特征。應用在存儲系統(tǒng)上運行時會產生軌跡(trace)文件，利用合適的分析方法分析軌跡文件可以定位程序的性能瓶頸。本文利用課題組前期工作ASTracer[13]中的自適應采樣模塊對分布式存儲系統(tǒng)進行動態(tài)采樣率的采樣。對采集到的軌跡文件進行數(shù)據(jù)特征的提取，并定義低效行為，對采集到的任務信息、算子信息、函數(shù)信息通過前期工作中的BigRoot[14]、SparkOT[15]和ASTracer[13]分別進行低效任務、低效算子和低效函數(shù)定位。

3.1 主動性能評測方法

為了對大數(shù)據(jù)存儲系統(tǒng)進行完整的性能評測，形成完整的性能評測方法體系結構，在本文提出的主動性能評測方法中，需要實現(xiàn)如表 1所示的多層次、多領域的性能測試。

目前業(yè)界存在多種多樣的性能評測軟件，但一些大數(shù)據(jù)基準測試程序集的測試程序分類不夠準確，缺少統(tǒng)一的配置方式，測試結果獲取困難，本文對目前廣泛使用的基準測試程序進行整合開發(fā)。在本文提出的主動性能評測方法中，需要提供多層次的測試方法選擇、測試程序配置、測試數(shù)據(jù)生成和測試結果分析方法。具體需要實現(xiàn)的方法有：

(1) 列出基準測試程序及其相關說明。可以通過程序直接獲取應用列表、應用領域對應的基準測試程序列表，以及每個測試程序的功能描述。

(2) 提供測試數(shù)據(jù)生成和任務運行的配置參數(shù)輸入功能。根據(jù)所選的測試程序，給出測試程序數(shù)據(jù)生成和任務運行的輸入配置參數(shù)的幫助。

(3) 測試數(shù)據(jù)生成。提供基準測試數(shù)據(jù)生成入口，為相應的測試功能生成所需測試數(shù)據(jù)。

(4) 測試結果分析。獲取任務原始信息并進行處理，提供任務運行過程中的信息以及測試結果。

Table 1 Evaluation layers and fields of active performance evaluation method

多層次多領域的主動性能評測可以為大數(shù)據(jù)存儲系統(tǒng)提供全面的性能指標，在應用層，應用領域的選擇能夠反映大數(shù)據(jù)系統(tǒng)基準測試程序集的應用方向，提供大數(shù)據(jù)應用在不同領域的性能表現(xiàn)，對于大數(shù)據(jù)Spark程序，可以統(tǒng)計Spark程序的運行時間，以及在當前存儲系統(tǒng)上運行時系統(tǒng)IO、CPU、內存等性能變化軌跡，存儲系統(tǒng)的讀寫速率、IOPS等性能參數(shù)。在分布式文件系統(tǒng)層，提供當前運行的大數(shù)據(jù)存儲系統(tǒng)負載能力以及吞吐量、操作延遲等性能指標。在基礎IO層，提供所用硬件設備的物理性能指標。

通過使用主動性能評測方法，可以為大數(shù)據(jù)存儲系統(tǒng)提供基準的性能測試參數(shù)，以及通用應用在大數(shù)據(jù)存儲系統(tǒng)上的性能表現(xiàn)。

3.2 被動性能評測方法

本文提出的基于被動測量的大數(shù)據(jù)存儲系統(tǒng)性能評測方法BDSProf主要包括大數(shù)據(jù)程序低效任務評測技術、大數(shù)據(jù)程序低效算子評測技術和大數(shù)據(jù)程序低效函數(shù)評測技術。

被動性能測評方法的核心思想是利用ASTracer[13]中的自適應采樣模塊對分布式存儲系統(tǒng)進行采樣率動態(tài)變化的采樣，收集大數(shù)據(jù)程序在存儲系統(tǒng)上運行時產生的trace文件，對采集到的trace文件進行數(shù)據(jù)特征提取，并定義低效行為。最終可以分別進行低效任務、低效算子和低效函數(shù)定位。

3.2.1 大數(shù)據(jù)程序低效任務評測技術

Spark將一個階段劃分為多個任務，如果某些任務慢于同一階段中的其他任務，整個應用程序的執(zhí)行會因這些任務(也稱為慢任務)而變慢。這些慢任務會顯著影響整個應用程序的執(zhí)行速度。但是，傳統(tǒng)的性能監(jiān)控工具如Ganglia[16]和Nagios[17]，雖然仍然是大型分布式計算系統(tǒng)所采用的主要性能檢測工具，然而其粗粒度的系統(tǒng)運行數(shù)據(jù)展示無法為具體應用的分析提供所需的細粒度事件信息，不能有效地挖掘慢任務背后的原因并進行有針對性的改進。

低效任務評測技術著眼于應用層面分析，采集被廣泛采用的系統(tǒng)特征，包括CPU、IO和網絡流量等資源占用特征以及數(shù)據(jù)局部性、讀寫數(shù)據(jù)量、混洗讀寫數(shù)據(jù)量、JVM(Java Virtual Machine)垃圾收集時間、任務序列化和反序列化時間等應用特征。評測過程使用Linux采樣工具收集系統(tǒng)資源占用信息，采樣工具會在Spark啟動時，自動開始采樣，記錄采樣開始時間戳，每秒鐘搜集一次系統(tǒng)資源占用信息，寫入日志，當Spark應用程序結束運行時，調度器在集群各個節(jié)點上終止采樣進程，然后聚合集群各個節(jié)點的采樣日志，通過和Spark任務執(zhí)行時間進行對比，就可以得到任務運行時的資源占用情況。應用特征則是從Spark日志文件中抽取，反映了慢任務產生的內部原因，如數(shù)據(jù)傾斜、數(shù)據(jù)局部性、JVM垃圾搜集、任務序列化和反序列化、數(shù)據(jù)本地性等。運用數(shù)學統(tǒng)計的方法，從以上特征中，找出根原因影響程序運行的規(guī)律，從而可反向推算根原因出現(xiàn)的時刻。

(1)數(shù)據(jù)特征提取。

采用Linux采樣工具收集系統(tǒng)信息，包括iostat、mpstat和sar。利用式(1)～式(3)分別計算系統(tǒng)資源占用特征[14]:

(1)

(2)

(3)

其中，user_timet是指t時間內用戶占用的 CPU 時間，total_timet是指t時間內總的CPU時間，IO_timet是指t時間內IO占用的時間，bytes_sendt是指t時間內網卡發(fā)送的數(shù)據(jù)量，bytes_receivedt是指t時間內網卡接收的數(shù)據(jù)量。

(2)根原因分析方法。

特征分為4類，包括離散特征、數(shù)值特征、資源特征和時間特征，本文針對不同的特征提出了不同的分析方法。資源特征包括CPU、IO和網絡特征，屬于數(shù)值特征的一個特例，由于需要排除應用自身造成的假陽性(FP)，所以要有特殊的約束條件。時間特征包括任務序列化和反序列時間、垃圾搜集時間，也是數(shù)值特征的一個特例，需要排除該特征雖然有波動但是相比于任務執(zhí)行時間可以忽略不計的情況。對于數(shù)值特征，當滿足式(4)中的全部條件時，則認為它是根原因特征。對于資源占用特征，使用邊緣檢測(Edge Detection)[14]的方法來過濾由任務本身導致的高資源占用率的情況。從數(shù)學的角度來講，如果任務滿足式(5)中的全部條件，那么就認為高資源占用率是由任務本身引起的。數(shù)據(jù)本地性是本文唯一考慮的離散特征。如果局部性值為2并且滿足式(6)中的條件，則將局部性作為根原因[14]。

F>global_quantileλq，

F>mean(Fpeer)λq

(4)

(5)

(6)

3.2.2 大數(shù)據(jù)程序低效算子評測技術

該技術對Standalone模式下運行的Spark大數(shù)據(jù)應用程序的性能數(shù)據(jù)進行采集，使用采集到的數(shù)據(jù)分析性能瓶頸，最終通過可視化展示的形式向Spark大數(shù)據(jù)程序開發(fā)人員提供程序運行時的各層系統(tǒng)性能軌跡、程序運行時事件、Straggler瓶頸任務的檢測分析，以及性能熱點算子的檢測分析服務。

在Spark的圖依賴關系中，如果一個彈性分布式數(shù)據(jù)集RDD(Resilient Distributed Dataset)的分區(qū)依賴于父RDD的多個分區(qū)，Spark混洗數(shù)據(jù)之前需要等待父RDD所有分區(qū)完成計算，Spark據(jù)此將應用程序劃分成多個階段。但是，如果一個RDD只依賴父RDD的一個分區(qū)，就無需等待別的分區(qū)完成計算，而本文主要分析這種情況下算子的低效行為。這種算子粒度的低效行為比應用粒度的低效任務更為復雜，低效算子不僅要考慮算子相對于其他算子執(zhí)行時間的長短，還要考慮算子自身的執(zhí)行時間和算子所在任務的執(zhí)行時間。

(1)低效算子定義及評價。

為了定位低效算子，本文為每個算子賦予一個低效算子評分，然后將低效評分較高的算子作為低效算子。本文采用算子評分OG(Operator Grade)的方法[18]來對Spark框架中的低效算子進行定位，在計算出每個算子相應的算子評分之后，從中選擇評分較高的算子作為低效算子，并進行后續(xù)的優(yōu)化處理。本文主要考慮以下幾個評分原則：

① 算子實例的執(zhí)行時間差異很大，執(zhí)行時間較長的算子實例應該分配較高的分數(shù)。

② 在關鍵流水線優(yōu)化后，其他算子流水線有可能會成為新的關鍵流水線，因此，應該為執(zhí)行時間較長的算子流水線中的算子實例分配較高的分數(shù)。

③ 算子實例的優(yōu)化潛力也應該被考慮在內，一般來說，相比于同階算子執(zhí)行時間更長的算子實例具有更多優(yōu)化潛力，應該被分配較高的分數(shù)。

為了滿足第1個原則，本文使低效評分IS(Inefficiency Score)與算子實例的執(zhí)行時間成正比。為了滿足第2個和第3個原則，本文使用流水線因子[18]PF(Pipeline Factor)為每個算子流水線分配一個合理的評分。PF使用式(7)計算:

(7)

其中，i代表第i條算子流水線，j代表第j個片段，ni代表第i條算子流水線內的片段數(shù)量，N表示關鍵算子流水線可以劃分的階段數(shù)量，Sj表示第j個片段的流水線執(zhí)行時間。

為了滿足第3個原則，本文使用SS(Straggler Scale)作為IS的一個因子。SS是當前算子實例的執(zhí)行時間除以同階算子實例執(zhí)行時間的中位數(shù)，這個因子代表算子的優(yōu)化潛力。把上述因素組合在一起后，利用式(8)可推導出IS[18]。

ISij=PFi×spanij×SSij=

(8)

其中,spanij是指第i條算子流水線中第j個片段的執(zhí)行時間，Medianj表示第j個流水線片段的平均執(zhí)行時間。

3.2.3 大數(shù)據(jù)程序低效函數(shù)評測技術

大數(shù)據(jù)程序低效函數(shù)評測技術重點分析分布式文件系統(tǒng)內部的低效行為，這些性能信息在應用層面和框架層面的性能分析中都無法獲取，但是分布式文件系統(tǒng)對所有的大數(shù)據(jù)系統(tǒng)都是至關重要的，這是大數(shù)據(jù)應用程序區(qū)別于高性能程序的一個重要特點。

分布式文件系統(tǒng)的性能和應用層面、框架層面的性能息息相關，應用層面的數(shù)據(jù)傾斜和框架層面的Hadoop函數(shù)都和分布式文件系統(tǒng)性能緊密相關。

對HDFS進行性能分析必須還原每一個IO請求的函數(shù)調用樹，否則便無法分析HDFS消耗在各個函數(shù)的延遲，也無法定位造成性能瓶頸的高延遲函數(shù)?；趩喂?jié)點的動態(tài)插樁技術無法滿足分布式文件系統(tǒng)的動態(tài)插樁需求，只能采用靜態(tài)插樁的方式對分布式文件系統(tǒng)插樁(直接修改源代碼并進行編譯)。

在獲取性能日志文件之后，首先需要利用父子關系將日志還原成多個調用樹結構，這些樹結構規(guī)模十分龐大，不便于分析，因此需要采用一種同構樹壓縮的算法進行大規(guī)模壓縮。在進行壓縮之后，還可以對壓縮節(jié)點的數(shù)據(jù)進行規(guī)約，比如只保留函數(shù)執(zhí)行時間的均值、方差、極值和分位點等統(tǒng)計信息。經過壓縮后不僅數(shù)據(jù)規(guī)模大幅下降，同時也方便抽取典型IO模式以及每種IO模式下的性能瓶頸。

實際HDFS任務運行過程中，有一些調用樹會頻繁出現(xiàn)，將其全部采樣既無必要，又消耗了大量計算和存儲資源，有時記錄trace消耗的時間會嚴重影響任務本身的運行時間，另外過大的trace文件對于后續(xù)分析也會造成極大負擔。與以往的工作不同，本文的采樣器都是以調用樹為決策的基本對象，而不是全局或單個函數(shù)調用。但是，考慮到采樣對應用性能的影響，采樣器設計不能過于復雜。本文使用根節(jié)點近似代替調用樹。

針對全局采樣率容易造成調用樹遺漏的問題，本文使用的方法是根據(jù)調用樹出現(xiàn)次數(shù)調整采樣率[19]。該方法主要考慮到不同的調用樹出現(xiàn)次數(shù)差異較大，尤其是在迭代多次的工作負載中，即使是用了較小的數(shù)據(jù)量，但由于頻繁的迭代計算，不同調用樹出現(xiàn)次數(shù)相差甚至5～6個數(shù)量級。對這類函數(shù)的采樣會造成trace文件過大，也會對任務性能造成影響。

(1)核心采樣器。

① bump采樣器。bump 采樣器使用bump函數(shù)作為采樣概率生成器，使用bump函數(shù)的原因是，這一類函數(shù)存在一個突變點，當變量超過一定值后數(shù)值會發(fā)生突變，利用該屬性，可以把函數(shù)調用的執(zhí)行次數(shù)作為變量，設定參數(shù)λ的值，可以保證函數(shù)在執(zhí)行指定次數(shù)之前有較大的概率被采樣到，但超過閾值之后，函數(shù)被采樣的概率會急劇下降，在保證了函數(shù)最低采樣的同時，也能防止一些執(zhí)行次數(shù)過多的函數(shù)被大量采樣。本文中使用的bump函數(shù)如式(9)所示:

(9)

其中,t1表示函數(shù)執(zhí)行次數(shù)，λ為超參數(shù)。

② 令牌桶采樣器。該方法的特點在于，不再使用采樣率的概念，而是用桶中是否有剩余的令牌來決定是否采樣，同時靈活性較高，可以通過設置參數(shù)滿足不同環(huán)境的采樣需求。這種方法帶來的效果是，頻繁出現(xiàn)的調用會被壓制，而罕見的調用幾乎總是被采樣到，尤其是當某一函數(shù)調用短時間內高并發(fā)式出現(xiàn)時，該采樣器可以有效壓縮采樣。

(2)采樣調優(yōu)。

本文采用了參數(shù)自動調優(yōu)機制，利用模擬退火算法對采樣器的參數(shù)設置進行自動搜索，從而獲取最優(yōu)的參數(shù)設置。模擬退火算法首先設置一個隨機的初始解x，并計算目標函數(shù)f(x)，如式(10)所示：

(10)

其中,entropy(x)表示采樣結果的信息熵，代表著trace文件包含的信息量,信息熵越大，獲取的信息越多;dist(x)表示采樣后的結果和全采樣結果的相似度，這里用歐氏距離來表示，歐氏距離越小相似度越高。本文還加入了如式(11)所示的約束：

0.1×Sp0.1≤S≤Sp0.1

(11)

其中，Sp0.1表示使用0.1概率采樣到的結果大小，S表示調參后動態(tài)采樣器采樣到的trace文件大小。即在保證較好的壓縮trace文件大小的同時又不會因為文件太小而丟失太多信息。

4 實驗及結果分析

4.1 實驗環(huán)境設置

本文實驗環(huán)境如表 2所示，使用R2220-D08服務器組成集群，通過測試終端登錄到集群進行實驗。

Table 2 Experimental environment configuration

4.2 主動評測性能評測實驗

4.2.1 應用層性能評測實驗

應用層性能評測以數(shù)學領域的Bayes應用為例。運行Bayes應用后，可以在結果文件中得到應用運行過程中的數(shù)據(jù)吞吐量情況以及不同節(jié)點吞吐量情況，如表 3所示。

Table 3 Active performance evaluation results of Bayes application at application layer

主動性能評測記錄程序運行過程中的CPU、內存、磁盤和網絡使用情況，圖 2是截取的與讀寫相關的性能指標，縱軸表示吞吐量，橫軸表示時間，可以觀察到程序運行期間讀寫隨時間變化的情況，由于程序運行過程中會提前準備數(shù)據(jù)，所以寫操作發(fā)生在前，讀操作發(fā)生在后。

Figure 2 Active performance evaluation partial results of Bayes application at application layer

4.2.2 分布式文件系統(tǒng)層性能評測實驗

分布式文件系統(tǒng)層性能評測以Dfsioe測試為例。表 4展示了使用分布式文件系統(tǒng)層Dfsioe應用對大數(shù)據(jù)存儲系統(tǒng)進行主動性能評測的結果。

Table 4 Active performance evaluation results of Dfsioe test at distributed file system layer

在分布式文件系統(tǒng)層進行主動性能評測同樣會記錄CPU、內存、磁盤和網絡使用情況，本文中僅截取與讀寫相關的性能指標進行展示，如圖 3所示，展示了讀寫速率隨時間的變化情況，以及每秒讀寫次數(shù)的變化情況。

Figure 3 Active performance evaluation partial results of Dfsioe test at distributed file system layer

4.2.3 基礎IO層性能評測實驗

基礎IO層性能評測以Iozone測試為例。在文件塊大小為128 MB的情況下，寫速率、重復寫速率、讀速率和重復讀速率如表 5所示。基礎IO層測試直接在本地完成，可以測試本地文件系統(tǒng)和本地磁盤的性能。

4.3 被動測試性能評測實驗

4.3.1 大數(shù)據(jù)低效任務評測實驗

實驗使用Bayes應用作為工作負載，從圖 4可

Table 5 Active performance evaluation results of Iozone test in the basic IO layer

Figure 4 Percentage of inefficiency causes

Figure 5 Analysis results of inefficient tasks

知Bayes的應用特征為IO和CPU占用較大，符合Bayes實際的應用特征。

圖5詳細展示了Spark運行Bayes應用程序時CPU、IO的資源利用率、慢任務及慢任務產生的根原因。

圖5中橫軸表示任務執(zhí)行時間，左側的縱軸表示資源利用率(百分比)，右邊的縱軸表示通過將慢任務的持續(xù)時間除以階段持續(xù)時間中位數(shù)計算出的慢任務因子。圖5中水平的黑色部分表示標注了慢任務的時間跨度、慢任務因子(任務執(zhí)行時間和同階段所有任務執(zhí)行時間中位數(shù)的比例)及其根原因。圖5中同時還展示了未確定根原因的慢任務。圖5上方的黑色橫線表示注入不同類型異常的開始時間和持續(xù)時間。

4.3.2 大數(shù)據(jù)低效算子評測實驗

實驗使用Nweight應用作為工作負載，圖 6顯示了Spark運行Nweight應用程序時每一個導致數(shù)據(jù)傾斜的任務事件，并得到Straggler在不同task上的分布。

Figure 6 Analysis results of Spark inefficient operator

本實驗先用IS定位低效算子，再采用聚類的方法對低效算子的JVM特征進行聚類，通過分析聚類中心的特征大小，就可以判定哪些特征和低效算子相關性較強。

本實驗將定性和定量分析不同工作負載下低效算子分布情況。由于工作負載的算子出現(xiàn)的次數(shù)較多，因此實驗只采取一些有代表性的階段進行分析并總結出典型的低效算子模式。

4.3.3 大數(shù)據(jù)程序低效函數(shù)評測實驗

本實驗選用了Hibench中的Kmeans負載來驗證ASTracer對其中異常函數(shù)的識別能力。對于函數(shù)DFSInputStream#writeChunk來說，本實驗中觀察該函數(shù)到75%分位點的執(zhí)行時間都小于0.1 ms，但是該函數(shù)的最大執(zhí)行時間達到200 ms，這表示工作負載中存在著嚴重的數(shù)據(jù)不平衡。

對于Kmeans的機器學習算法要求多輪迭代，表 6展示了Kmeans的采樣函數(shù)信息，可以看到函數(shù)調用次數(shù)越多，且不同函數(shù)的執(zhí)行時間不平衡,因此數(shù)據(jù)傾斜的問題對這樣的工作負載有著明顯的性能影響。

Table 6 Kmeans and Dfsio sampling functions

5 結束語

在數(shù)據(jù)量與日俱增的情況下，大數(shù)據(jù)的存儲處于核心位置，通過對大數(shù)據(jù)存儲系統(tǒng)性能的評測能夠指導實際開發(fā)人員分析大數(shù)據(jù)應用的性能瓶頸，為此，本文基于業(yè)界當前工作進展與課題組前期工作提出了面向大數(shù)據(jù)存儲系統(tǒng)的主動與被動測試相結合的評測理論體系，并依據(jù)本文所提出的理論體系針對主動測試與被動測試實現(xiàn)了評測工具，給出了當前進行大數(shù)據(jù)存儲系統(tǒng)性能評測的問題分析與評測原理，本文所開發(fā)的工具源碼已開源至木蘭社區(qū)[20]。實驗結果表明，本文所提出的方法與工具能夠提供全面的性能指標，并為大數(shù)據(jù)存儲系統(tǒng)提供多層次的性能評測及分析，具有較強的實用意義。