乾貨|開源OLAP引擎(ClickHouse、Doris、Presto、ByConity)性能對比分析

隨着數據量和數據複雜性的不斷增加,越來越多的企業開始使用OLAP(聯機分析處理)引擎來處理大規模數據並提供即時分析結果。在選擇OLAP引擎時,性能是一個非常重要的因素。

 

因此,本文將使用TPC-DS基準測試的99個查詢語句來對比開源的ClickHouse、Doris、Presto以及ByConity這4個OLAP引擎的性能表現,以便爲企業選擇合適的OLAP引擎提供參考。

 

圖片

文|蘊博  來自ByConity開源團隊

 

 

圖片

TPC-DS(Transaction Processing Performance Council Decision Support Benchmark)是一個面向決策支持系統(Decision Support System,簡稱DSS)的基準測試,該工具是由TPC組織開發,它模擬了多維分析和決策支持場景,並提供了99個查詢語句,用於評估數據庫系統在複雜的多維分析場景下的性能。每個查詢都設計用於模擬複雜的決策支持場景,包括跨多個表的連接、聚合和分組、子查詢等高級SQL技術。

 

圖片

ClickHouse、Doris、Presto和ByConity都是當前比較流行的開源OLAP引擎,它們都具有高性能和可擴展性的特點。

 

● ClickHouse是由俄羅斯搜索引擎公司Yandex開發的一個列式數據庫管理系統,它專注於大規模數據的快速查詢和分析。

● Doris是一個分佈式列式存儲和分析系統,它支持實時查詢和分析,並可以與Hadoop、Spark和Flink等大數據技術進行集成。

● Presto是一個分佈式SQL查詢引擎,它由Facebook開發,可以在大規模數據集上進行快速查詢和分析。

● ByConity是由字節開源的雲原生數倉,採用了存儲計算分離的架構,實現租戶資源隔離、彈性擴縮容,並具有數據讀寫的強一致性等特性,它支持主流的OLAP引擎優化技術,讀寫性能非常優異。

 

本文將使用這四個OLAP引擎對TPC-DS基準測試的99個查詢語句進行性能測試,並對比它們在不同類型的查詢中的性能差異。

 

圖片

測試環境配置:

 

 

Clickhouse

Doris

Presto

ByConity

環境配置

Memory: 256GB

Disk: ATA, 7200rpm, partitioned:gpt

System: Linux 4.14.81.bm.30-amd64 x86_64, Debian GNU/Linux 9

 

測試數據量

使用1TB的數據表,相當於28億行數據量級

軟件包版本

23.4.1.1943

1.2.4.1

0.28.0

0.1.0-GA

版本發佈時間

2023-04-26

2023-04-27

2023-03-16

2023-03-15

節點數

5個Worker

5個BE,1個FE

5個Worker,1個Coordinator

5個Worker,1個Server

其他配置

distributed_product_mode = 'global', partial_merge_join_optimizations = 1

bucket配置:維表1,returns表10-20,sales表100-200

 

Hive Catalog,

ORC format,

Xmx200GB

enable_optimizer=1, dialect_type='ANSI'

 

服務器配置:

Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                48
On-line CPU(s) list:   0-47
Thread(s) per core:    2
Core(s) per socket:    12
Socket(s):             2
NUMA node(s):          2
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 79
Model name:            Intel(R) Xeon(R) CPU E5-2650 v4 @ 2.20GHz
Stepping:              1
CPU MHz:               2494.435
CPU max MHz:           2900.0000
CPU min MHz:           1200.0000
BogoMIPS:              4389.83
Virtualization:        VT-x
L1d cache:             32K
L1i cache:             32K
L2 cache:              256K
L3 cache:              30720K
NUMA node0 CPU(s):     0-11,24-35
NUMA node1 CPU(s):     12-23,36-47

 

測試方法:

 

● 使用TPC-DS基準測試的99個查詢語句,和1TB(28億行)的數據測試4個OLAP引擎的性能。

● 在每個引擎中使用相同的測試數據集,並保持相同的配置和硬件環境。

● 對於每個查詢,多次執行並取平均值,以減少測量誤差,設置每次查詢超時時間爲500秒。

● 記錄查詢執行的細節,例如查詢執行計劃、I/O和CPU使用情況等。

 

圖片

我們使用了相同的數據集和硬件環境來測試這四個OLAP引擎的性能。

 

測試數據集大小爲1TB,硬件和軟件環境如上介紹,我們使用了TPC-DS基準測試中的99個查詢語句分別在四個OLAP引擎上進行了連續三次的測試,並取三次平均結果。

 

● 其中ByConity跑通了所有99個查詢測試。

● Doris在SQL15出現Crash,另外有4次的Timeout,分別是SQL54、SQL67、SQL78和SQL95。

● Presto只在SQL67和SQL72發生Timeout,其他查詢測試都跑通了。

● Clickhouse只跑通了50%的查詢語句,大概有一部分是Timeout,另一部分是系統報錯,分析原因是Clickhouse不能有效的支持多表關聯查詢導致,只能把這類SQL語句做手動改寫拆分才能執行。

 

