近年來，隨著大數據系統的快速發展，各式各樣的開源基準測試集被開發出來，以評測和分析大數據系統并促進其技術改進。然而，迄今為止，還沒有就這些基準測試集進行系統調研。因此，本文對當前最前沿的開源大數據基準測試集進行全面總結，闡述其歷史、現狀并展望下一步研究方向。首先，我們從大數據系統的角度對大數據基準測試集進行了定義和分類。隨后，我們回顧了基準測試技術的三個重要方面——工作負載生成技術、輸入數據生成技術和系統評估指標。最后，論文從這三個方面對現有基準測試集進行歸類，并重點描述其中具有代表性的測試集，進而討論未來研究方向，以推動該領域工作的持續發展。

介 紹

近年來，大數據在應用領域獲得了廣泛和毋庸置疑的成功，這些領域包括互聯網服務(如搜索引擎、社交網絡和電子商務)、多媒體(如視頻、照片和音樂流)以及科學研究(如生物信息學、天文學和高能物理)等。在大數據時代，不斷增長的數據量、快速處理數據(數據速度)的需求以及數據類型、結構和來源的多樣性給我們帶來了全新的挑戰，傳統的數據管理系統已經捉襟見肘。高效數據存儲和處理的需求促使多種新的大數據系統被開發出來，這些系統通常被分為三個陣營，如圖1所示：(1)Hadoop相關系統 (涵蓋高級語言和結構化查詢語言(SQL))已成為多數大數據應用的實際解決方案;(2)數據庫管理系統(DBMSs)和NoSQL數據庫在線上事務及分析中被廣泛使用;(3)在大數據領域，人們對于圖數據、流數據和復雜科學數據的特殊處理需要產生了對專用系統的需求。

圖1. 大數據系統分類與總述

在此背景下，對大數據系統進行基準測試已經成為許多領域研究開發工作的最重要驅動力之一，這些領域包括數據管理系統、硬件架構、操作系統和編程系統。首先，它有助于評估現有大數據系統的進展，從而推動其工程開發并且指導其性能提高。其次，它有助于評估新興大數據應用的需求，從而促進大數據技術的進步。盡管大數據系統的基準評測已經吸引了學術界和產業界人士的廣泛關注，但是到目前為止還沒有對當今最先進的大數據基準測試集展開的全面評估。因此，基于作者自身積累的經驗(創建BigDataBench項目以及召開多屆大數據基準、性能優化和新興硬件的國際研討會(BPOE))，本文試圖盡填補這一空白。該調查總結歸納了當前流行的開源基準測試集。圖2顯示了這些基準測試集的詞云圖，其中詞的大小和流行度成比例。

圖2. 開源大數據基準的標簽云

表1. 最新開源大數據基準測試集總覽表

為了面向大數據社區中的廣泛受眾，本文首先提供了大數據基準測試集的概述和分類，如表1所示。第2章將詳細介紹理解大數據系統和基準測試的必要概念。在接下來的章節中，我們將就三個重要方面(工作負載生成技術、輸入數據生成技術和系統度量指標)對現有大數據基準測試集進行回顧。同時，我們將分別根據基準測試集在這三個方面的不同分為不同的類別，并描述每一類別中具有代表性的基準測試集。

首先，對于一個基準測試研究來說，工作負載中的操作實現了大多數應用的數據處理邏輯。因此相關的、可移植的和可伸縮的工作負載的生成，決定了基準測試集的代表性和可用性。鑒于此，第3章將從兩個互補的方面來回顧現有基準測試集的工作負載生成技術：工作負載實現技術和運行時負載執行模式。

其次，數據量大、產生速度快和數據種類多是大數據最重要的特性，因而產生具有3V特性的工作負載輸入數據的同時保證數據的真實性和可靠性是大數據基準測試集成功的先決條件。第4章通過把現有的輸入數據生成技術分為四類：現有數據集、基于指定分布的數據集生成器、基于真實數據的數據集生成器以及混合數據集生成器。

最后，第5章總結了評估系統性能、價格和能耗的指標，并介紹了未來大數據基準測試中應該考慮的性能參數。

我們注意到，除了以上三個方面之外，關于大數據系統的基準測試還有其他重要的方面，包括大數據基準測試集的設計和實現方法;如何對基準測試集進行更新和擴展以及它們如何用于對大數據系統和應用的性能分析。所有這些方面都超出了本文的范圍，我們推薦了一些最近的參考書目以便讀者進一步閱讀：面向Hadoop的基準測試集、數據庫基準測試集和專用圖處理系統的基準測試集;還有一些主流的基準測試集，如Yahoo! Cloud Serving Benchmark(YCSB)、BigBench、HiBench、CloudSuite 和BigDataBench 。

大數據基準測試集概述

在本節中，我們首先在2.1節中介紹大數據基準測試集的類別。然后，我們將在2.2節、2.3節和2.4節中分別介紹Hadoop 相關系統、數據庫和專用系統的基準測試集的發展。

2.1大數據基準測試集分類

現有基準測試集通常可以根據基準測試范圍分為三類：

微基準測試集。這類基準測試集被用于評估單個系統組件或特定系統行為(或代碼的功能)。首先，系統組件既包括CPU或網絡設備之類的硬件，又包括Hadoop分布式文件系統(HDFS)之類的軟件，如NNBench和TestDFSIO用于測試HDFS中的NameNode和網絡組件的性能。其次，Hadoop中特定系統行為的例子是grep和sort。

端到端基準測試集。這類基準測試集的目的是使用典型應用場景評估整個系統，每個場景都對應一個工作負載的集合。例如，TPC-E-58提供一組線上事務處理(OLTP)查詢，以模擬交易和客戶帳戶管理等事務。

基準測試集套件是不同的微基準測試集或端到端基準測試集的組合，這些套件的目標是提供全面的基準測試解決方案。例如，HcBench和MRBS等基準測試套件提供了Hadoop相關系統的工作負載，HiBench、CloudSuite和BigDataBench則提供了多種大數據系統的工作負載。

在接下來的小節中，我們將分別介紹大數據系統的三大陣營以及為它們設計的基準測試集。圖3展示了大數據基準測試集十年來的發展，并根據所評估的系統將它們分為四組：(1)從2006年Hadoop發布開始，Hadoop相關系統的各種基準測試集被開發出來;(2) 自2009年以來，繼承自TPC的為數據庫開發的基準測試集不斷發展;(3)專用系統的基準測試是一個不成熟卻快速發展的領域，因此相關基準測試集從2013年才開始出現;(4) 大數據系統的三大陣營均可用HiBench、CloudSuite和BigDataBench進行基準測試。表1總結了這些基準測試集，并根據它們的發布日期把相同類型的按升序排列。注意，大數據基準測試是一個活躍的研究領域，許多基準測試集在最初發布之后仍在發展(特別是HiBench、CloudSuite和BigDataBench)，因此本文將重點討論它們的最新版本。

圖3. 大數據基準測試集發布時間軸

2.2 Hadoop相關系統

2.2.1 系統

Hadoop的HDFS和MapReduce。受Google文件系統(GFS)和Google MapReduce的啟發，開源社區開發了Hadoop HDFS和MapReduce。隨著以Hadoop為中心的系統在工業界取得了巨大的成功，各種各樣在Hadoop上開發的系統出現了，我們將討論其中兩類主要的系統——高級語言和SQL。注意，盡管還有其他的大數據系統作為Hadoop的替代品，比如Apache Flink，但這一小節將重點討論Hadoop相關系統。這是因為很多為Hadoop開發的基準測試集也可以用于測試那些替代品。

