引言：

隨著數(shù)據(jù)量和數(shù)據(jù)復(fù)雜性的不斷增加，越來越多的企業(yè)開始使用OLAP（聯(lián)機(jī)分析處理）引擎來處理大規(guī)模數(shù)據(jù)并提供即時(shí)分析結(jié)果。在選擇OLAP引擎時(shí)，性能是一個(gè)非常重要的因素。因此，本文將使用TPC-DS基準(zhǔn)測(cè)試的99個(gè)查詢語(yǔ)句來對(duì)比開源的ClickHouse、Doris、Presto以及ByConity這4個(gè)OLAP引擎的性能表現(xiàn)，以便為企業(yè)選擇合適的OLAP引擎提供參考。

TPC-DS基準(zhǔn)測(cè)試簡(jiǎn)介

TPC-DS（Transaction Processing Performance Council Decision Support Benchmark）是一個(gè)面向決策支持系統(tǒng)（Decision Support System，簡(jiǎn)稱DSS）的基準(zhǔn)測(cè)試，該工具是由TPC組織開發(fā)，它模擬了多維分析和決策支持場(chǎng)景，并提供了99個(gè)查詢語(yǔ)句，用于評(píng)估數(shù)據(jù)庫(kù)系統(tǒng)在復(fù)雜的多維分析場(chǎng)景下的性能。每個(gè)查詢都設(shè)計(jì)用于模擬復(fù)雜的決策支持場(chǎng)景，包括跨多個(gè)表的連接、聚合和分組、子查詢等高級(jí)SQL技術(shù)。

OLAP引擎介紹

ClickHouse、Doris、Presto和ByConity都是當(dāng)前比較流行的開源OLAP引擎，它們都具有高性能和可擴(kuò)展性的特點(diǎn)。

ClickHouse是由俄羅斯搜索引擎公司Yandex開發(fā)的一個(gè)列式數(shù)據(jù)庫(kù)管理系統(tǒng)，它專注于大規(guī)模數(shù)據(jù)的快速查詢和分析。

Doris是一個(gè)分布式列式存儲(chǔ)和分析系統(tǒng)，它支持實(shí)時(shí)查詢和分析，并可以與Hadoop、Spark和Flink等大數(shù)據(jù)技術(shù)進(jìn)行集成。

Presto是一個(gè)分布式SQL查詢引擎，它由Facebook開發(fā)，可以在大規(guī)模數(shù)據(jù)集上進(jìn)行快速查詢和分析。

ByConity是由字節(jié)開源的云原生數(shù)倉(cāng)，采用了存儲(chǔ)計(jì)算分離的架構(gòu)，實(shí)現(xiàn)租戶資源隔離、彈性擴(kuò)縮容，并具有數(shù)據(jù)讀寫的強(qiáng)一致性等特性，它支持主流的OLAP引擎優(yōu)化技術(shù)，讀寫性能非常優(yōu)異。

本文將使用這四個(gè)OLAP引擎對(duì)TPC-DS基準(zhǔn)測(cè)試的99個(gè)查詢語(yǔ)句進(jìn)行性能測(cè)試，并對(duì)比它們?cè)诓煌愋偷牟樵冎械男阅懿町悺?/p>

測(cè)試環(huán)境和方法

測(cè)試環(huán)境配置：

服務(wù)器配置：

測(cè)試方法：

使用TPC-DS基準(zhǔn)測(cè)試的99個(gè)查詢語(yǔ)句，和1TB（28億行）的數(shù)據(jù)測(cè)試4個(gè)OLAP引擎的性能。

在每個(gè)引擎中使用相同的測(cè)試數(shù)據(jù)集，并保持相同的配置和硬件環(huán)境。

對(duì)于每個(gè)查詢，多次執(zhí)行并取平均值，以減少測(cè)量誤差，設(shè)置每次查詢超時(shí)時(shí)間為500秒。

記錄查詢執(zhí)行的細(xì)節(jié)，例如查詢執(zhí)行計(jì)劃、I/O和CPU使用情況等。

性能測(cè)試結(jié)果