因此在對比總耗時我們暫時排除Clickhouse,其他三個OLAP引擎TPC-DS測試總耗時如下圖1所示,從圖1 中我們可以看出開源的ByConity查詢性能明顯優於其他引擎,性能約是其他的3-4倍。(注:以下所有圖表縱座標單位爲秒)

 

圖片

圖1 TPC-DS 99條查詢總耗時

 

針對TPC-DS基準測試的99個查詢語句,我們接下來按照查詢場景的不同進行分類,例如基礎查詢、連接查詢、聚合查詢、子查詢、窗口函數查詢等。

 

下面我們將使用這些分類方式來對ClickHouse、Doris、Presto和ByConity四個OLAP引擎進行性能分析對比:

 

/ 基礎查詢場景下 /

 

該場景包含簡單的查詢操作,例如從單個表中查詢數據,過濾和排序結果等。基礎查詢的性能測試主要關注處理單個查詢的能力。

 

其中ByConity的表現最佳,Presto和Doris的性能也表現都不錯,這是因爲基礎查詢通常只涉及到少量的數據表和字段,因此能夠充分利用Presto和Doris的分佈式查詢特性和內存計算能力,Clickhouse對多表關聯支持不好,出現一些跑不通的現象,其中SQL5、8、11、13、14、17、18均超時,我們按Timeout=500秒計算,但希望顯示更清晰截取Timeout=350秒。

 

下圖2 是基礎查詢場景下四個引擎的平均查詢時間:

 

圖片

圖2 TPC-DS 基礎查詢的性能對比

 

/ 連接查詢場景 /

 

連接查詢是常見的多表查詢場景,它通常使用JOIN語句連接多個表,並根據指定條件進行數據檢索。

 

如圖3 我們看到ByConity的性能最佳,主要得益於對查詢優化器的優化,引入了基於代價的優化能力(CBO),在多表Join時候進行re-order的等優化操作。其次是Presto和Doris,Clickhouse在多表Join的效果相比其他三個性能不是很好,且對很多複雜語句的支持不夠好。

 

圖片

圖3 TPC-DS連接查詢的性能對比

 

/ 聚合查詢場景 /

 

聚合查詢是對數據進行統計計算的場景,例如測試SUM、AVG、COUNT等聚合函數的使用。

 

ByConity依然表現優異,其次是Doris和Presto,Clickhouse出現了四次Timeout,爲了方便看出差異,我們截取Timeout值到250秒。

 

圖片

圖4 TPC-DS聚合查詢的性能對比

 

/ 子查詢場景 /

 

子查詢是在SQL語句中嵌套使用的查詢場景,它通常作爲主查詢的條件或限制條件。

 

如下圖5所示,ByConity表現最佳,原因是ByConity實現了基於規則的優化能力(RBO)進行查詢優化,通過算子下推、列裁剪和分區裁剪等技術,把複雜的嵌套查詢進行整體優化,替除所有的子查詢,把常見算子轉化成Join+Agg的形式。

 

其次是Doris和Presto表現相對較好,但Presto在SQL68和SQL73出現Timeout,Doris也在3個SQL查詢出現Timeout,Clickhouse同樣出現了部分超時和系統報錯,原因上面有提到。同樣爲方便看出差異,我們截取Timeout值等於250秒。

 

圖片

圖5 TPC-DS子查詢的性能對比

 

/ 窗口函數查詢場景 /

 

窗口函數查詢是一種高級的SQL查詢場景,它可以在查詢結果中進行排名、分組、排序等操作。

 

如下圖6所示,ByConity的性能最優,其次是Presto,Doris出現了一次Timeout的情況,Clickhouse依然有部分沒有跑通TPC-DS測試。

 

圖片

圖6 TPC-DS窗口函數查詢的性能對比

 

圖片

本文對ClickHouse、Doris、Presto和ByConity四個OLAP引擎在TPC-DS基準測試的99個查詢語句下的性能進行了分析和比較。我們發現,在不同的查詢場景下,四個引擎的性能表現存在差異。

 

● ByConity在所有TPC-DS的99個查詢場景下都表現優異,超過其他三個OLAP引擎;

● Presto和Doris在連接查詢、聚合查詢和窗口函數查詢場景下表現較好;

● 由於Clickhouse的設計和實現並不是專門針對關聯查詢進行優化,因此在多表關聯查詢方面整體表現差強人意。

 

需要注意的是,性能測試結果取決於多個因素,包括數據結構、查詢類型、數據模型等。在實際應用中,需要綜合考慮各種因素,以選擇最適合自己的OLAP引擎。

 

在選擇OLAP引擎時,還需要考慮其他因素,如可擴展性、易用性、穩定性等。在實際應用中,需要根據具體業務需求進行選擇,並對引擎進行合理的配置和優化,以獲得最佳的性能表現。

 

總之,ClickHouse、Doris、Presto、ByConity都是非常優秀的OLAP引擎,具有不同的優點和適用場景。在實際應用中,需要根據具體業務需求進行選擇,並進行合理的配置和優化,以獲得最佳的性能表現。同時,需要注意選擇具有代表性的查詢場景和數據集,並針對不同的查詢場景進行測試和分析,以便更全面地評估引擎的性能。

 

作者|ByConity

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章