貝殼找房作為“科技驅動的新居住服務商”，致力于推進居住服務產業(yè)數(shù)字化、智能化進程，通過助力優(yōu)質服務者，為三億中國家庭提供包括二手房、新房、租賃、裝修等全方位的高品質、高效率居住服務。

　　貝殼大數(shù)據平臺部構建和支撐了全集團多個場景應用，覆蓋的業(yè)務線多，業(yè)務復雜度高，因此對數(shù)據分析平臺的要求也非常高。OLAP平臺需要支撐如指標分析、Ad hoc探索性分析、可視化報表等常規(guī)業(yè)務，還需要支持如用戶行為分析、風控、DMP等典型業(yè)務。OLAP平臺需要適配不同類型、負載以及場景的分析要求，為此大數(shù)據平臺部需要同時運維的平臺上已經存在有6、7種不同的分析引擎。

　　從2021年開始通過引入DorisDB，作為主要的分析引擎開始了公司大數(shù)據分析引擎的整合。在指標平臺、報表平臺上基本實現(xiàn)了通過一個組件(DorisDB)來適配多樣的數(shù)據分析場景。通過DorisDB構建一站式全場景的極速數(shù)據分析平臺，提升了數(shù)據分析效率，降低了運維復雜度，充分釋放了數(shù)據價值。

　　“作者：肖贊貝殼找房(北京)科技有限公司OLAP平臺負責人，基礎平臺中心大數(shù)據平臺部架構師。”

　　一、業(yè)務背景

　　貝殼是一個典型的產業(yè)互聯(lián)網公司，OLAP平臺是我們數(shù)字化運營的基石，在數(shù)據平臺中占據著非常重要的位置。首先OLAP平臺需要支撐集團的經營管理決策，需要將各種業(yè)務流程中的關鍵指標抽象出來，在OLAP平臺上進行實現(xiàn)。其次是探索性分析，OLAP平臺需要支持前線的業(yè)務員的探索性分析。再次是可視化報表，即常規(guī)的固定報表業(yè)務，需要OLAP引擎有支持大規(guī)模并發(fā)請求的能力。最后是典型業(yè)務如用戶行為分析、用戶轉換漏斗、用戶畫像、用戶風控，交易等業(yè)務的支撐。下面以指標臺和可視化報表平臺為例對貝殼的業(yè)務現(xiàn)狀做一些簡要的介紹：

　　1.指標平臺

　　指標平臺作為全集團多場景的統(tǒng)一指標管理平臺，提供了以下功能：

　　·對外提供統(tǒng)一的API

　　·指標統(tǒng)一定義，口徑統(tǒng)一管理

　　·實時指標查詢

　　前期使用Apache Kylin支持匯總指標查詢。隨著明細查詢的需求增加，又引入了Druid、ClickHouse和Apache Doris等多個組件。

　　目前應用情況：

　　·上萬級別指標應用

　　·幾千萬調用/天

　　·TP99查詢在3秒以內

　　2.可視化報表平臺

　　運營人員可以在可視化報表平臺上，基于Hive表或指標來創(chuàng)建自助報表�；�于指標創(chuàng)建報表時，通過指標平臺將請求轉化為SQL語句，大部分使用Impala執(zhí)行查詢。

　　目前應用情況：

　　·活躍報表數(shù)千張

　　·每天數(shù)十萬次調用

　　二、業(yè)務痛點

　　引入不同的引擎來解決不同場景的問題，雖然可以滿足大部分業(yè)務的需求，同時也會帶來其它的問題。總結主要有以下四點：

　　1.歷史數(shù)據Update支持差

　　由于貝殼大部分的業(yè)務場景都需要對數(shù)據進行更新操作。如果是離線指標通過批量的方式處理，但實時指標就需要實時的對歷史數(shù)據進行更新。

　　例如在經紀人帶看場景中，某些帶看記錄，如果觸發(fā)了風控規(guī)則，會被判定為無效帶看記錄，數(shù)據狀態(tài)就會發(fā)生變更。再比如新房交易流程，新房記錄的狀態(tài)需要在報備、帶看、簽約、成交直接互相流轉。整個業(yè)務流程都需要對新房狀態(tài)進行在線更新。

　　Druid作為原架構中的主要分析引擎，不支持Update功能，只能用于對離線數(shù)據進行指標分析，無法支持實時指標計算。ClickHouse雖然提供了Update和Delete兩個mutation操作，但是修改的代價比較大。經常積累過量mutation無法完成數(shù)據更新，而且導致了多次線上ClickHouse集群整體宕機。另外，由于mutation是一個異步的線程，所以并不能保證Update的數(shù)據實時可見，從而指標的實時性也無法得到保障。

　　2.多表Join功能的支持能力差

　　平臺現(xiàn)有的OLAP引擎(Kylin、Druid、ClickHouse)多表Join時的性能都比較差，甚至不支持多表Join。以前通常只能采用寬表形式來構建數(shù)據模型。但貝殼是一個線上線下結合產業(yè)互聯(lián)網公司，一個典型的場景是有經紀人經常在門店中間跳動。在計算最新的業(yè)績，或者計算獎金指標的時候，就需要去關注組織架構變動。使用寬表模型的話，只要維度發(fā)生變化，就需要重刷整個寬表，導致有些指標刷新的時間過久，數(shù)據時效性就會變差。

