如何分析時序數據庫DolphinDB與Spark的性能對比測試報告

今天就跟大家聊聊有關如何分析時序數據庫DolphinDB與Spark的性能對比測試報告，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結了以下內容，希望大家根據這篇文章可以有所收獲。

1. 概述

Spark是基于內存計算的通用大數據并行計算框架，內置多種組件，如批處理、流處理、機器學習和圖處理。Hive是基于Hadoop的數據倉庫，支持類SQL的命令查詢，提升了Hadoop的易用性。Spark與Hive、Hadoop通常是搭配使用，利用Hive中的數據分區可以方便地管理和過濾數據，提高查詢效率。

DolphinDB是C++編寫的高性能分布式時序數據庫，內置高吞吐低延遲的列式內存引擎，集成了功能強大的編程語言，支持類Python和SQL的腳本語言，可以直接在數據庫中進行復雜的編程和運算。DolphinDB內部用Data Source來抽象分區數據。在Data Source之上，可以完成SQL，機器學習，批處理和流處理等計算任務。一個Data Source既可以是內置的數據庫分區，也可以是外部數據。如果Data Source是內置數據庫的分區，大部分計算都可以在本地完成，極大地提升了計算和查詢效率。

本報告將對DolphinDB、Spark直接訪問HDFS（Spark+Hadoop，下文稱為Spark）、Spark通過Hive組件訪問HDFS（Spark+Hive+Hadoop，下文稱為Spark+Hive）三者進行性能對比測試。測試內容包括數據導入、磁盤空間占用、數據查詢以及多用戶并發查詢。通過對比測試，我們能更深入的了解影響性能的主要因素，以及不同工具的最佳應用場景。

2. 環境配置

2.1 硬件配置

本次測試使用了兩臺配置完全相同的服務器（機器1，機器2），各個配置參數如下：

主機：DELL PowerEdge R730xd

CPU：Intel Xeon(R) CPU E5-2650 v4（24核 48線程 2.20GHz）

內存：512 GB （32GB × 16, 2666 MHz）

硬盤：17T HDD （1.7T × 10, 222 MB/s 讀取；210 MB/s 寫入）

網絡：萬兆以太網

OS： CentOS Linux release 7.6.1810 (Core)

2.2 集群配置

測試的DolphinDB版本為Linux v0.95。測試集群的控制節點部署在機器1上，每臺機器上各部署三個數據節點，共六個數據節點。每個數據節點配置8個worker，7個executor，24G內存。

測試的Spark版本為2.3.3，搭載Apache Hadoop 2.9.0。Hadoop與Spark配置為完全分布式模式，機器1為Master，并且在機器1、機器2上都具有Slave。Hive的版本是1.2.2，機器1、機器2上都具有Hive。元數據存儲在機器1上的MySql數據庫中。Spark 與Spark + Hive使用Standalone模式下的client 方式來提交應用。

測試時，DolphinDB、Spark、Spark+Hive均配置6塊硬盤，不同并發數下使用的CPU、內存總和都相同，都是48個線程，144G內存。Spark與Spark+Hive使用的資源只是對于特定的應用，每個應用有6個executor，在多用戶并發的情況下，Spark、Spark+Hive單個用戶使用的資源會隨著用戶數量增多而減少。不同并發數下每個用戶使用的資源如表1所示。

表1.Spark、Spark+Hive不同并發數下單用戶使用的資源

3. 數據集及數據庫設計

3.1 數據集

測試數據集是紐約證券交易所（NYSE）提供的TAQ數據集，包含 8000 多支股票在2007.08.01-2007.08.31一個月內的Level 1報價數據，包含交易時間, 股票代碼, 買入價, 賣出價, 買入量, 賣出量等報價信息。數據集中共有 65 億（6,561,693,704）條報價記錄，一個 CSV 中保存一個交易日的記錄，該月共23個交易日，未壓縮的 23個CSV 文件共計 277 GB。

數據來源：https://www.nyse.com/market-data/historical

3.2 數據庫設計

表2. TAQ在各個系統中的數據類型。