我們使用了相同的數(shù)據(jù)集和硬件環(huán)境來測(cè)試這四個(gè)OLAP引擎的性能。測(cè)試數(shù)據(jù)集大小為1TB，硬件和軟件環(huán)境如上介紹，我們使用了TPC-DS基準(zhǔn)測(cè)試中的99個(gè)查詢語(yǔ)句分別在四個(gè)OLAP引擎上進(jìn)行了連續(xù)三次的測(cè)試，并取三次平均結(jié)果。其中ByConity跑通了所有99個(gè)查詢測(cè)試。Doris在SQL15出現(xiàn)Crash，另外有4次的Timeout，分別是SQL54、SQL67、SQL78和SQL95。Presto只在SQL67和SQL72發(fā)生Timeout，其他查詢測(cè)試都跑通了。而Clickhouse只跑通了50%的查詢語(yǔ)句，大概有一部分是Timeout，另一部分是系統(tǒng)報(bào)錯(cuò)，分析原因是Clickhouse不能有效的支持多表關(guān)聯(lián)查詢導(dǎo)致，只能把這類SQL語(yǔ)句做手動(dòng)改寫拆分才能執(zhí)行。因此在對(duì)比總耗時(shí)我們暫時(shí)排除Clickhouse，其他三個(gè)OLAP引擎TPC-DS測(cè)試總耗時(shí)如下圖1所示，從圖1 中我們可以看出開源的ByConity查詢性能明顯優(yōu)于其他引擎，性能約是其他的3-4倍。（注：以下所有圖表縱坐標(biāo)單位為秒）

圖1 TPC-DS 99條查詢總耗時(shí)

針對(duì)TPC-DS基準(zhǔn)測(cè)試的99個(gè)查詢語(yǔ)句，我們接下來按照查詢場(chǎng)景的不同進(jìn)行分類，例如基礎(chǔ)查詢、連接查詢、聚合查詢、子查詢、窗口函數(shù)查詢等。下面我們將使用這些分類方式來對(duì)ClickHouse、Doris、Presto和ByConity四個(gè)OLAP引擎進(jìn)行性能分析對(duì)比：

基礎(chǔ)查詢場(chǎng)景下

該場(chǎng)景包含簡(jiǎn)單的查詢操作，例如從單個(gè)表中查詢數(shù)據(jù)，過濾和排序結(jié)果等?；A(chǔ)查詢的性能測(cè)試主要關(guān)注處理單個(gè)查詢的能力。其中ByConity的表現(xiàn)最佳，Presto和Doris的性能也表現(xiàn)都不錯(cuò)，這是因?yàn)榛A(chǔ)查詢通常只涉及到少量的數(shù)據(jù)表和字段，因此能夠充分利用Presto和Doris的分布式查詢特性和內(nèi)存計(jì)算能力，Clickhouse對(duì)多表關(guān)聯(lián)支持不好，出現(xiàn)一些跑不通的現(xiàn)象，其中SQL5、8、11、13、14、17、18均超時(shí)，我們按Timeout=500秒計(jì)算，但希望顯示更清晰截取Timeout=350秒。下圖2 是基礎(chǔ)查詢場(chǎng)景下四個(gè)引擎的平均查詢時(shí)間：

圖2 TPC-DS 基礎(chǔ)查詢的性能對(duì)比

連接查詢場(chǎng)景

連接查詢是常見的多表查詢場(chǎng)景，它通常使用JOIN語(yǔ)句連接多個(gè)表，并根據(jù)指定條件進(jìn)行數(shù)據(jù)檢索。如圖3 我們看到ByConity的性能最佳，主要得益于對(duì)查詢優(yōu)化器的優(yōu)化，引入了基于代價(jià)的優(yōu)化能力（CBO），在多表Join時(shí)候進(jìn)行re-order的等優(yōu)化操作。其次是Presto和Doris，Clickhouse在多表Join的效果相比其他三個(gè)性能不是很好，且對(duì)很多復(fù)雜語(yǔ)句的支持不夠好。

圖3 TPC-DS連接查詢的性能對(duì)比

聚合查詢場(chǎng)景

聚合查詢是對(duì)數(shù)據(jù)進(jìn)行統(tǒng)計(jì)計(jì)算的場(chǎng)景，例如測(cè)試SUM、AVG、COUNT等聚合函數(shù)的使用。ByConity依然表現(xiàn)優(yōu)異，其次是Doris和Presto，Clickhouse出現(xiàn)了四次Timeout，為了方便看出差異，我們截取Timeout值到250秒。

圖4 TPC-DS聚合查詢的性能對(duì)比

子查詢場(chǎng)景

