貝殼找房作為“科技驅動的新居住服務商”，致力於推進居住服務產業數字化、智慧化程序，透過助力優質服務者，為三億中國家庭提供包括二手房、新房、租賃、裝修等全方位的高品質、高效率居住服務。
貝殼大資料平臺部構建和支撐了全集團多個場景應用，覆蓋的業務線多，業務複雜度高，因此對資料分析平臺的要求也非常高。OLAP平臺需要支撐如指標分析、Ad hoc探索性分析、視覺化報表等常規業務，還需要支援如使用者行為分析、風控、DMP等典型業務。OLAP平臺需要適配不同型別、負載以及場景的分析要求，為此大資料平臺部需要同時運維的平臺上已經存在有6、7種不同的分析引擎。
從2021年開始透過引入StarRocks，作為主要的分析引擎開始了公司大資料分析引擎的整合。在指標平臺、報表平臺上基本實現了透過一個元件（StarRocks）來適配多樣的資料分析場景。透過StarRocks構建一站式全場景的極速資料分析平臺，提升了資料分析效率，降低了運維複雜度，充分釋放了資料價值。
“ 作者：肖贊
貝殼找房（北京）科技有限公司OLAP平臺負責人，基礎平臺中心大資料平臺部架構師 ”
業務背景
貝殼是一個典型的產業網際網路公司，OLAP平臺是我們數字化運營的基石，在資料平臺中佔據著非常重要的位置。首先OLAP平臺需要支撐集團的經營管理決策，需要將各種業務流程中的關鍵指標抽象出來，在OLAP平臺上進行實現。其次是探索性分析，OLAP平臺需要支援前線的業務員的探索性分析。再次是視覺化報表，即常規的固定報表業務，需要OLAP引擎有支援大規模併發請求的能力。最後是典型業務如使用者行為分析、使用者轉換漏斗、使用者畫像、使用者風控，交易等業務的支撐。下面以指標臺和視覺化報表平臺為例對貝殼的業務現狀做一些簡要的介紹：
指標平臺
指標平臺作為全集團多場景的統一指標管理平臺，提供了以下功能：
- 對外提供統一的API
- 指標統一定義，口徑統一管理
- 實時指標查詢
前期使用Apache Kylin支援彙總指標查詢。隨著明細查詢的需求增加，又引入了Druid、ClickHouse和Apache Doris等多個元件。
目前應用情況：
- 上萬級別指標應用
- 幾千萬呼叫/天
- TP99查詢在3秒以內
視覺化報表平臺
運營人員可以在視覺化報表平臺上，基於Hive表或指標來建立自助報表。基於指標建立報表時，透過指標平臺將請求轉化為SQL語句，大部分使用Impala執行查詢。
目前應用情況：
- 活躍報表數千張
- 每天數十萬次呼叫
業務痛點
引入不同的引擎來解決不同場景的問題，雖然可以滿足大部分業務的需求，同時也會帶來其它的問題。總結主要有以下四點：
歷史資料Update支援差
由於貝殼大部分的業務場景都需要對資料進行更新操作。如果是離線指標透過批次的方式處理，但實時指標就需要實時的對歷史資料進行更新。
例如在經紀人帶看場景中，某些帶看記錄，如果觸發了風控規則，會被判定為無效帶看記錄，資料狀態就會發生變更。再比如新房交易流程，新房記錄的狀態需要在報備、帶看、簽約、成交直接互相流轉。整個業務流程都需要對新房狀態進行線上更新。
Druid作為原架構中的主要分析引擎，不支援Update功能，只能用於對離線資料進行指標分析，無法支援實時指標計算。ClickHouse雖然提供了Update和Delete兩個mutation操作，但是修改的代價比較大。經常積累過量mutation無法完成資料更新，而且導致了多次線上ClickHouse叢集整體宕機。另外，由於mutation是一個非同步的執行緒，所以並不能保證Update的資料實時可見，從而指標的實時性也無法得到保障。
多表Join功能的支援能力差
平臺現有的OLAP引擎(Kylin、Druid、ClickHouse)多表Join時的效能都比較差，甚至不支援多表Join。以前通常只能採用寬表形式來構建資料模型。但貝殼是一個線上線下結合產業網際網路公司，一個典型的場景是有經紀人經常在門店中間跳動。在計算最新的業績，或者計算獎金指標的時候，就需要去關注組織架構變動。使用寬表模型的話，只要維度發生變化，就需要重刷整個寬表，導致有些指標重新整理的時間過久，資料時效性就會變差。
現有的引擎Druid雖然有lookup表的能力，但經過實際測試後效能不佳。Apache Kylin實際上也不支援Join，多表的Join需要透過在cube構建的時候底層打成寬表來實現。ClickHouse只支援本地Hash join的模式，不支援分散式Shuffle join，多數情況下靈活性受限，效能表現不佳。
無法同時支援明細與聚合
在貝殼指標不僅僅需要給管理人員看彙總指標，如果發現指標有問題，還需要下鑽到明細，檢視導致指標異常的具體原因。隨後根據明細資料的情況，再採取一系列的管理動作。也就是說，OLAP引擎需要同時具備明細資料查詢和資料聚合的能力。由於Apache Kylin、Druid不能較好支援明細資料查詢，之前只能將聚合後的資料儲存在Apache Kylin、Druid中，明細資料儲存在Clickhouse中。沒有把聚合資料放到Clickhouse是由於Clickhouse的物化檢視是不透明的，對上層的應用程式來說查詢明細的時候需要切換到對應的明細表，操作也比較繁瑣。不論是查詢引擎還是表的切換都需要我們維護額外的查詢程式碼邏輯。而且對前端的資料分析人員也不夠友好，他們需要同時瞭解明細資料與聚合資料不同的儲存位置以及之間的對應關係，增加學習，溝通的成本。
OLAP引擎較多，運維複雜，使用者學習成本較高
目前貝殼的資料分析平臺中引入了六、七種不同的分析引擎（Impala、Presto、Kylin、Druid、ClickHouse、Hive）。而團隊只有十幾個人，技術棧過多，導致我們對每一種引擎的掌握程度都不夠深，運維壓力非常大，出問題的時候很容易hold不住。
特別像ClickHouse 的叢集，雖然效能很好，但是對運維的要求比較高。ClickHouse叢集的分片、副本資訊，都是透過靜態的配置檔案的方式進行配置。當整個叢集需要擴縮容的時候，就必須透過修改配置檔案的方式進行重新整理，資料的均衡都需要運維人員介入。此外ClickHouse透過zookeeper來做副本管理，當叢集規模變大時，副本數過多會導致zookeeper的壓力變大，叢集的穩定性也就會相應變差。
另一方面，多個引擎對使用者來說學習成本也很高，不同分析系統的SQL語句不一致，每一種都需要額外的學習成本。
StarRocks 與其它 OLAP 引擎的比較
為解決以上問題，從今年開始我們引入了 StarRocks，逐步替換之前的分析引擎，實現 OLAP 平臺多業務場景的查詢引擎統一化。
主要因為 StarRocks 具備以下特性：
- MPP 架構 + 高效列式儲存引擎
- 高效能、高可用、高彈性
- 標準 ANSI SQL 支援
- 支援多表 Join
- 支援 MySQL 協議
- 支援預聚合
- 支援物化檢視
- 支援預聚合結果自動更新
- 支援資料高效的批次匯入、實時匯入
- 支援資料的實時更新
我們對 StarRocks 與其他 OLAP 引擎做了全面的對比測試，對比項包括 ClickHouse、Duird 和 Apache Doris。測試環境配置資訊如下：
查詢效能：StarRocks vs ClickHouse vs Apache Doris
查詢效能對比測試使用 SSB 測試集，資料量最大的表 lineorder 約60億(scale 1000)。在 ClickHouse 最擅長的寬表模式下，分別在限制執行緒數不超過8，不限制執行緒數兩種情況下對比了 StarRocks 和 Clickhouse 的效能。
在 StarRocks 和 ClickHouse 單節點都使用不超過8個執行緒的情況下，13個查詢中有9個 StarRocks 的效能好於 ClickHouse。
(寬表模式，設定ClickHouse max_threads=8）
不限制ClickHouse執行緒數情況下，13個查詢中有7個 StarRocks 效能好於 ClickHouse。
(寬表模式，不限制max_threads）
在多表 Join 模式下，對比了 StarRocks 和 Apache Doris 的表現。整體上 StarRocks 比 Apache Doris 有5-10倍的效能優勢。
沒有對 Apache Doris 的寬表效能程序測試，是由於在60億的資料量下，StarRocks 可以直接使用 insert into select 語句將資料轉成寬表，Apache Doris 執行相同語句會報 oom。由此也可以看出 StarRocks 在記憶體的管理和執行效率上比 Apache Doris 要好不少。同時也瞭解到 StarRocks 後續也有開源的計劃，所以我們在應用中都使用了 StarRocks 作為 OLAP 分析引擎。
高併發：StarRocks vs Druid
線上實際環境，以寬表模式對 Druid 和 StarRocks 進行了高併發的壓力測試。Druid 叢集的QPS 可以達到600-700左右，平均響應時間100ms左右，最大響應時間300ms左右。相同規模的 StarRocks 叢集，QPS 可以達到1500-2000，平均響應時間在50ms左右，最大響應時間在100ms左右。
（壓力測試下Druid併發量）
（壓力測試下DorisDB併發量）
此外，我們額外對 StarRocks 的 Join 模式進行了高併發的壓力測試，QPS 可以到200-300，平均響應時間470ms。可以看出即使在 Join 模式的複雜查詢場景下，StarRocks 的併發效能還依舊維持在一個不錯的水準。
其他指標
如下表所示，我們也對其他方面的指標進行了比較：
StarRocks 在貝殼的應用
目前貝殼的 StarRocks 叢集使用35臺物理機（80core、192GB記憶體、3TB SSD），部署了35 BE，3 FE。支援瞭如指標平臺、視覺化報表平臺、典型業務場景等多個應用。
指標平臺
1、 高QPS指標查詢
透過 StarRocks 強大的併發能力支撐以往 Druid 所不能滿足的高 QPS 場景。如房屋經紀人業績考核時段，QPS 會瞬間從幾十飆升到3000。以往使用Durid應對這類瞬時高壓場景沒有很好的解決辦法，叢集會不停告警乃至宕機。使用 StarRocks 支撐的指標平臺就能很好的解決這個問題。
2、 可自動更新的物化檢視
StarRocks 有非常好的物化檢視能力。對慢查詢指標透過rollup聚合，在查詢時可以自動命中物化檢視，自動路由，加速整個查詢。同時物化檢視支援自動更新，當明細表發生變化時，物化檢視自動重新整理聚合結果。
3、 實時的大屏指標
原有的實時指標是透過 ClickHouse 來支援的，但是需要建大量的檢視。ClickHouse 物化檢視不支援自動路由，在查詢時需要指定對應的物化視圖表名字。而且 ClickHouse 對 Update 的支援也非常有限，查詢最新的記錄需要額外的函式支援，不符合標準的 SQL 語法。總體來說使用 ClickHouse 來計算實時指標，實現過程非常複雜。透過 StarRocks 來支援實時指標場景，能自動對指標進行實時更新，只需要建立對應的物化檢視即可，無需額外的任何操作就可以指標的實時更新。
4、 更靈活的資料模型
StarRocks 同時也具備非常強的單表查詢能力和多表 Join 能力，可以支援寬表模式和多表Join模式。在應對部分靈活指標，如前文提到的經紀人組織架構變更場景，基於 StarRocks 就無需構建寬表。使用線上Join的方式，當維度發生變動的時候，更新維度表重新進行關聯查詢即可。
奧丁視覺化平臺
此前我們基於 MySQL 做了大量的報表，如市場管理看板等。隨著資料量增大，資料量達到千萬級別 MySQL 已經完全不能支撐。目前已將這些視覺化系統報表全部遷移到 StarRocks上。由於 StarRocks 對 MySQL 協議的支援，整個遷移的過過程比較平滑，只需要很少的工作量。
典型業務
原有的典型業務如A/B試驗平臺、交易平臺、風控平臺、直播中臺等，之前是基於 ClickHouse 和 Apache Doris 構建的。現在我們已經開始將這些業務應用逐步遷移至 StarRocks。此外，後續構建的新應用，如使用者行為分析等，我們也會基於 StarRocks 來進行構建。
下圖是直播中臺從 Apache Doris 遷移到 StarRocks 後的查詢效率對比。可以看到查詢效率均有成倍的提升，在資料量大的情況下（全量表）效能提升尤為明細，效能提升均在7倍以上。
寫在最後
在近半年的使用過程中，從整體來看 StarRocks 在穩定性和查詢效能上要優於 Apache Doris。寬表效能和 ClickHouse 不相上下，多表Join能力要勝於 ClickHouse。StarRocks 在保持甚至超過 ClickHouse 效能的同時，極大降低了我們的運維壓力，簡化了資料開發的鏈路。
StarRocks 對 Hive 外表的支援也給我們很大的想象空間，尤其是一些 Ad hoc 查詢場景。現在我們的小查詢用 Spark SQL，大的查詢用 Hive 或者是 Presto。後續使用 StarRocks 來分擔一些熱查詢的流量，整體的查詢效率也可以得到進一步的提升。使用 StarRocks 查詢ElasticSearch 外表也在我們下一步的規劃中。
後續我們會將 StarRocks 覆蓋到更多的業務場景，使用 StarRocks 逐步替代 Druid、Clickhouse、Kylin 等其他分析引擎，來構建我們全場景統一的極速 OLAP 分析平臺。