Hadoop的高級語言。此類系統開發有兩個目標。第一個目標是簡化Hadoop MapReduce作業的開發并自動優化它們的執行，從而使開發人員能夠專注于編程邏輯。例如，來自yahoo!的Pig提供一種稱為Pig Latin的文本語言，用于描述諸如連接、排序、過濾和用戶自定義操作等數據操作符。通過使用Pig Latin，復雜的任務可以轉換為一個或多個可在Apache Pig上執行的MapReduce任務。Apache Tez 和Twill的開發都有類似目的。

第二個目標是為了滿足不斷增長的實時數據提取的需求。傳統上，Hadoop MapReduce提供的批處理通常需要幾分鐘或幾個小時才能完成。因此，在Hadoop中添加高級語言的目的是支持實時數據處理。例如，加州大學伯克利分校的AMPLab建議Spark。

通過內存計算來加速Hadoop的數據處理。Spark為不同的應用提供了一個簡單易用的編程接口，同時使用RDD來為內存中的計算范式提供高效的容錯處理。

Hadoop的SQL。為了解決實時查詢數據的問題，此類系統將SQL接口添加到Hadoop中。比如，受Google BigTable的啟發，Apache HBase 5是在HDFS上建立的基于列的分布式數據庫。在HBase中，表被用作Hadoop MapReduce作業的輸入和輸出。類似地，Hive是由Facebook開發的一個流行的數據倉庫，它提供了一種名為HiveQL的類似SQL的語言，用于支持Hadoop上的交互式SQL查詢。這一類別的其他系統包括Apache Tajo(一個關系數據倉庫)、Apache Tajo(一個并行的數據庫)和Spark SQL(支持關系處理的Spark的一個組件，Shark是它的之前的版本)。

2.2.2 基準測試集

在Hadoop的發布中，有幾個內置的微基準測試集(即 WordCount、Grep 、Sort和TeraSort)，它們是目前最常用的MapReduce基準測試集。通過引入性價比和能源消耗指標，TPCx-HS對TeraSort進行了擴展。Hadoop發行版的更高版本進一步提供了幾個基準測試集來測試其組件，包括HDFS(基準測試集是TestDFSIO、DFSCIOTest和NNBench)和進程間通信(基準測試集是ThreadedMapBench)。HiBD (High-performance BigData)也測試了Hadoop網絡組件的性能。此外，HiBench和PUMA是兩組微基準測試集，它們應用在不同計算需求和不同數據傳輸量的領域。

GridMixMap和SWIM(Statistical Workload Injector for MapReduce)是兩種流行的端到端基準測試集，它使用混合的合成工作負載來評估Hadoop集群。MRBench將TPC-H查詢轉換為MapReduce作業。PigMix是用來測試Pig的數據處理性能和可伸縮性的。

許多基準測試套件支持多個大數據系統。HcBench和MRBS是用來評估Hadoop的MapReduce和Hive的。CloudSuite提供了流行的、可擴展的工作負載，以評估在云架構中部署的Hadoop MapReduce和NoSQL數據庫。BigDataBench全面覆蓋了Hadoop相關系統(包括Spark、Hive、Spark和Impala在內)的工作負載。

2.3 數據庫

2.3.1 系統

數據庫管理系統。幾十年來，并行的DBMSs被用作管理大規模數據的主要解決方案。除了傳統的關系型DBMSs(如MySQL 36和Oracle 41)，在遵循原子性、一致性、隔離性、持久性屬性的基礎上(ACID)，最近人們還提出了處理大數據的新型數據庫。這些數據庫(如Megastore、Mesa和Spanner)旨在提供數據庫的高可伸縮性，同時為用戶提供方便的基于SQL的查詢語言。此外，NewSQL數據庫(例如HStore)是另一種為高吞吐量的在線OLTP而設計的關系型數據庫，但它仍然保持ACID屬性。

NoSQL數據庫。然而，許多大數據應用并不需要嚴格的ACID約束，比起一致性和可靠性，它們更注重低延遲、高吞吐量這樣的性能。在遵循了基本的可用性、軟狀態、最終基本的一致性后，種類繁多的NoSQL數據存儲遵守如下要求：基本可用性、軟狀態(軟狀態是指允許系統存在中間狀態，而該中間狀態不會影響系統整體可用性)、最終一致性。對于大數據的處理，三種常用的NoSQL數據庫分別為Key/Value數據庫(如Amazon Dynamo、Cassandra和Linkedin Voldemort)、基于列的數據庫(如BigTable 和Hypertable)和基于文檔的存儲(如CouchDB和MongoDB)。

2.3.2 基準測試集

在過去的幾十年里，TPC基準測試集是評估DBMSs的實際標準。在13個TPC基準測試集中，6個活躍的基準測試集是：針對線上事務處理數據庫(OLTP Database)的TPC-C和TPCE，針對決策支持系統(DSSs)的TPC-H、TPC-DS和TPC-DI，而TPCVMS則將來自上述基準測試集的工作負載混合在一起來評估虛擬化系統。這些基準測試集仍是DBMSs大數據基準測試解決方案的一般選擇。此外，最近人們還開發了一些基準測試集來比較DBMSs和MapReduce系統。CALDA提供基于Hadoop的分析工作負載，將Hadoop與基于行的DBMS(DBMS-x)和基于列的DBMS(Vertica)進行比較。AMPLab基準測試集使用CALDA的工作負載比較了幾個數據分析系統，包括Apache Tez、一個NoSQL數據庫(Amazon Redshit)以及Hadoop上的三個SQL系統(Hive, Shark, and Impala)。由TPC-DS發展而來的BigBench提供了在線服務工作負載和離線分析工作負載，可以用來比較Hadoop和Teradata DBMS。

近年來，NoSQL數據庫的涌現引發了對新基準測試集的需求。YCSB是一個流行的基準測試集，它提供了云在線服務工作負載(也就是在線事務處理操作的混合)。它可以用來比較兩個非關系數據庫(Cassandra和HBase)和一個異地分布式數據庫(PNUTS)以及一個傳統的關系數據庫(MySQL)。YCSB+擴展了YCSB以評估NoSQL數據庫的高級特性(如提取加速技術)。BG提供了用于仿真社交網絡操作的工作負載，這個基準測試集可以用來比較DBMSs(如SQL-X和CASQL)和NoSQL(如MongoDB)。

2.4 專用系統

在學術界、工業界和管理界中越來越多地使用圖數據、流數據和科學數據，這促使了許多專用系統的產生。與通用的大數據系統相比，這些專用系統的設計是為了在執行復雜查詢或分析特定數據類型時提供更好的性能。根據系統所支持的數據類型，我們介紹三個主流的專用系統。

2.4.1圖數據

系統。隨著數據和網絡科學的快速發展，越來越多的信息被連接起來形成了個大圖。在一個互聯的世界里，圖自然地模擬出復雜的數據結構，如社交網絡、蛋白質相互作用網絡和自然網絡。圖數據被廣泛應用于許多領域，如在線零售、社交應用和生物信息學。為了解決圖數據日益增長的規模和復雜性所帶來的挑戰，兩類圖系統被人們開發出來：(1) 圖數據庫，如Neo4j;(2) 分布式圖處理系統，如Google Pregel要求程序員根據頂點的操作和交互來編寫函數，Giraph和Graphx分別是Pregel在Hadoop和Spark中開源的實現，HaLoop是Hadoop中MapReduce的改進版本，它用于迭代圖的數據分析。