子查詢是在SQL語(yǔ)句中嵌套使用的查詢場(chǎng)景，它通常作為主查詢的條件或限制條件。如下圖5所示，ByConity表現(xiàn)最佳，原因是ByConity實(shí)現(xiàn)了基于規(guī)則的優(yōu)化能力（RBO）進(jìn)行查詢優(yōu)化，通過算子下推、列裁剪和分區(qū)裁剪等技術(shù)，把復(fù)雜的嵌套查詢進(jìn)行整體優(yōu)化，替除所有的子查詢，把常見算子轉(zhuǎn)化成Join+Agg的形式。其次是Doris和Presto表現(xiàn)相對(duì)較好，但Presto在SQL68和SQL73出現(xiàn)Timeout，Doris也在3個(gè)SQL查詢出現(xiàn)Timeout，Clickhouse同樣出現(xiàn)了部分超時(shí)和系統(tǒng)報(bào)錯(cuò)，原因上面有提到。同樣為方便看出差異，我們截取Timeout值等于250秒。

圖5 TPC-DS子查詢的性能對(duì)比

窗口函數(shù)查詢場(chǎng)景

窗口函數(shù)查詢是一種高級(jí)的SQL查詢場(chǎng)景，它可以在查詢結(jié)果中進(jìn)行排名、分組、排序等操作。如下圖6所示，ByConity的性能最優(yōu)，其次是Presto，Doris出現(xiàn)了一次Timeout的情況，Clickhouse依然有部分沒有跑通TPC-DS測(cè)試。

圖6 TPC-DS窗口函數(shù)查詢的性能對(duì)比

總結(jié)

本文對(duì)ClickHouse、Doris、Presto和ByConity四個(gè)OLAP引擎在TPC-DS基準(zhǔn)測(cè)試的99個(gè)查詢語(yǔ)句下的性能進(jìn)行了分析和比較。我們發(fā)現(xiàn)，在不同的查詢場(chǎng)景下，四個(gè)引擎的性能表現(xiàn)存在差異。ByConity在所有TPC-DS的99個(gè)查詢場(chǎng)景下都表現(xiàn)優(yōu)異，超過其他三個(gè)OLAP引擎；Presto和Doris在連接查詢、聚合查詢和窗口函數(shù)查詢場(chǎng)景下表現(xiàn)較好；由于Clickhouse的設(shè)計(jì)和實(shí)現(xiàn)并不是專門針對(duì)關(guān)聯(lián)查詢進(jìn)行優(yōu)化，因此在多表關(guān)聯(lián)查詢方面整體表現(xiàn)差強(qiáng)人意。

需要注意的是，性能測(cè)試結(jié)果取決于多個(gè)因素，包括數(shù)據(jù)結(jié)構(gòu)、查詢類型、數(shù)據(jù)模型等。在實(shí)際應(yīng)用中，需要綜合考慮各種因素，以選擇最適合自己的OLAP引擎。

在選擇OLAP引擎時(shí)，還需要考慮其他因素，如可擴(kuò)展性、易用性、穩(wěn)定性等。在實(shí)際應(yīng)用中，需要根據(jù)具體業(yè)務(wù)需求進(jìn)行選擇，并對(duì)引擎進(jìn)行合理的配置和優(yōu)化，以獲得最佳的性能表現(xiàn)。

總之，ClickHouse、Doris、Presto、ByConity都是非常優(yōu)秀的OLAP引擎，具有不同的優(yōu)點(diǎn)和適用場(chǎng)景。在實(shí)際應(yīng)用中，需要根據(jù)具體業(yè)務(wù)需求進(jìn)行選擇，并進(jìn)行合理的配置和優(yōu)化，以獲得最佳的性能表現(xiàn)。同時(shí)，需要注意選擇具有代表性的查詢場(chǎng)景和數(shù)據(jù)集，并針對(duì)不同的查詢場(chǎng)景進(jìn)行測(cè)試和分析，以便更全面地評(píng)估引擎的性能。

加入我們

ByConity社區(qū)擁有大量的用戶，同時(shí)是一個(gè)非常開放的社區(qū)，我們邀請(qǐng)大家和我們一起討論共建，在Github上建立了issue：https://github.com/ByConity/ByConity/issues/26，也可以加入我們的飛書群、Slack或者Discord參與交流。

免責(zé)聲明：市場(chǎng)有風(fēng)險(xiǎn)，選擇需謹(jǐn)慎！此文僅供參考，不作買賣依據(jù)。

關(guān)鍵詞：