在 DolphinDB database 中，我們按照date、symbol列組合分區，第一分區使用日期DATE來進行值分區，共23個分區，第二分區使用股票代碼SYMBOL來進行范圍分區，分區數量100個，每個分區大約120M左右。

Spark存儲在HDFS上的數據以23個csv對應23個目錄。Spark+Hive采用兩層分區，第一層分區使用日期DATE列進行靜態分區，第二層分區使用股票代碼SYMBOL進行動態分區。

具體腳本見附錄。

4. 數據導入和查詢測試

4.1 數據導入測試

原始數據均勻地分布在兩臺服務器的6個硬盤上，這樣可以充分利用集群中的所有資源。DolphinDB通過異步多節點的方式并行導入數據，Spark與Spark+Hive并行啟動6個應用來讀取數據，把數據存儲到HDFS中。各個系統導入數據的時間如表3所示。各個系統中數據占用的磁盤空間如表4所示。數據導入腳本見附錄。

表3. DolphinDB、Spark、Spark+Hive導入數據時間

表4. DolphinDB、Spark、Spark+Hive中數據占用的磁盤空間

DolphinDB的導入性能明顯優于Spark和Spark+Hive，是Spark的4倍左右，是Spark + Hive的6倍左右。DolphinDB使用C++編寫并且內部有很多優化，極大地利用了磁盤的IO。

DolphinDB占用的磁盤空間大于Spark與Spark+Hive，大約是他們的2倍，這是因為Spark和Spark+Hive在Hadoop上都使用Parquet格式，Parquet格式通過Spark寫入到Hadoop上默認使用snappy壓縮。

4.2 數據查詢測試

為保證測試公平，每個查詢語句要進行多次測試，每次測試之前均通過 Linux 系統命令分別清除系統的頁面緩存、目錄項緩存和硬盤緩存。DolphinDB還清除其內置緩存。

表5中的查詢語句涵蓋了大部分查詢場景，包含分組、排序、條件、聚合計算、點查詢、全表查詢，用來評估DolphinDB、Spark、Spark+Hive在不同用戶數量提交下的性能。

表5. DolphinDB、Spark、Spark+Hive查詢語句

4.2.1 DolphinDB與Spark單用戶查詢測試

以下是DolphinDB與Spark單用戶查詢的結果，結果中的耗時為查詢8次的平均用時。

表6. DolphinDB、Spark單用戶查詢結果

從結果可以看出，DolphinDB的查詢性能是Spark+HDFS的200倍左右。查詢Q1到Q6都是以DolphinDB的分區字段為過濾條件，DolphinDB只需要加載指定分區的數據，無需全表掃描，而Spark從Q1到Q6都需要全表掃描，耗費大量的時間。對于查詢Q7，DolphinDB和Spark都需要全表掃描，但是DolphinDB只加載相關的列，無需加載所有列，而Spark則需要加載所有數據。由于Query運行時間被數據加載主導，DolphinDB和Spark的性能差距沒有之前的查詢語句的大。

4.2.2 DolphinDB與Spark+Hive單用戶查詢測試

由于DolphinDB的數據經過分區，且在查詢的時候實現謂詞下推，效率明顯高于Spark。此處我們使用Spark搭載Hive組件來訪問HDFS，對比DolphinDB和Spark+Hive的查詢性能。以下是DolphinDB、Spark+Hive單用戶查詢的結果，結果中的耗時為查詢8次的平均用時。

表7. DolphinDB、Spark+Hive單用戶查詢結果

結果顯示，DolphinDB的查詢性能明顯優于Spark+Hive，是Spark+Hive的數十倍。與表6的結果相比，Spark+Hive的查詢速度比Spark要快得多，DolphinDB具有的優勢明顯下降了很多。這是因為Hive對數據進行分區，且在查詢語句的條件帶有分區字段的時候，只加載部分數據，實現數據過濾，提高效率。查詢語句Q7掃描全表的時候會出現內存溢出。