基準測試集。人們已經開發了許多圖基準測試集來評估圖數據庫、高性能計算(HPC)系統和超算系統(如Graph 500)。在評估大數據應用時，數據量大和圖計算的多樣性帶來了新的挑戰——我們需要新的基準測試集。LinkBench和GraphBIG是針對此類問題面向Facebook社交網絡和IBM System G的場景開發的。其他的基準測試集包括Waterloo Graph Benchmark (WGB)、Graphalytics、CloudSuite。此外，BigDataBench也提供了工作負載來比較圖數據庫、分布式圖處理系統和Hadoop相關系統。

2.4.2流數據

系統。流式數據處理的巨大的潛在價值與大數據的流處理系統的出現息息相關。在這些系統中，數據不斷地到達，并且在短時間內處理。傳統的流數據主要來自傳感器網絡和金融交易。今天，大多數流數據是由Web 2.0應用程序和物聯網(IoT)設備生成的文本和媒體數據。因此，在處理大量流數據時，需要更強大的流數據處理來提供高可用性和快速恢復能力。為了應對這一挑戰，來自開源社區的流分析系統(如Apache Storm、Spark Streaming和Samza)和來自工業界的流分析系統(如IBM的InfoSphere Streams和TIBCO)已經被提出。

基準測試。開發流基準測試集需要解決幾個挑戰性問題，其中包括生成具有語義有效性的數據、為連續的查詢結果生成正確的答案、設計一個查詢語言標準。線性負載是一種用于評估流數據管理系統的過時的流基準測試集，它只能支持數值數據。Stream Bench和HiBench提供了7個微基準測試集來評估Storm、Spark Streaming 和Samza。Streams是最新的一個用來比較IBM InfoSphere Streams和Apache Storm的基準測試集，它的工作負載是模擬在線垃圾郵件檢測和電子郵件分類。另外，CloudSuite通過一個媒體流基準測試集來測試Darwin Streaming Server。BigDataBench通過三個交互式工作負載來測試Storm。

2.4.3科學數據

系統。現代研究儀器可以產生大量的科學數據，它們的數據量和速度都呈指數級增長。例如，歐洲核子研究組織(CERN)的物理學家和工程師儲存了200千萬億字節(PB)的數據，每年產生約15千萬億字節的數據。當前和未來的科學數據基礎設施對高效捕獲、存儲、分析和整合這些海量數據集的需求不斷增長，這將刺激許多科學大數據系統的發展，例如，SciDB是一個用于管理PB級科學數據的分析數據庫。基于這樣的想法，許多科學數據集(如衛星圖像、海洋、望遠鏡和基因組數據集)在SciDB中都被表示為數組，SciDB采用多維數組數據模型來支持復雜的查詢。國家生物技術信息中心(NCBI)還提供了一個系統列表(如Basic Local Alignment Search Tool (BLAST))來存儲和處理基因組數據。MAKER和Work Queue是為促進基因組數據大規模并行處理而開發的系統。此外，R是一個普適的環境，為科學應用程序提供統計分析技術，也為一些最近的系統(如SparkR)提供了一個可以支持大數據的分布式的R的實現。

基準測試集。盡管有各種各樣的科學大數據系統，但目前還沒有可用的基準測試集。DSIMBench是為了比較R和Hadoop而開發的。GenBase提供工作負載來比較R、Hadoop、DBMSs(Postgres和System X)和SciDB。BigDataBench提供工作負載來測試Message Passing Interface (MPI)和Work Queue。

工作負載生成技術

這一節，我們在表2和表3總結了已經存在的大數據基準測試集，從兩個技術維度——工作負載實現技術(3.1節)和運行時執行模式(3.2節)——來揭示工作負載生成技術的基本特征。然后我們接著在3.3節中討論了開放性的挑戰問題。

3.1 工作負載實現技術

在大數據系統的基準測試研究中，工作負載描述了它們的典型行為。也就是說，工作負載可通過從這些行為中提取操作(函數或算法)形成。因此，根據用于形成工作負載的操作類型，我們將大數據工作負載劃分為三類:

1. I / O操作。這些操作在輸入數據或文件上執行(例如，讀、寫、移動數據或新建、刪除文件)。在現有的大數據基準測試集中(除了GridMix)，一個工作負載是由一個I/O操作來實現。

2. 算法操作。當作為一種算法實現時，一個工作負載由一個或多個對輸入數據的獨立操作組成。

3. 基本操作(EO)。這些操作要么是標準的SQL操作符，要么是具有類似語法的操作符(如Pig Latin)。與以上兩類分別實現為固定的I/O操作或算法操作的工作負載相比，第三類工作負載的實現支持工作負載中EOs的動態組合，以模擬不同的應用場景。

現在，我們將在3.1.1、3.1.2和3.1.3小節分別針對Hadoop相關系統、數據庫和專用系統的基準測試集回顧其工作負載實現技術。

表2. 大數據基準測試集的負載生成技術：單個負載

3.1.1 Hadoop相關系統

在Hadoop內置的微基準測試集中，工作負載是用算法操作實現的。具體地說，WordCount、Grep和Sort工作負載的算法分別是計算單詞頻率、計算匹配的正則表達式的數量以及排序輸入數據。這些工作負載代表了Hadoop應用中的CPU密集型行為(WordCount)和I/O密集型行為(Grep和Sort)。TeraSort是一種改進版的Sort。該算法首先對輸入數據進行采樣，并將其劃分為若干個有序段。然后，它用map/reduce任務對片段中的數據進行局部排序，并將所有的reduce任務合并在一起，以對輸入進行整體排序。因此，Terasort在map階段是CPU密集型，而在reduce階段則是I/O密集型。

大多數用于測試Hadoop組件的基準測試集都是通過I/O操作實現的。NNBench通過文件操作來評測HDFS的NameNode。TestDFSIO和DFSCIOTest都是用來測量HDFS的讀取和寫入數據的能力。ThreadedMapBench使用Sort作為MapReduce的例子來測試網絡的移動性能，在這種情況下，map任務的輸出可以有一個或多個溢出。類似地，HiBD的工作負載會將均勻地、偽隨機的、或不均勻地中間數據打亂重排。

此外，PUMA集成了Hadoop內置的微基準測試集，并為統計分析和機器學習算法開發了10個新特性：(1) Term-vector可以找到文檔中出現頻率最高的單詞;(2) Inverted-index創建了一個文字到文檔的倒排索引;(3) Selfjoin把k-field的關聯作為(k + 1)-field關聯的輸入和輸出;(4) Adjacency-list生成圖中節點的鄰接表;(5)k - means聚類;(6) Classification將輸入歸為k個預定義類中的一個;(7) Histogram-movies生成輸入數據的直方圖;(8) Histogram-ratings在 MovieLens數據集中生成一份評級的直方圖;(9) SequenceCount可以統計一個文檔中3-gram的數量;(10) Ranked Inverted Index可以根據文檔中單詞出現的頻率將其降序排列。

GridMix和SWIM是兩種流行的端到端基準測試，它們使用了I/O操作來實現合成的MapReduce工作負載。具體來說，GridMix實現了兩種工作負載：LOADJOB模擬讀、寫、打亂以及map和reduce任務;而SLEEPJOB則將這些任務掛起。SWIM使用數據打亂操作來模擬MapReduce作業中的shuffle/input和output/shuffle比率。此外，MRBench實現了MapReduce框架中的SQL操作符(如select、order和join)，并將22個TPCH查詢轉換為MapReduce作業。PigMix是由Pig發展而來，因此它的工作負載由Pig操作符組成(如連接、分組和分割)，其語法嚴格遵守SQL標準。Pigmix有12個查詢工作負載，而PigMix2又增加了5個。

