引言: 隨著數(shù)據(jù)量和數(shù)據(jù)復(fù)雜性的不斷增加,越來越多的企業(yè)開始使用OLAP(聯(lián)機分析處理)引擎來處理大規(guī)模數(shù)據(jù)并提供即時分析結(jié)果。在選擇OLAP引擎時,性能是一個非常重要的因素。因此,本文將使用TPC-DS基準(zhǔn)測試的99個查詢語句來對比開源的ClickHouse、Doris、Presto以及ByConity這4個OLAP引擎的性能表現(xiàn),以便為企業(yè)選擇合適的OLAP引擎提供參考。 TPC-DS基準(zhǔn)測試簡介 TPC-DS(Transaction Processing Performance Council Decision Support Benchmark)是一個面向決策支持系統(tǒng)(Decision Support System,簡稱DSS)的基準(zhǔn)測試,該工具是由TPC組織開發(fā),它模擬了多維分析和決策支持場景,并提供了99個查詢語句,用于評估數(shù)據(jù)庫系統(tǒng)在復(fù)雜的多維分析場景下的性能。每個查詢都設(shè)計用于模擬復(fù)雜的決策支持場景,包括跨多個表的連接、聚合和分組、子查詢等高級SQL技術(shù)。 OLAP引擎介紹 ClickHouse、Doris、Presto和ByConity都是當(dāng)前比較流行的開源OLAP引擎,它們都具有高性能和可擴展性的特點。 ClickHouse是由俄羅斯搜索引擎公司Yandex開發(fā)的一個列式數(shù)據(jù)庫管理系統(tǒng),它專注于大規(guī)模數(shù)據(jù)的快速查詢和分析。 Doris是一個分布式列式存儲和分析系統(tǒng),它支持實時查詢和分析,并可以與Hadoop、Spark和Flink等大數(shù)據(jù)技術(shù)進行集成。 Presto是一個分布式SQL查詢引擎,它由Facebook開發(fā),可以在大規(guī)模數(shù)據(jù)集上進行快速查詢和分析。 ByConity是由字節(jié)開源的云原生數(shù)倉,采用了存儲計算分離的架構(gòu),實現(xiàn)租戶資源隔離、彈性擴縮容,并具有數(shù)據(jù)讀寫的強一致性等特性,它支持主流的OLAP引擎優(yōu)化技術(shù),讀寫性能非常優(yōu)異。 本文將使用這四個OLAP引擎對TPC-DS基準(zhǔn)測試的99個查詢語句進行性能測試,并對比它們在不同類型的查詢中的性能差異。 測試環(huán)境和方法 測試環(huán)境配置: 服務(wù)器配置: 測試方法: 使用TPC-DS基準(zhǔn)測試的99個查詢語句,和1TB(28億行)的數(shù)據(jù)測試4個OLAP引擎的性能。 在每個引擎中使用相同的測試數(shù)據(jù)集,并保持相同的配置和硬件環(huán)境。 對于每個查詢,多次執(zhí)行并取平均值,以減少測量誤差,設(shè)置每次查詢超時時間為500秒。 記錄查詢執(zhí)行的細(xì)節(jié),例如查詢執(zhí)行計劃、I/O和CPU使用情況等。 性能測試結(jié)果 我們使用了相同的數(shù)據(jù)集和硬件環(huán)境來測試這四個OLAP引擎的性能。測試數(shù)據(jù)集大小為1TB,硬件和軟件環(huán)境如上介紹,我們使用了TPC-DS基準(zhǔn)測試中的99個查詢語句分別在四個OLAP引擎上進行了連續(xù)三次的測試,并取三次平均結(jié)果。其中ByConity跑通了所有99個查詢測試。Doris在SQL15出現(xiàn)Crash,另外有4次的Timeout,分別是SQL54、SQL67、SQL78和SQL95。Presto只在SQL67和SQL72發(fā)生Timeout,其他查詢測試都跑通了。而Clickhouse只跑通了50%的查詢語句,大概有一部分是Timeout,另一部分是系統(tǒng)報錯,分析原因是Clickhouse不能有效的支持多表關(guān)聯(lián)查詢導(dǎo)致,只能把這類SQL語句做手動改寫拆分才能執(zhí)行。因此在對比總耗時我們暫時排除Clickhouse,其他三個OLAP引擎TPC-DS測試總耗時如下圖1所示,從圖1 中我們可以看出開源的ByConity查詢性能明顯優(yōu)于其他引擎,性能約是其他的3-4倍。(注:以下所有圖表縱坐標(biāo)單位為秒) 圖1 TPC-DS 99條查詢總耗時 針對TPC-DS基準(zhǔn)測試的99個查詢語句,我們接下來按照查詢場景的不同進行分類,例如基礎(chǔ)查詢、連接查詢、聚合查詢、子查詢、窗口函數(shù)查詢等。下面我們將使用這些分類方式來對ClickHouse、Doris、Presto和ByConity四個OLAP引擎進行性能分析對比: 基礎(chǔ)查詢場景下 該場景包含簡單的查詢操作,例如從單個表中查詢數(shù)據(jù),過濾和排序結(jié)果等。基礎(chǔ)查詢的性能測試主要關(guān)注處理單個查詢的能力。其中ByConity的表現(xiàn)最佳,Presto和Doris的性能也表現(xiàn)都不錯,這是因為基礎(chǔ)查詢通常只涉及到少量的數(shù)據(jù)表和字段,因此能夠充分利用Presto和Doris的分布式查詢特性和內(nèi)存計算能力,Clickhouse對多表關(guān)聯(lián)支持不好,出現(xiàn)一些跑不通的現(xiàn)象,其中SQL5、8、11、13、14、17、18均超時,我們按Timeout=500秒計算,但希望顯示更清晰截取Timeout=350秒。下圖2 是基礎(chǔ)查詢場景下四個引擎的平均查詢時間: 圖2 TPC-DS 基礎(chǔ)查詢的性能對比 連接查詢場景 連接查詢是常見的多表查詢場景,它通常使用JOIN語句連接多個表,并根據(jù)指定條件進行數(shù)據(jù)檢索。如圖3 我們看到ByConity的性能最佳,主要得益于對查詢優(yōu)化器的優(yōu)化,引入了基于代價的優(yōu)化能力(CBO),在多表Join時候進行re-order的等優(yōu)化操作。其次是Presto和Doris,Clickhouse在多表Join的效果相比其他三個性能不是很好,且對很多復(fù)雜語句的支持不夠好。 圖3 TPC-DS連接查詢的性能對比 聚合查詢場景 聚合查詢是對數(shù)據(jù)進行統(tǒng)計計算的場景,例如測試SUM、AVG、COUNT等聚合函數(shù)的使用。ByConity依然表現(xiàn)優(yōu)異,其次是Doris和Presto,Clickhouse出現(xiàn)了四次Timeout,為了方便看出差異,我們截取Timeout值到250秒。 圖4 TPC-DS聚合查詢的性能對比 子查詢場景 子查詢是在SQL語句中嵌套使用的查詢場景,它通常作為主查詢的條件或限制條件。如下圖5所示,ByConity表現(xiàn)最佳,原因是ByConity實現(xiàn)了基于規(guī)則的優(yōu)化能力(RBO)進行查詢優(yōu)化,通過算子下推、列裁剪和分區(qū)裁剪等技術(shù),把復(fù)雜的嵌套查詢進行整體優(yōu)化,替除所有的子查詢,把常見算子轉(zhuǎn)化成Join+Agg的形式。其次是Doris和Presto表現(xiàn)相對較好,但Presto在SQL68和SQL73出現(xiàn)Timeout,Doris也在3個SQL查詢出現(xiàn)Timeout,Clickhouse同樣出現(xiàn)了部分超時和系統(tǒng)報錯,原因上面有提到。同樣為方便看出差異,我們截取Timeout值等于250秒。 圖5 TPC-DS子查詢的性能對比 窗口函數(shù)查詢場景 窗口函數(shù)查詢是一種高級的SQL查詢場景,它可以在查詢結(jié)果中進行排名、分組、排序等操作。如下圖6所示,ByConity的性能最優(yōu),其次是Presto,Doris出現(xiàn)了一次Timeout的情況,Clickhouse依然有部分沒有跑通TPC-DS測試。 圖6 TPC-DS窗口函數(shù)查詢的性能對比 總結(jié) 本文對ClickHouse、Doris、Presto和ByConity四個OLAP引擎在TPC-DS基準(zhǔn)測試的99個查詢語句下的性能進行了分析和比較。我們發(fā)現(xiàn),在不同的查詢場景下,四個引擎的性能表現(xiàn)存在差異。ByConity在所有TPC-DS的99個查詢場景下都表現(xiàn)優(yōu)異,超過其他三個OLAP引擎;Presto和Doris在連接查詢、聚合查詢和窗口函數(shù)查詢場景下表現(xiàn)較好;由于Clickhouse的設(shè)計和實現(xiàn)并不是專門針對關(guān)聯(lián)查詢進行優(yōu)化,因此在多表關(guān)聯(lián)查詢方面整體表現(xiàn)差強人意。 需要注意的是,性能測試結(jié)果取決于多個因素,包括數(shù)據(jù)結(jié)構(gòu)、查詢類型、數(shù)據(jù)模型等。在實際應(yīng)用中,需要綜合考慮各種因素,以選擇最適合自己的OLAP引擎。 在選擇OLAP引擎時,還需要考慮其他因素,如可擴展性、易用性、穩(wěn)定性等。在實際應(yīng)用中,需要根據(jù)具體業(yè)務(wù)需求進行選擇,并對引擎進行合理的配置和優(yōu)化,以獲得最佳的性能表現(xiàn)。 總之,ClickHouse、Doris、Presto、ByConity都是非常優(yōu)秀的OLAP引擎,具有不同的優(yōu)點和適用場景。在實際應(yīng)用中,需要根據(jù)具體業(yè)務(wù)需求進行選擇,并進行合理的配置和優(yōu)化,以獲得最佳的性能表現(xiàn)。同時,需要注意選擇具有代表性的查詢場景和數(shù)據(jù)集,并針對不同的查詢場景進行測試和分析,以便更全面地評估引擎的性能。 加入我們 ByConity社區(qū)擁有大量的用戶,同時是一個非常開放的社區(qū),我們邀請大家和我們一起討論共建,在Github上建立了issue:https://github.com/ByConity/ByConity/issues/26,也可以加入我們的飛書群、Slack或者Discord參與交流。 |