DolphinDB、Spark+Hive都對數據進行了分區，且在加載數據時都可以實現謂詞下推，達到數據過濾的效果，但是DolphinDB的查詢速度優于Spark+Hive。這是因為Spark+Hive區讀取HDFS上的數據是不同系統之間的訪問，數據要經過序列化、網絡傳輸、反序列化的過程，非常耗時，從而影響性能。DolphinDB的大部分計算都在本地完成，減少了數據傳輸，因此更加高效。

4.2.3 DolphinDB與Spark計算能力對比

上面DolphinDB分別與Spark、Spark+Hive的查詢性能對比，由于數據分區、查詢時的數據過濾以及傳輸影響了Spark的性能，因此這里我們先把數據加載到內存中，再進行相關的計算，比較DolphinDB和Spark+Hive。我們省略了Spark+Hive，因為使用Hive只是為了數據過濾，讀取HDFS上的數據更加高效，這里的測試數據已經在內存中。

表8是測試計算能力的語句。每次測試都包含兩個語句，第一個語句是把數據加載到內存中，第二個語句是對內存中的數據進行計算。DolphinDB會自動緩存數據，Spark則通過自己的默認緩存機制重新創建一個臨時表TmpTbl。

表8. DolphinDB與Spark計算能力對比語句

以下是DolphinDB與Spark計算能力的測試結果，結果中的耗時是測試5次的平均用時。

表9. DolphinDB與Spark計算能力測試結果

由于數據已經在內存中，對比表6，Spark使用的時間大幅度減少，但是DolphinDB的計算能力仍然比Spark優越。DolphinDB用C++編寫，自己管理內存，比起Spark使用JVM來管理內存更加高效。另外，DolphinDB內置了更高效的算法，提高了計算性能。

DolphinDB的分布式計算以分區為單位，計算指定內存的數據。Spark加載整個HDFS上的塊，一個數據塊包含了具有不同symbol值的數據，雖然緩存，但是仍然要篩選，所以在Q1與Q2的比值較大。Spark計算時使用的廣播變量是經過壓縮的，傳輸到其他的executor上再解壓影響性能。

4.2.4 多用戶并發查詢

我們使用表5中的查詢語句，對DolphinDB、Spark、Spark+Hive進行多用戶并發查詢測試。以下是測試結果，結果中的耗時是查詢8次的平均用時。

表10. DolphinDB、Spark、Spark+Hive多用戶并發查詢結果

圖1. DolphinDB、Spark多用戶查詢結果對比

圖2. DolphinDB、Spark+Hive多用戶查詢結果對比

從上面的結果可以看出，隨著并發數量的增加，三者的查詢時間逐漸增加。當達到8個用戶并發的時候Spark性能較之前少量的用戶并發情況下顯著下降，Spark 在執行Q7的時候會導致worker死亡。Spark+ Hive在多用戶訪問的時候與DolphinDB一樣，基本保持穩定，但是執行Q7查詢語句的一直會出現內存溢出的異常。

Spark+ Hive的查詢配置與Spark 一樣，因為有分區的作用，并且可以過濾數據，查詢數據量比較小，所以效率相對于Spark掃描全部數據比較好。

DolphinDB在并發查詢中性能明顯優于Spark 與Spark+ Hive，從上圖可以看出在多用戶并發訪問情況下，隨著用戶數量的增加，DolphinDB相對于Spark 的優勢幾乎是線性增長，相對于Spark + Hive 的優勢基本保持不變，體現了有數據分區在查詢的時候實現數據過濾的重要性。

DolphinDB在多用戶并發的情況下實現了多用戶的數據共享，不像Spark 的數據只是針對于具體的應用。所以在8個并發用戶的情況下，Spark 每個用戶分配到的資源比較少，性能顯著下降。DolphinDB的數據共享可以減少資源的使用，在有限的資源下，把更多的資源留給用戶計算使用，提高用戶并發的效率，增大用戶的并發數量。

5. 小結