最后，有兩個基準測試套件包含了各種各樣的微基準測試集和端到端基準測試集。HcBench由具有交互工作負載的基準測試集組成，它能模擬實時數據分析場景。MRBS的主要是通過在工作負載執行期間生成和注入故障負載來評估Hadoop集群的可依賴性和可靠性，這個基準測試集套件提供了五個端到端基準測試集，分別用來代表數據密集型和計算密集型場景。

3.1.2數據庫

在TPC系列的基準測試集中，工作負載是通過把標準SQL操作符和其他操作符結合在一起實現的，其中標準SQL操作符包括算術、字符、比較、邏輯、集合。這些操作符可以三種方式(即順序的、并行的和迭代組合)組合起來形成代表不同業務場景的查詢工作負載。TPC-C和TPC-E提供了5到10個事務類型的OLTP工作負載來模擬批發供應商和經紀公司的查詢。TPC-H提供了22個特設的負載來表示在DSSs(decision support system)中插入和刪除數據的操作。PC-DS進一步使用99個查詢模板來支持DSSs中數千個查詢的生成。這些查詢工作負載可以分為四類業務場景：報告、點對點、迭代查詢和數據挖掘。此外，TPC-ID能夠表示DSSs中的兩個數據集成場景的工作負載，這兩個集成場景分別是：(1)在最初創建DSS時加載數據的操作;(2)將新數據集成到現有DSS中的操作。

使用SQL操作符，BigBench定義了30個查詢工作負載來表示大數據分析中的典型行為。這些工作負載覆蓋了5個業務模型(銷售、推銷、運營、供應鏈和新業務模型)、3個數據結構(結構化、半結構化和非結構化數據)以及3種分析技術(統計分析、數據挖掘和報告)。

另外，CALDA使用5個操作符來實現三個查詢工作負載(掃描、聚合和連接)，這幾個工作負載代表了MapReduce和DMBSs中的數據分析任務。AMPLab基準測試集繼承了這些工作負載，并添加了使用PageRank算法實現的工作負載。BG通過使用讀取和更新數據庫的操作來模擬社交網絡操作。

通過對各種web應用程序進行測試，YCSB定義了云服務系統的4個基本操作。為了得到實際的操作組合，YCSB采用了四種分布(uniform、Zipfian、Latest和Multinomial)來決定執行的四個基本操作中的一個。該基準測試集提供5個核心的工作負載(即頻繁更新、頻繁讀取、只讀、讀取最新的和讀取短期的)表示5個典型的云服務應用。

3.1.3專用系統

圖數據、流數據和科學數據是當前專用大數據系統的重點。我們將討論這些系統的工作負載生成技術。

圖數據。圖由有限數量的頂點(節點)和邊以及與之相關的屬性組成。從對圖的操作來看，圖的工作負載通常有4種：圖的查詢、圖的遍歷、圖的更新和圖的分析。

LinkBench和WGB都使用SQL操作符來實現工作負載。LinkBench是為通用圖數據庫(如MySQL和HBase)設計的，它的工作負載應用場景是三種Facebook社交圖操作：圖查詢(獲取定點/邊)、圖更新(插入、更新和刪除定點/邊)和圖分析(計數和測邊距)。WGB在其工作負載中實現了三個分布式處理場景：圖查詢(查找匹配的頂點或邊、查找k跳鄰居、可到達性和最短路徑查詢、模式匹配)、圖更新(添加/刪除頂點或邊、更新圖結構)和圖分析(PageRank和聚類)。

此外，Graphalytics在其社交網絡工作負載中使用了各種算法來測試圖分析系統的瓶頸。這些工作負載包括三種：圖遍歷(廣度優先搜索(BFS))、圖更新(圖演變)和圖分析(一般統計信息、連接組件(CC)和社區檢測)。GraphBIG是為CPU和GPU平臺開發的基準測試集，它的13個工作負載覆蓋三個應用場景：圖遍歷(BFS，DFS)、圖更新(圖構建、更新和拓撲變形)和圖分析(最短路徑、k-core分解、CC、圖著色、三角形數、吉布斯推論、度中心性、中介中心性)。

流數據。Stream Bench提供了幾個微基準測試集來表示流應用場景中的典型行為。而Streams實現的工作負載可以用來表示電子郵件分類應用的七個階段。BigDataBench提供了三種工作負載：協同過濾 (CF)、Nutch網頁搜索以及熱點頭條(它對傳入流的主題進行滾動計數，并識別最熱門的k個話題)。

科學數據。當前的基準測試集提供了處理微陣列數據的工作負載。DSIMBench實現了一個聚類算法用來作一個微陣列計算的工作負載。GenBase的工作負載對應于DNA微陣列數據集的5種典型的基因組算法，這些工作負載代表了生物學和醫療領域的5種應用場景。BigDataBench基于Scalable Assembly at Notre Dame (SAND) 和BLAST實現了一系列基因組數據的工作負載。

3.1.4同時適用于三大陣營系統的基準測試套件

HiBench由Hadoop內置微基準測試集(WordCount、Sort、TeraSort)、Nutch網頁搜索(PageRank和Nutch索引)以及Mahout(貝葉斯分類和k-means聚類)組成。這些工作負載既可以在Hadoop運行，也可以在Spark上運行。該套件還提升了TestDFSIO的性能來計算HDFS聚類的吞吐量。它的最新版本集成了CALDA和Stream Bench的微基準測試集。

CloudSuite是為擴展性云應用而設計的，因此它的工作負載偏向于在線服務。具體地說，它對數據庫和專用系統的基準測試集提供了服務工作負載，同時它的基準測試集為Hadoop相關系統提供了分析工作負載。Hadoop分析工作負載是使用Mahout機器學習算法實現的。在其圖基準測試集中，TunkRank算法通過計算Twitter用戶的追隨者的數量來估計該用戶的影響力。在其流基準測試集中，工作負載處理QuickTime流和MPEG數據。

BigDataBench是一個基準測試套件，它提供的工作負載不僅涵蓋不同領域的大數據應用場景(即因特網服務、多媒體分析和生物信息學)，還包括當前最先進的大型數據軟件棧。首先，BigDataBench為與Hadoop相關的系統提供了7個微基準測試集。每個基準測試集都包括不同的工作負載，它們基于四個軟件棧(Hadoop、Spark、MPI和Flink)來實現相同的算法。此外，BigDataBench提取了9個用于數據庫的有代表性的操作，每個操作都是基于三個軟件棧(Hive、Shark和Impala)實現的工作負載。最后，BigDataBench在工作負載中實現了幾個用于圖、流和生物信息應用的算法。

3.2工作負載運行時執行模式

在本節中，我們首先介紹應用在現有基準測試集中的單個工作負載的提交策略(3.2.1節)。然后，為模擬實際的應用場景(3.2.2節)，我們將討論關于混合工作負載的基準測試技術。

3.2.1工作負載提交策略

在工作負載執行期間，提交策略決定了工作負載的輸入數據和輸入模式(即提交速率和順序)。我們將本文回顧的基準測試集的提交策略分成三類。

