1.查詢性能：DorisDB vs ClickHouse vs Apache Doris

查詢性能對(duì)比測(cè)試使用SSB測(cè)試集，數(shù)據(jù)量最大的表lineorder約60億(scale 1000)。在ClickHouse最擅長的寬表模式下，分別在限制線程數(shù)不超過8，不限制線程數(shù)兩種情況下對(duì)比了DorisDB和Clickhouse的性能。

在DorisDB和ClickHouse單節(jié)點(diǎn)都使用不超過8個(gè)線程的情況下，13個(gè)查詢中有9個(gè)DorisDB的性能好于ClickHouse。

(寬表模式，設(shè)置ClickHouse max_threads=8）

不限制ClickHouse線程數(shù)情況下，13個(gè)查詢中有7個(gè)DorisDB性能好于ClickHouse。

(寬表模式，不限制max_threads）

在多表Join模式下，對(duì)比了DorisDB和Apache Doris的表現(xiàn)。整體上DorisDB比Apache Doris有5-10倍的性能優(yōu)勢(shì)。

沒有對(duì)Apache Doris的寬表性能進(jìn)程測(cè)試，是由于在60億的數(shù)據(jù)量下，DorisDB可以直接使用insert into select語句將數(shù)據(jù)轉(zhuǎn)成寬表，Apache doris執(zhí)行相同語句會(huì)報(bào)oom。由此也可以看出DorisDB在內(nèi)存的管理和執(zhí)行效率上比Apache Doris要好不少。同時(shí)也了解到DorisDB后續(xù)也有開源的計(jì)劃，所以我們?cè)趹?yīng)用中都使用了DorisDB作為OLAP分析引擎。

2.高并發(fā)：DorisDB vs Druid

線上實(shí)際環(huán)境，以寬表模式對(duì)Druid和DorisDB進(jìn)行了高并發(fā)的壓力測(cè)試。Druid集群的QPS可以達(dá)到600-700左右，平均響應(yīng)時(shí)間100ms左右，最大響應(yīng)時(shí)間300ms左右。相同規(guī)模的DorisDB集群，QPS可以達(dá)到1500-2000，平均響應(yīng)時(shí)間在50ms左右，最大響應(yīng)時(shí)間在100ms左右。

（壓力測(cè)試下Druid并發(fā)量）

（壓力測(cè)試下DorisDB并發(fā)量）

此外，我們額外對(duì)DorisDB的Join模式進(jìn)行了高并發(fā)的壓力測(cè)試，QPS可以到200-300，平均響應(yīng)時(shí)間470ms。可以看出即使在Join模式的復(fù)雜查詢場(chǎng)景下，DorisDB的并發(fā)性能還依舊維持在一個(gè)不錯(cuò)的水準(zhǔn)。

3.其他指標(biāo)

如下表所示，我們也對(duì)其他方面的指標(biāo)進(jìn)行了比較：

四、DorisDB在貝殼的應(yīng)用

目前貝殼的DorisDB集群使用35臺(tái)物理機(jī)（80core、192GB內(nèi)存、3TB SSD），部署了35 BE，3 FE。支持了如指標(biāo)平臺(tái)、可視化報(bào)表平臺(tái)、典型業(yè)務(wù)場(chǎng)景等多個(gè)應(yīng)用。

1.指標(biāo)平臺(tái)

1）高QPS指標(biāo)查詢

通過DorisDB強(qiáng)大的并發(fā)能力支撐以往Druid所不能滿足的高QPS場(chǎng)景。如房屋經(jīng)紀(jì)人業(yè)績考核時(shí)段，QPS會(huì)瞬間從幾十飆升到3000。以往使用Durid應(yīng)對(duì)這類瞬時(shí)高壓場(chǎng)景沒有很好的解決辦法，集群會(huì)不停告警乃至宕機(jī)。使用DorisDB支撐的指標(biāo)平臺(tái)就能很好的解決這個(gè)問題。

2）可自動(dòng)更新的物化視圖

DorisDB有非常好的物化視圖能力。對(duì)慢查詢指標(biāo)通過rollup聚合，在查詢時(shí)可以自動(dòng)命中物化視圖，自動(dòng)路由，加速整個(gè)查詢。同時(shí)物化視圖支持自動(dòng)更新，當(dāng)明細(xì)表發(fā)生變化時(shí)，物化視圖自動(dòng)刷新聚合結(jié)果。

3）實(shí)時(shí)的大屏指標(biāo)

