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

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

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

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

　　一、業(yè)務(wù)背景

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

　　1.指標(biāo)平臺

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

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

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

　　·實(shí)時指標(biāo)查詢

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

　　目前應(yīng)用情況：

　　·上萬級別指標(biāo)應(yīng)用

　　·幾千萬調(diào)用/天

　　·TP99查詢在3秒以內(nèi)

　　2.可視化報表平臺

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

　　目前應(yīng)用情況：

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

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

　　二、業(yè)務(wù)痛點(diǎn)

　　引入不同的引擎來解決不同場景的問題，雖然可以滿足大部分業(yè)務(wù)的需求，同時也會帶來其它的問題?？偨Y(jié)主要有以下四點(diǎn)：

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

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

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

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

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

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

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

　　3.無法同時支持明細(xì)與聚合

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

　　4.OLAP引擎較多，運(yùn)維復(fù)雜，用戶學(xué)習(xí)成本較高

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

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

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

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

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

　　主要因?yàn)镈orisDB具備以下特性：

　　·MPP架構(gòu)+高效列式存儲引擎

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

　　·標(biāo)準(zhǔn)ANSI SQL支持

　　-支持多表Join

　　-支持MySQL協(xié)議

　　·支持預(yù)聚合

　　-支持物化視圖

　　-支持預(yù)聚合結(jié)果自動更新

　　·支持?jǐn)?shù)據(jù)高效的批量導(dǎo)入、實(shí)時導(dǎo)入

　　·支持?jǐn)?shù)據(jù)的實(shí)時更新

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

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

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

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

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

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

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

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

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

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

　　3.其他指標(biāo)

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

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

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

　　1.指標(biāo)平臺

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

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

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

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

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

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

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

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

　　2.奧丁可視化平臺

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

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

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

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

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

　　寫在最后

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

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

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

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

特別提醒：本網(wǎng)信息來自于互聯(lián)網(wǎng)，目的在于傳遞更多信息，并不代表本網(wǎng)贊同其觀點(diǎn)。其原創(chuàng)性以及文中陳述文字和內(nèi)容未經(jīng)本站證實(shí)，對本文以及其中全部或者部分內(nèi)容、文字的真實(shí)性、完整性、及時性本站不作任何保證或承諾，并請自行核實(shí)相關(guān)內(nèi)容。本站不承擔(dān)此類作品侵權(quán)行為的直接責(zé)任及連帶責(zé)任。如若本網(wǎng)有任何內(nèi)容侵犯您的權(quán)益，請及時聯(lián)系我們，本站將會在24小時內(nèi)處理完畢。