預先指定。在許多基準測試集中，工作負載的輸入數據、提交速率和順序都是在執行前指定的。這里可分為兩種情況。在第一種情況下，基準測試集一次執行一個工作負載。例如，在Hadoop內置的微基準測試集(如WordCount、Grep和Sort)中，工作負載執行遵循兩步預定流程：上傳輸入數據到HDFS、運行工作負載。TeraSort還有第三步來檢驗已排序的輸出數據。其他的微基準測試集(包括TPCx-HS、Stream Bench、DSIMBench、 HcBench和CloudSuite的微基準測試集)也屬于這種情況。此外，盡管一些端到端基準測試集(如PigMix, WGB, Graphalytic, GraphBIG和Streams)使用了一組相關的工作負載來模擬應用場景，但這些基準測試集仍是一個個地執行這些工作負載。在第二種情況下，許多端到端基準測試集使用固定的輸入數據、提交速率和順序來執行多個工作負載。例如，TPC系列基準測試集使用了一個標準的工作負載執行過程，它有5個步驟：系統設置、數據庫設置、數據庫加載、工作負載生成和執行以及系統度量。其他的一些數據庫基準測試集(如CALDA、AMPLab基準測試集和BigBench)也都應用了類似的工作負載執行模式。

參數控制。這類基準測試集允許用戶使用參數控制工作負載的執行。首先，在用于測試Hadoop組件的微基準測試集中，NNBench和MRBench提供了用于控制創建文件數的參數，DFSCIOTest提供了用于控制文件數量和大小的參數，ThreadedMapBench提供參數來控制輸入文件的大小、每個map的分支數量以及每個主機的map數量。此外，YCSB提供了一個客戶端參數列表，它不僅可以決定輸入數據和工作負載的大小和內容，還控制了工作負載提交率(即目標吞吐量和線程數量)。類似地，BG提供數據庫、工作負載和評級參數來控制數據內容(如行數)、工作負載提交(例如，會話數和會話間的思考時間)以及在基準測試中使用的評估指標。LinkBench保持平均輸入率不變，但允許用戶根據指數分布來配置和決定請求到達間隔。

真實日志驅動。通過使用這種提交策略，基準測試集可以根據真實世界的日志來真實地復現工作負載。SWIM復現合成的MapReduce作業，它的輸入速率、順序和輸入數據的大小都采用了Facebook記錄的的真實作業。類似地，BigDataBench的多租戶版本(名為BigDataBench-mt 115)根據Google集群日志中匿名作業的提交模式復現了實際的Hadoop和Spark作業 (WordCount、Grep和排序) ，復現的前提是實際作業和匿名作業的工作負載特征非常相似。

最后，一些基準測試集應用了混合提交策略。GridMix支持以上全部三類提交策略。在第一個策略中，作業提交過程是預先指定的，一旦完成了作業，就會提交作業。如果測試的集群負載不足或過量，則第二個策略會自動增加或降低提交率，GridMix使用了這個策略，它提供了5個參數來定義負載過量和不足的閾值。第三種策略提交的作業完全遵循真實日志中的工作時間的間隔，比如Rumen日志。MRBS提供了兩種提交策略：使用預先指定策略時，它會在提交新工作之前等待當前工作負載完成;使用參數控制策略時，它會創建多個并發客戶端，并提供參數來控制每個客戶端工作負載提交的等待時間間隔。

3.2.2工作負載混合

真正的大數據系統通常執行由多個租戶提交的并發運行的多個工作負載。在執行期間，不同類型的工作負載有不同的比例。然而，大多數現有的微基準測試集都使用單租戶工作負載提交模式。也就是說，這些基準測試集僅根據單個隊列執行工作負載，在表2中我們把這些基準測試叫做“not a mix”。另一方面，大多數端到端基準測試集和一些基準測試套件采用多租戶提交模式，因此它們可以生成一種合成的或現實的工作負載混合。

合成工作負載的混合。許多基準測試集(如PigMix、HcBench和BigBench)都預先確定了不同工作負載的比例。TPC系列基準測試集還設計了一個具有不同比例的查詢集。類似地，YCSB調用包來聯結一套相關的工作負載以模擬應用場景(比如有“大量讀”或“大量寫”工作負載的場景)。LinkBench提供了合成的圖操作工作負載混合來模擬Facebook的社交網絡場景。此外，MRBS還使用隨機分布等概率分布來決定不同工作負載的比例。

真實工作負載的混合。由于真實的日志是工作負載混合模式最可信的來源，所以GridMix和SWIM首先通過挖掘生產日志來描述MapReduce作業的真實組合，再根據日志運行I/O工作負載。根據Google的集群日志，BigDataBench也可以重現真實的Hadoop或Spark混合作業。

表3. 大數據基準測試集的負載生成技術：混合負載

3.3 開放性挑戰問題

根據工業標準(例如TPC和公司評價表現標準(SPEC))，從工作負載角度看，成功的基準測試集有三個準則：(1)相關性：負載應能體現被測系統的典型行為;(2)可移植性：負載應能在不同的軟件系統和架構上執行;(3)可伸縮性：負載數量應能增加或刪除以來測試不同規模的系統。我們注意到已有的大數據基準并不能完全符合以上三個準則。

相關性。鑒別被測系統的典型行為是實現高度相關性負載的先決條件。大數據系統的快速發展要求基準測試集不僅要緊跟當前最先進的技術和系統，還要考慮未來的變化。例如，針對流數據和科學數據的專用系統的應用范圍很廣，但現有基準測試集僅涵蓋這些應用場景的極少數情況。另一個例子是，盡管為Hadoop相關系統開發了大量基準測試集，但這些基準測試集主要是為批處理和對延遲不敏感的應用開發的，并且它們不適用新出現的Hadoop相關系統(如Cloudera Kudu，它是2015年九月發布的支持延遲敏感分析應用的系統)。

大數據系統的多樣性和快速發展使得開發具有代表性的工作負載并使之覆蓋不同的應用場景變得非常具有挑戰性。解決此問題的一個可行方案是從各種工作負載獨立于系統的行為中抽象出一般方法，從而將整個工作負載分解為許多EO(基本操作)及其組合模式。充分的抽象不僅允許使用現有的EO開發新的工作負載而很少或不改變EO本身，也為不同的系統實現留出空間。到目前為止，這種抽象方法已成功應用于兩個領域：數據庫和HPC，它們使用標準SQL運算符和13 dwarfs(即一種用來描述HPC工作負載的計算和通信模式的方法)分別作為EO。 BigDataBench還初步研究了這種方法，它使用11個SQL運算符來表示三個大數據應用場景：快速存儲、日志監控和PageRank。

在數據應用中，應用抽象方法來深入了解EO和它們的組合模式需要解決三個挑戰性問題。首先，在大多數大數據應用中(例如因特網服務和多媒體)，工作負載是在半結構化和非結構化數據上執行的，它們的操作和模式是復雜多樣的。其次，大數據領域(例如機器學習、數據庫、自然語言處理和計算機視覺)多意味著研究它們所有的應用抽象是相當耗時的。 最后，不同的大數據軟件棧(例如Hadoop，Spark，Flink，Kudu)和庫(例如Mahout，MLlib，AstroML)中的算法種類加大了抽象的難度。

可移植性。我們首先從軟件系統(即軟件棧)的角度討論這個準則。大數據系統通常允許程序員編寫一些代碼(例如Hadoop中的Map和Reduce函數)來實現他們的應用，同時將資源管理、作業調度、容錯處理和其他任務留給軟件棧。因此，與傳統軟件系統相比，大數據系統更加復雜。比如，典型的HPC系統僅有兩層：分布式調度器和分布式運行環境(例如MPI)。而 Hadoop有五層：JVM層、HDFS層、分布式調度器(如Yet Another Resource Negotiator(YARN))、分布式運行環境(Jobtrack和Tasktrack)以及Hive數據倉庫層。之前的研究表明，軟件棧對工作負載性能有顯著影響。例如，在Spark上運行的作業比在Hadoop上運行的作業快100倍。

