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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

·TP99查詢?cè)?秒以內(nèi)

2.可視化報(bào)表平臺(tái)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

-支持多表Join

-支持MySQL協(xié)議

·支持預(yù)聚合

-支持物化視圖

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

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

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

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

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?？梢钥闯黾词乖贘oin模式的復(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é)支持也十分給力,在此表示感謝。