原有的實(shí)時(shí)指標(biāo)是通過ClickHouse來支持的，但是需要建大量的視圖。ClickHouse物化視圖不支持自動(dòng)路由，在查詢時(shí)需要指定對(duì)應(yīng)的物化視圖表名字。而且ClickHouse對(duì)Update的支持也非常有限，查詢最新的記錄需要額外的函數(shù)支持，不符合標(biāo)準(zhǔn)的SQL語法?？傮w來說使用ClickHouse來計(jì)算實(shí)時(shí)指標(biāo)，實(shí)現(xiàn)過程非常復(fù)雜。通過DorisDB來支持實(shí)時(shí)指標(biāo)場(chǎng)景，能自動(dòng)對(duì)指標(biāo)進(jìn)行實(shí)時(shí)更新，只需要?jiǎng)?chuàng)建對(duì)應(yīng)的物化視圖即可，無需額外的任何操作就可以指標(biāo)的實(shí)時(shí)更新。

4）更靈活的數(shù)據(jù)模型

DorisDB同時(shí)也具備非常強(qiáng)的單表查詢能力和多表Join能力，可以支持寬表模式和多表Join模式。在應(yīng)對(duì)部分靈活指標(biāo)，如前文提到的經(jīng)紀(jì)人組織架構(gòu)變更場(chǎng)景，基于DorisDB就無需構(gòu)建寬表。使用在線Join的方式，當(dāng)維度發(fā)生變動(dòng)的時(shí)候，更新維度表重新進(jìn)行關(guān)聯(lián)查詢即可。

2.奧丁可視化平臺(tái)

此前我們基于MySQL做了大量的報(bào)表，如市場(chǎng)管理看板等。隨著數(shù)據(jù)量增大，數(shù)據(jù)量達(dá)到千萬級(jí)別MySQL已經(jīng)完全不能支撐。目前已將這些可視化系統(tǒng)報(bào)表全部遷移到DorisDB上。由于DorisDB對(duì)MySQL協(xié)議的支持，整個(gè)遷移的過過程比較平滑，只需要很少的工作量。

3.典型業(yè)務(wù)

原有的典型業(yè)務(wù)如A/B試驗(yàn)平臺(tái)、交易平臺(tái)、風(fēng)控平臺(tái)、直播中臺(tái)等，之前是基于ClickHouse和Apache Doris構(gòu)建的?，F(xiàn)在我們已經(jīng)開始將這些業(yè)務(wù)應(yīng)用逐步遷移至DorisDB。此外，后續(xù)構(gòu)建的新應(yīng)用，如用戶行為分析等，我們也會(huì)基于DorisDB來進(jìn)行構(gòu)建。

下圖是直播中臺(tái)從Apache Doris遷移到DorisDB后的查詢效率對(duì)比?？梢钥吹讲樵冃示谐杀兜奶嵘?，在數(shù)據(jù)量大的情況下（全量表）性能提升尤為明細(xì)，性能提升均在7倍以上。

（直播平臺(tái)使用DorisDB后，所有查詢的延時(shí)都顯著降低）

寫在最后

在近半年的使用過程中，從整體來看DorisDB在穩(wěn)定性和查詢性能上要優(yōu)于Apache doris。寬表性能和ClickHouse不相上下，多表Join能力要?jiǎng)儆贑lickHouse。DorisDB在保持甚至超過ClickHouse性能的同時(shí)，極大降低了我們的運(yùn)維壓力，簡化了數(shù)據(jù)開發(fā)的鏈路。

DorisDB對(duì)hive外表的支持也給我們很大的想象空間，尤其是一些Ad hoc查詢場(chǎng)景?，F(xiàn)在我們的小查詢用Spark SQL，大的查詢用hive或者是presto。后續(xù)使用DorisDB來分擔(dān)一些熱查詢的流量，整體的查詢效率也可以得到進(jìn)一步的提升。使用DorisDB查詢ElasticSearch外表也在我們下一步的規(guī)劃中。

后續(xù)我們會(huì)將DorisDB覆蓋到更多的業(yè)務(wù)場(chǎng)景，使用DorisDB逐步替代Druid、Clickhouse、Kylin等其他分析引擎，來構(gòu)建我們?nèi)珗?chǎng)景統(tǒng)一的極速OLAP分析平臺(tái)。

DorisDB團(tuán)隊(duì)的同學(xué)支持也十分給力，在此表示感謝。

songjy