因此，在不同的軟件系統上實現相同邏輯(算法)的工作負載十分必要，這可以實現這些系統間的相互比較。目前的一些基準測試集支持在不同大數據系統上實現可移植的工作負載：HcBench和MRBS在Hadoop和Hive上實現工作負載;CALDA和AMPLab基準測試在Hadoop上實現了并行數據庫和SQL引擎上的工作負載;HiBench在Hadoop，Spark，Storm和Samza上實現了工作負載;GenBase在R、Hadoop、DBMS和SciDB上實現了工作負載;BigDataBench在Spark、Hadoop、MPI和Flink上實現了八個工作負載;Hive，Shark和Impala實現了九個工作負載。 但是，大多數被調查的基準測試集并不支持在不同的大數據系統上運行可移植的工作負載。

考慮到現代數據中心的異構體系結構，在不同體系結構上執行工作負載是工作負載可移植性中同樣重要的一個方面。但是，現有的基準測試集只做了初步工作。GraphBIG為基于CPU和GPU的平臺提供工作負載。BigDataBench提供了另一種解決方案，它在三個微架構模擬器(Simics，MARSSx86和gem5)上實現Hadoop MapReduce工作負載，從而允許架構研究人員在不同的體系結構(如x86，ARM和SPARC)上對這些工作負載進行模擬評估。該領域需要更多的基準測試集。

伸縮性。為了評估不同規模的系統，基準測試集應該能夠調整工作負載的規模，同時保證其提交和混合的真實性。但是，現有基準測試集要么支持使用參數調整負載規模的工作負載而不考慮其真實性，要么執行和提交真實工作負載但不能動態地調整規模。此問題的一種可能解決方案是分析真實日志以得到準確的租戶信息(其中包括不同租戶的分布以及他們提交的工作負載)。使用這些分析得到的信息，基準測試集可以構建一個多租戶框架，并通過調整并發租戶數量來控制工作負載的規模，同時仍然保持這些用戶提交的工作負載分布與真實場景一致。

輸入數據生成技術

在本節中，我們首先介紹大數據的特征(4.1節)，然后回顧現有大數據基準測試集中的四類輸入數據生成技術(4.2節)。最后，我們討論一些公開的挑戰(4.3節)。表4列出了這些技術的摘要。請注意，有兩類基準測試集不在此處的討論范圍內。第一類(如GridMix、SWIM和HiBD)需要基準測試用戶提供輸入數據。第二類(如NNBench和DFSCIOTest)則不需要輸入數據。

4.1 大數據特征

最常見的大數據特征是由美國國家標準與技術研究院(NIST)和Gartner提出的3個V，即數據量(volume)，速度(velocity)和種類(variety)。

數據量。數據量是最能體現大數據規模的特征。大多數數據源的數據量通常由存儲單元數(如GigaByte(GB)，TeraByte(TB)，PB，ExaByte(EB)和Zettabyte(ZB))測量。在諸如社交圖的圖數據中，數據量是根據峰值(例如，2的20次方)的數量來測量。 據IBM稱，今天90%的數據是在過去幾年中創建的，生成的數據將在未來幾年呈指數級增長。例如，預計人類和設備每天將創建2.3萬億GB數據，預計到2020年將創建超過35個ZB數據。另一個例子是，單個人類基因組測序結果大小約為140GB，而世界人口約為70億。

速度。速度不僅反映了數據生成有多快，更重要的是反映了大數據系統處理數據有多快。高速數據源有很多。例如網站和數據庫中的日志文件、 移動設備(如手機)、 Facebook和Twitter等社交媒體、公共云中的在線游戲和大量服務應用軟件(SaaS)。 以社交媒體為例，人們每月在YouTube上觀看40億小時的視頻，分享10億條內容，每天在Facebook上創建超過500 TB的數據，每小時發送1667萬條推文。如今的大數據系統必須實時處理如此如此快速產生的數據。

表4. 大數據基準的數據生成技術總覽表

種類。種類表示數據類型、數據結構和數據源的差異和多樣性。信息技術的快速發展意味著越來越多的數字化信息產生。數字化信息不僅包括結構化數據(例如表格)，還包括各種各樣的非結構化數據(例如文本，圖像，音頻和視頻)和半結構化數據(例如圖和XML數據)。 數字信息的巨大價值極大促進了各種大數據系統的發展，以存儲不同類型的數據，并提供查詢和分析服務。

此外，IBM提出真實性是大數據的第四個特征。數據的真實性體現數據的可靠性水平。真實世界的原始數據集通常是混亂的，并且有內在的錯誤、不一致性、不完整性、模糊和污染。為了避免由不正確和不確定的數據引起的問題，必須進行數據清理和預處理以保證數據的真實性。為產生價值(例如做出正確的決策)，組織和客戶都需要確保數據在處理和分析之前是可靠的。例如，IBM估計由于缺乏數據真實性，美國消費者每年損失3.1萬億美元。

為了在不同的基準測試場景下產生有意義且可信的評估結果，數據生成器需要支持不同的數據類型(數據真實性)，并在可控生成速率(數據速度)下生成可伸縮的工作負載輸入數據(數據量)，同時保證所用數據的可靠性(數據真實性)。在此背景下，我們回顧了四類數據生成器。

4.2 大數據基準測試中的數據生成器

(1)現有數據集：許多大基準測試提供固定大小的數據集作為其工作負載的輸入。MRBS提供了從不同數據源(如MovieLens、Genomic研究中心和Wikipedia Dump)獲得的各種真實數據集。HiBench也使用維基百科轉儲和維基百科頁面到頁面的鏈接數據庫作為工作負載的輸入。除了這些數據集之外，HiBench還抓取了240萬個維基百科網頁，并將它們用作Nutch頁面索引工作負載的輸入數據。

為流數據和科學數據系統設計的基準測試通常提供真實數據集作為工作負載輸入數據。Streams的電子郵件工作負載的輸入數據是1.1 GB的Enron數據集。Stream Bench開發了一個基于Apache Kafka的消息系統來從兩個真實數據集(AOL搜索數據和CAIDA匿名Internet日志數據)生成流。DSIMBench使用來自NCBI的兩個微陣列數據集。GenBase也使用代表不同患者基因的微陣列數據。

此外，一些基準測試集提供了具有一系列可選數據規模的現有數據集。PUMA擴展了五個公開可用的數據集(Wikipedia, Self-Join, Adjacency-List, Movies, and Ranked-Inverted-Index)，并為每個數據集提供了2到4個可用的數據規模，其范圍從30 GB到300 GB。HcBench提供了9個合成數據集，其數據大小以2的n次冪為單位生成，范圍從128MB到32GB。CloudSuite還提供了真實數據集列表，并支持擴展這些數據集。

總結。使用現有的數據集可以保證數據的準確性，因為它們通常是從現實世界的數據源獲得并經過適當的清理。但是，如果沒有數據生成器，則無法控制數據量和速度。此外，通過互聯網傳輸大數據集(如下載TB或PB規模數據)非常消耗資源。

1. 基于合成分布的數據生成器：這類數據生成器根據它們采用的分布可以分為兩類。第一類生成器根據默認的均勻分布創建隨機的工作負載輸入數據。 WordCount、Grep、Sort和TestDFSIO基準使用兩個隨機數據生成器(RandomWriter、RandomTextWriter)。ThreadedMapBench、TeraSort、TPCx-HS和BG構建自己的隨機數據生成器。TPC-C和TPC-H中使用dbgen在生成的數據庫表中產生均勻分布值。YCSB提供生成器來創建具有指定數量記錄的數據集。MRBench開發了一個表解析器將TPC-H表轉換為純文本文件。