在數據的導入方面，DolphinDB可以并行加載，Spark與Spark+Hive 則通過多個應用同時加載來導入數據。DolphinDB的導入速度是Spark 和Spark+ Hive 的4-6倍。在磁盤空間上，DolphinDB占用的磁盤空間是Spark與Spark+ Hive在Hadoop上占用的磁盤空間的兩倍左右，Spark與Spark + Hive使用了snappy壓縮。

在數據的SQL查詢方面，DolphinDB的優勢更加明顯。優勢主要來自四個方面：（1）本地化計算，（2）分區過濾，（3）優化的內存計算，（4）跨會話的數據共享。在單用戶查詢情況下，DolphinDB的查詢速度是Spark的幾倍到上百倍，是Spark+ Hive 的幾十倍。Spark 讀取HDFS 是不同的系統之間的調用，其中包含了數據的序列化，網絡，反序列化非常消耗時間，且占據很多的資源。DolphinDB的SQL查詢大部分是本地化計算，大幅減少了數據傳輸和加載的時間。Spark+ Hive 相對與Spark速度提升很大，主要是因為Spark + Hive只掃描相關分區的數據，實現了數據的過濾。在剔除本地化和分區過濾的因素后（即所有數據已經在內存中），DolphinDB的計算能力仍然優于Spark數倍。DolphinDB基于分區的分布式計算效率很高，且對內存的管理比Spark基于JVM的管理更加優秀。Spark的多用戶并發會隨著用戶數量的增多效率逐漸下降，在查詢大數據量的時候用戶過多導致worker 死亡。Spark + Hive的多用戶并發相對比較穩定，但是加載數據過大會出現內存溢出錯誤。 多用戶情況下, DolphinDB可以實現數據的共享，從而減少加載數據使用的資源，查詢速度是Spark的數百倍，是Spark+Hive 的幾十倍。隨著用戶數量的增加，DolphinDB相對于Spark的性能優勢更加明顯。涉及到分區查詢的情況下，Spark+ Hive與DolphinDB顯著提高查詢性能。

Spark是一個非常優秀的通用分布式計算引擎，在SQL查詢、批處理、流處理、機器學習等方面均有上佳表現。但由于SQL查詢通常只需要對數據計算一次，相對于機器學習需要上百次的迭代，內存計算的優勢無法充分體現。因此，我們更建議將Spark用于計算密集型的機器學習。

在測試過程中，我們也發現DolphinDB是一個非常輕量級的實現，集群的搭建簡單快速， Spark + Hive+ Hadoop 集群安裝配置非常復雜。

附錄

附錄1. 數據預覽

附錄2. Hive創建表語句

CREATE TABLE IF NOT EXISTS TAQ (time TIMESTAMP, bid DOUBLE, ofr DOUBLE, bidsiz INT, ofrsiz INT, mode INT, ex TINYINT, mmid STRING）PARTITIONED BY (date DATE, symbol STRING) STORED AS PARQUET;

附錄3.

DolphinDB導入數據腳本：

fps1、fps2分別代表機器1、2上所有的csv路徑的vector
fps是包含fps1和fps2 的vector
allSites1、allSites2 分別代表機器1、2上數據節點名稱的vector
allSite 是包含 allSites1和allSites2的vector
DATE_RANGE=2007.07.01..2007.09.01
date_schema=database('', VALUE, DATE_RANGE)
symbol_schema=database('', RANGE, buckets)
db=database(FP_DB, COMPO,[date_schema,symbol_schema])
taq = db.createPartitionedTable(schema, `taq, `date`symbol)
for(i in 0..1){
	for(j in 0..(size(fps[i])-1))  {
		rpc(allSites[i][j] % size(allSite[i])],submitJob,"loadData" , "loadData" ,loadTextEx{database(FP_DB), "taq", `date`symbol, fps[i][j]} )
	}
}

Spark與Hive導入數據的配置：

--master local[8]
--executor-memory 24G

看完上述內容，你們對如何分析時序數據庫DolphinDB與Spark的性能對比測試報告有進一步的了解嗎？如果還想了解更多知識或者相關內容，請關注億速云行業資訊頻道，感謝大家的支持。