　　現(xiàn)有的引擎Druid雖然有l(wèi)ookup表的能力，但經過實際測試后性能不佳。Apache Kylin實際上也不支持Join，多表的Join需要通過在cube構建的時候底層打成寬表來實現(xiàn)。ClickHouse只支持本地Hash join的模式，不支持分布式Shuffle join，多數(shù)情況下靈活性受限，性能表現(xiàn)不佳。

　　3.無法同時支持明細與聚合

　　在貝殼指標不僅僅需要給管理人員看匯總指標，如果發(fā)現(xiàn)指標有問題，還需要下鉆到明細，查看導致指標異常的具體原因。隨后根據明細數(shù)據的情況，再采取一系列的管理動作。也就是說，OLAP引擎需要同時具備明細數(shù)據查詢和數(shù)據聚合的能力。由于Apache Kylin、Druid不能較好支持明細數(shù)據查詢，之前只能將聚合后的數(shù)據存儲在Apache Kylin、Druid中，明細數(shù)據存儲在Clickhouse中。沒有把聚合數(shù)據放到Clickhouse是由于Clickhouse的物化視圖是不透明的，對上層的應用程序來說查詢明細的時候需要切換到對應的明細表，操作也比較繁瑣。不論是查詢引擎還是表的切換都需要我們維護額外的查詢代碼邏輯。而且對前端的數(shù)據分析人員也不夠友好，他們需要同時了解明細數(shù)據與聚合數(shù)據不同的存儲位置以及之間的對應關系，增加學習，溝通的成本。

　　4.OLAP引擎較多，運維復雜，用戶學習成本較高

　　目前貝殼的數(shù)據分析平臺中引入了六、七種不同的分析引擎(Impala、Presto、Kylin、Druid、ClickHouse、Hive)。而團隊只有十幾個人，技術棧過多，導致我們對每一種引擎的掌握程度都不夠深，運維壓力非常大，出問題的時候很容易hold不住。

　　特別像ClickHouse的集群，雖然性能很好，但是對運維的要求比較高。ClickHouse集群的分片、副本信息，都是通過靜態(tài)的配置文件的方式進行配置。當整個集群需要擴縮容的時候，就必須通過修改配置文件的方式進行刷新，數(shù)據的均衡都需要運維人員介入。此外ClickHouse通過zookeeper來做副本管理，當集群規(guī)模變大時，副本數(shù)過多會導致zookeeper的壓力變大，集群的穩(wěn)定性也就會相應變差。

　　另一方面，多個引擎對用戶來說學習成本也很高，不同分析系統(tǒng)的SQL語句不一致，每一種都需要額外的學習成本。

　　三、DorisDB與其它OLAP引擎的比較

　　為解決以上問題，從今年開始我們引入了DorisDB，逐步替換之前的分析引擎，實現(xiàn)OLAP平臺多業(yè)務場景的查詢引擎統(tǒng)一化。

　　主要因為DorisDB具備以下特性：

　　·MPP架構+高效列式存儲引擎

　　·高性能、高可用、高彈性

　　·標準ANSI SQL支持

　　-支持多表Join

　　-支持MySQL協(xié)議

　　·支持預聚合

　　-支持物化視圖

　　-支持預聚合結果自動更新

　　·支持數(shù)據高效的批量導入、實時導入

　　·支持數(shù)據的實時更新

　　我們對DorisDB與其他OLAP引擎做了全面的對比測試，對比項包括ClickHouse、Duird和Apache Doris。測試環(huán)境配置信息如下：

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

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

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

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

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

　　(寬表模式，不限制max_threads)

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

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

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

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

　　(壓力測試下Druid并發(fā)量)

　　(壓力測試下DorisDB并發(fā)量)

　　此外，我們額外對DorisDB的Join模式進行了高并發(fā)的壓力測試，QPS可以到200-300，平均響應時間470ms�？梢钥闯黾词乖贘oin模式的復雜查詢場景下，DorisDB的并發(fā)性能還依舊維持在一個不錯的水準。

　　3.其他指標

　　如下表所示，我們也對其他方面的指標進行了比較：

　　四、DorisDB在貝殼的應用

　　目前貝殼的DorisDB集群使用35臺物理機(80core、192GB內存、3TB SSD)，部署了35 BE，3 FE。支持了如指標平臺、可視化報表平臺、典型業(yè)務場景等多個應用。

　　1.指標平臺

　　1）高QPS指標查詢

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

　　2）可自動更新的物化視圖

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

　　3）實時的大屏指標

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

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

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

　　2.奧丁可視化平臺

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

　　3.典型業(yè)務

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

　　下圖是直播中臺從Apache Doris遷移到DorisDB后的查詢效率對比�？梢钥吹讲樵冃�率均有成倍的提升，在數(shù)據量大的情況下(全量表)性能提升尤為明細，性能提升均在7倍以上。

　　(直播平臺使用DorisDB后，所有查詢的延時都顯著降低)

　　寫在最后

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

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

　　后續(xù)我們會將DorisDB覆蓋到更多的業(yè)務場景，使用DorisDB逐步替代Druid、Clickhouse、Kylin等其他分析引擎，來構建我們全場景統(tǒng)一的極速OLAP分析平臺。

　　DorisDB團隊的同學支持也十分給力，在此表示感謝。