第二類生成器在數據生成中使用非均勻分布。PigMix和PigMix2使用zeta分布和均勻分布產生數據。HiBench使用統計分布來生成k均值聚類工作負載的輸入數據。WGB基于遞歸現實圖生成器實現其圖生成器，它使用冪律分布模擬圖的實際屬性。類似地，Graphalytics通過添加兩個多度分布(Zeta分布和幾何分布模型)和圖結構特征來擴展社交網絡圖生成器。此外，BigBench 和TPC-DI都采用并行數據生成框架(PDGF)來生成結構化表格數據。PDGF既提供使用種子策略創建隨機數的隨機生成器，也給出了提供基本分布函數列表(如正態分布，泊松分布和指數分布)的分布生成器。BigBench擴展了PDGF以生成半結構化數據(Web日志)和非結構化數據(文本)。

總結。合成數據生成器易于定義和實現。他們可以根據用戶的基準測試要求提供可伸縮的數據量。例如，TPC-C和TPC-H中使用的dbgen提供了8個比例參數，它可以生成大小范圍從1GB到10,000 GB的表。這些生成器還可以通過調整數據生成期間的并行程度來控制數據速度。例如，RandomWriter和RandomTextWriter是為map / reduce程序實現的。因此，它們可以通過調整map和reduce數量來控制數據速度。然而，盡管一些合成生成器(例如PigMix，HiBench和BigBench數據生成器)使用經過充分研究的分布來模擬真實世界分布，但生成的合成數據與實際數據的接近程度取決于這些分布中使用的參數。最佳參數通常無法獲得，因此無法保證生成數據的真實性。

1. 基于真實數據的數據生成器：此類數據生成器捕獲并保留實際數據的重要特征，進而生成具有類似特征的可伸縮的合成數據來維護數據的可靠性。例如，LinkBench首先從真實的Facebook社交圖譜中學習圖結構的屬性，然后根據學到的屬性通過隨機生成圖節點和邊來創建真實的基準數據。

事實上，在許多實際情況下，由于機密和花費的問題，獲取大規模真實數據集很困難。BigDataBench開發了Big Data Generation工具(BDGS)以便在真實的基礎上生成可伸縮的工作負載輸入數據集。BDGS有三個基本步驟：(1)選擇不同類型和來源的具有代表性的真實世界數據集。BigDataBench現在提供15個真實數據集;(2)構建數據模型以捕獲和保留真實數據集的重要特征。BDGS提供了三個數據生成器：文本生成器、圖生成器和表生成器，它們使用隱式Dirichlet分配(LDA)模型、kronecker圖模型和PDGF來確定真實文本的特征、圖和表格數據。例如，文本生成器可以應用LDA來描述文本中的主題和單詞分布。該生成器首先從真實文本數據集(如亞馬遜電影評論)中學習以獲得單詞字典，然后它使用該數據集訓練LDA模型的參數;(3)在合成數據的生成中可以使用參數控制數據量和速度。

總結。迄今為止，基于真實數據的生成器是有效生成具有可控數據量和速度的工作負載輸入的最佳技術，同時確保生成的數據具有與實際數據類似的特征。然而，因為它無法定量評估生成的合成數據的真實性水平，這種數據生成技術僅能定性地保證數據的真實性。

1. 混合數據生成器：一些基準測試集采用上述工作負載生成技術的混合。CALDA生成HTML文檔作為其工作負載輸入。在每個文檔中，visitDate，adRevenue和sourceIP的文件在特定范圍內隨機生成，其他文件從真實數據集中采樣，并且使用Zipfian分布生成到其他頁面的鏈接。AMPLab基準測試也使用CALDA數據生成器。此外，TPC-E和TPC-DS都使用傳統的合成均勻分布或高斯分布生成其大部分輸入數據。另一方面，它們基于真實世界的數據生成一小部分關鍵輸入數據。例如，TPC-E根據2000年美國和加拿大人口普查數據生成名稱、地址、性別數據。GraphBIG提供了四個真實的固定大小的數據集(Twitter Graph，IBM Knowledge Repo，IBM Watson Gene Graph和CA Road Network)和一個合成的圖生成器(Linked Data Benchmark Council (LDBC) Graph)生成具有社交網絡功能的可伸縮圖。

4.3 開放性挑戰問題

現有大數據基準測試面臨的一個主要問題是使用現成的數據集作為工作負載輸入可以保證數據的準確性，但數據量和速度有限。另一方面，當生成不同數據量和速度的合成數據時，很難保證生成數據的真實性水平。在考慮不同的數據類型和來源(數據種類)時，這個問題更加復雜，此處有兩個具有挑戰性的關鍵問題。

第一個問題是現有的基準測試集可以構建模型來提取某些數據類型(如表格，文本和圖數據)的真實數據集的特征，但是，他們很少關注其他數據類型，如流、圖、視頻和科學數據。此外，某些數據類型具有各種數據源，因此需要區分建模技術。例如，圖數據至少有四個來源：社交網絡、信息網絡、自然網絡和人造技術網絡。但是，現有基準測試集僅提供了社交網絡模型。我們注意到流數據和科學數據也面臨數據源多樣化和模型缺少的問題。

第二個同時也是更具挑戰性的問題是如何評估產生的合成數據的真實性水平。恰當的的評估方法不僅允許基準測試集用戶評估其測試結果的可靠性水平，而且還能管理數據生成器中已建立模型的有效性。但是，據我們了解，幾乎沒有基準測試集考慮過如何測量數據的真實性。在信息質量評估(IQA)框架中，一些理論研究量化大數據中內容的客觀性、真實性和可信度，從而提供了描述和評估數據真實性的一般方法。例如，本研究使用基于共有信息的搭配分析來評估文本數據的真正性和可信度，從而能夠分析真實文本數據與生成的合成數據之間的關系。因此，IQA框架為大數據基準測試集提供了基礎，它可以用來開發具有數據真實性定量評估機制的合成數據生成器。

評估中的指標和性能參數

在本節中，我們首先總結了現有大數據基準測試中使用的評估指標(5.1節)，如表5所示。 然后，我們討論了在對大數據系統進行基準測試時要考慮的重要性能參數(5.2節)。

5.1 評價指標

目前，性能，價格和能耗是評估計算機系統的最常用指標。我們首先在第5.1.1節中介紹幾種流行的性能指標，然后討論第5.1.1節中的價格和能耗指標。

表5. 大數據基準評價標準總覽表

5.1.1 性能指標

響應時間：該度量表示的是工作負載(如MapReduce作業或數據庫查詢)從提交到完成時刻之間的時間間隔。大多數大數據基準測試集都是計算響應時間的算術平均值。相比之下，LinkBench使用六個響應時間值：平均值，最大值，第50個，第75個，第95個和第99個百分點。其它一些基準測試則計算系統在某些約束下的響應時間。繼承自Wisconsin Benchmark的YCSB使用兩個指標測試云服務系統的擴展性能。第一個指標是機器數量增加時的查詢響應時間。第二個指標是系統運行并增加時的響應時間。從社交網絡的角度來看，BG提供了四個參數α，β，τ和δ，以將性能度量定義為響應時間等于或小于β的請求的百分比α，而這些不可預測的請求數據量小于δ分鐘期間的τ百分比。

吞吐量：在大多數情況下，該指標表示處理的查詢/作業數量的平均值或每單位時間的平均處理數據量(例如1秒或1小時)。TPC系列基準測試使用吞吐量作為OLTP系統(TPC-C和TPC-E)、DSS(TPC-H，TPC-DS和TPC-DI)和虛擬化系統(TPC-VMS)的性能指標。 在用于測試HDFS的TestDFSIO和DFSCIOTest中，吞吐量通過每個文件的I / O速率(MB /秒)的平均值和標準差計算。

