貝殼找房 x DorisDB：全新統一的極速OLAP平臺實踐

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

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

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

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

　　一、業務背景

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

　　1.指標平臺

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

　　·對外提供統一的API

　　·指標統一定義，口徑統一管理

　　·實時指標查詢

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

　　目前應用情況：

　　·上萬級別指標應用

　　·幾千萬調用/天

　　·TP99查詢在3秒以內

　　2.可視化報表平臺

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

　　目前應用情況：

　　·活躍報表數千張

　　·每天數十萬次調用

　　二、業務痛點

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

　　1.歷史數據Update支持差

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　·標準ANSI SQL支持

　　-支持多表Join

　　-支持MySQL協議

　　·支持預聚合

　　-支持物化視圖

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

　　·支持數據高效的批量導入、實時導入

　　·支持數據的實時更新

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

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

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

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

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

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

　　(寬表模式，不限制max_threads)

　　在多表Join模式下，對比了DorisDB和Apache Doris的表現。整體上DorisDB比Apache Doris有5-10倍的性能優勢。

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

　　2.高并發：DorisDB vs Druid

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

　　(壓力測試下Druid并發量)

　　(壓力測試下DorisDB并發量)

　　此外，我們額外對DorisDB的Join模式進行了高并發的壓力測試，QPS可以到200-300，平均響應時間470ms。可以看出即使在Join模式的復雜查詢場景下，DorisDB的并發性能還依舊維持在一個不錯的水準。

　　3.其他指標

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

　　四、DorisDB在貝殼的應用

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

　　1.指標平臺

　　1）高QPS指標查詢

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

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

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

　　3）實時的大屏指標

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

　　4）更靈活的數據模型

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

　　2.奧丁可視化平臺

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

　　3.典型業務

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

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

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

　　寫在最后

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

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

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

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