可靠性：在NNbench和MRBS中，該標準分別表示成功的文件操作比率和MapReduce客戶端請求的比率。此外，Stream Bench引入了兩個懲罰度量來評估系統的可靠性：(1)吞吐量懲罰因子是故障吞吐量除以沒有故障的吞吐量。該因子小于或等于1; (2)延遲懲罰因子：故障延遲除以沒有故障的延遲。該因子大于或等于1。

可用性：在TPCx-HS，MRBS和TPC-DS中，該標準表示系統可用時間的比率。

上述四個指標是用戶可感知的可觀察到的指標。相比之下，體系結構指標是用于評估微架構級別系統的不可觀察的性能指標。因此，這些指標獨立于軟件系統，用于測試硬件架構的性能。在當前的基準測試中(例如CloudSuite，BigDataBench和GraphBIG)，有三種類型的體系結構指標：(1)執行周期劃分。 CloudSuite將工作負載執行時間從兩個維度劃分為：應用程序時間和操作系統時間，指令提交時間和停滯時間。 BigDataBench將執行指令分為五種類型：整數、浮點、分支、存儲和加載。 GraphBIG將CPU執行周期分為四個部分：前端停頓，后端停頓，休眠和不良推測(frontend stall, backend stall, retiring, and bad speculation)。(2)處理器計算強度。這些指標包括每個周期的指令數(IPC)，每秒百萬條指令數(MIPS)，每秒百萬次浮點運算數(MFLOPS)以及計算與訪存的比率。(3)內存分級結構。這些指標包括cache未命中情況，指令轉換檢測緩沖區(ITLB)和數據轉換檢測緩沖區(DTLB)在不同級別的未命中情況。這些未命中情況通常當作miss-per-Kilo-instruction(MPKI)來計算。此外，GraphBIG使用兩個發散指標來衡量GPU平臺：分支發散率(每個warp中未激活線程的平均比率)和內存發散率(重放指令的比例)。

5.1.2 價格和能耗指標

性價比指標：該指標評估被測系統(SUT)價格對系統性能的影響。例如，在TPC-C和TPC-DS中，價格/性能的指標是用每分鐘一個事務所用的美元數(tpm)(例如10美元/ 1000轉/分)表示。在LinkBench中，該指標是每美元產生的峰值吞吐量。 在TPC-Pricing中提供了一種通用方法，通過綜合考慮價格的不同來源(包括硬件(購買價格)、軟件(許可證費用)、3年維護費用以及市場上合適的折扣)來計算SUT的定價配置。使用定價配置可以定義價格/性能指標。

能耗指標：TPC在2007年提出能耗規范來計算SUT的能耗，它考慮了系統組件的功率及其環境(包括溫度，濕度和海拔高度)。TPC還提供被稱為能耗測量系統的軟件包以促進其能耗規范的實施和能耗/性能指標的定義。根據TPC基準測試標準，TPCx-HS使用TereSort作為示例工作負載來討論如何為大數據系統設計能耗指標。TPC-E提出了一種能耗/性能指標，其測量每秒一個事務消耗功率的瓦特數(tps)(例如32瓦/ 10噸)。BigDataBench還提供能耗性能指標用于計算MapReduce作業的每焦耳處理的數據量。類似地，SPEC也通過開發服務器效率評級工具(SERT)來計算單節點或多節點服務器的能耗。基于此工具，SPEC開發了一個名為SPECpower-ssj2008的基準測試，它使用一個功率分析儀，一個溫度傳感器和一個控制器系統來測量系統能耗。

5.2 大數據系統性能參數的討論

在大數據系統上運行工作負載時，有三個原因使各種參數影響大數據性能。首先，大數據系統通常具有比傳統系統(如MPI)更復雜的軟件棧和層，因此有很多配置參數。其次，許多大數據系統支持多種編程語言，如C、Java和Python。程序的屬性在不同的語言中變化很大，因此引入了更多的配置參數。最后，在分布式和共享環境(例如Amazon Web Services等公共云)中執行工作負載時，資源分配參數的設置(例如CPU和內存資源的分配以及網絡資源的預留)也會影響工作負載的性能。

到目前為止，盡管人們為改善科研和工業中大數據系統的性能做出了許多努力，但我們回顧的大多數大數據基準測試在測試時僅使用默認參數設置。然而這不能保證公平的基準測試，因為從程序代碼、輸入數據、資源屬性等方面來看，在不同系統上，工作負載性能參數的最佳組合也不同。隨著新的大數據基準測試的開發，基準測試設計師需要認識到性能參數及其影響，需要考慮如何使基準測試公平而且不會失去根據被測系統來自定參數的自由。我們簡要總結了未來基準測試中要考慮的重要性能參數(至少在作者們看來)，具體如下：

系統配置參數。大數據系統中大量軟件棧和多種編程語言的使用會帶來大量的配置參數。例如，在Hadoop中，有三類基本的配置參數用于控制MapReduce作業的執行：(1)作業中map和reduce任務的數量;(2)map和reduce任務中可用間隙的數量以及這些間隙的資源配置(即處理器的數量和存儲量);(3)數據傳輸機制，例如map任務的輸出是否在存儲之前被壓縮。上述參數的設置也可以稱為執行計劃配置。在Hadoop中，用戶需要為其工作運行指定的執行計劃參數(系統配置參數)，而在一些其他系統(如Hive和Pig或某些數據庫引擎)中則可以自動生成執行計劃配置。

除了系統配置參數之外，人們還提出了調度技術來提高MapReduce工作在Hadoop相關系統上的性能。這些技術通過考慮三個性能參數來管理并發運行作業的執行，以減少其總體完成時間：作業資源共享的公平性; map和reduce任務之間的依賴關系;作業執行中的數據位置(在輸入數據所在處運行任務)。此外，由于網絡帶寬比機器中的磁盤帶寬小得多，人們引入了一些技術來減少MapReduce作業的網絡負載和通信成本。這些技術通過耦合數據和虛擬機(VM)的位置來改善數據位置，或者關注于通過管理作業內和作業間的傳輸活動來減少shuffling流量。

資源分配參數。當數據中心中部署大數據系統時，計算和網絡資源由不同系統的工作負載共享。因此CPU和內存資源的分配以及網絡資源的保留機制都是要考慮的性能參數。

瓶頸緩解參數。如今，在許多大數據系統中(例如Hadoop和數據存儲)，作業的處理分為數百或數千個并行處理任務。因此瓶頸任務(即任務花費最長時間完成的任務)會極大地影響系統的性能。針對這樣的問題，人們提出了許多方法來減輕瓶頸任務的影響，這些方法通常根據其考慮的性能參數分為三類：(1)解決瓶頸的特定硬件/軟件來源，如動態電壓和頻率調節(DVFS)、OS內核和系統軟件; (2)提高并行度; (3)為所有任務提交冗余副本或只為掉隊任務重復提交冗余副本，然后使用其最快副本來減少其完成時間。

總結

在本文中，我們全面回顧了當前開源大數據系統基準測試集。首先，我們介紹了大數據系統和基準測試集的基本概念，之后回顧了基準測試核心技術(工作負載生成技術，輸入數據生成技術以及評測指標和性能參數)。隨后，我們分別根據三種技術對基準測試集進行了分類。最后，考慮到大數據基準測試集的不斷發展，本文還討論了亟待解決的開放性挑戰問題，以期推動大數據基準測試集向著真正可信、可用和公平的方向發展。