近年來，眾安保險致力于加速數據價值向業務價值轉化，在“互聯?+保險?融”的雙輪驅動下，誕生了數字化轉型中專門針對業務數據管理和分析的系統產品——集智。

依托豐富的可視化圖表組件以及底層的?數據處理能?，集智實現了零代碼拖拽式分析與億級數據的秒級響應。?前在眾安內部，數字?活、健康險、?融、直營、?險各個業務線，以及 HR、運管、?控等中后臺部門，超過 3000 ?都在使?集智平臺，平均?活可達 2000+，提升超過 50% 的數據分析效率，降低了公司 40% 的??成本。

本文將以眾安集智平臺基于極速 MPP 分析型數據庫系統 StarRocks 的應用實踐，講解集智平臺如何解決極速查詢和高并發等數據問題，提升整體的數據支持能力和市場競爭力。

一、業務背景

一款好的數據分析產品離不開底層的數據引擎，集智平臺的??使?場景對底層的數據架構提出了不同的要求

• 可視化分析→需要有豐富的函數庫?持不同類型圖表的數據計算；

• 交互式分析→需要分析結果的快速響應來保障?戶流暢的分析思路；

• 多維透視分析→需要?數據量的明細數據來?撐不同維度的篩選和下鉆；

• 實時數據分析→需要?持數據的實時寫?、實時查詢。

針對上述的?個需求，我們在平臺建設的初期選?了 ClickHouse 作為底層統一的 OLAP 引擎，數據鏈路如下：

離線的數據會通過 DataX 統一采集到 MaxCompute 或 Hive 數倉，在離線數倉內部完成數據 ETL 的?作，數據加?完成之后，再次經由 DataX 輸出到 ClickHouse 中，ClickHouse 中的數據直接提供給看板或者第三?系統做數據查詢。

實時的數據會通過 Binlog 監聽或者?志采集?具同步到 Kafka，再經由 Flink 完成實時的數據 ETL，最終落到 ClickHouse 中。值得一提的是，這?為了應對一些業務場景中數據需要實時按主鍵更新的需求，我們采?了 ClickHouse 的ReplacingReplicatedMergeTree引擎。由于 ClickHouse 對數據更新操作的?持還不夠成熟，因此在使? Replacing 引擎的過程中遇到很多問題，這也是我們尋求新的 OLAP 技術選型的主要原因。

二、平臺現狀

集智上線后采?的是 ClickHouse，并且已經伴隨業務運?了一段時間，但隨著使?平臺的?戶?漸增多，業務?需要查詢的數據量也越來越?，業務場景變得復雜后，很多特定場景 ClickHouse ?法滿?，?對不同?員??的需求時也遇到一些瓶頸。同時我們分別從業務?戶的?度，以及平臺運維的?度發現了以下問題：

從?戶?度

• 一?分析看板上往往有 6-8 個圖表，這些圖表的查詢請求都是同時發給 ClickHouse 的。但是在多并發的場景，ClickHouse 的查詢性能下降的很快，平時一個 1-2s 左右的查詢，在 8 個并發下就可能把 CPU 吃滿，平均響應時間退化 4 倍左右，降到 8-10s，對看板的??加載時間，以及交互分析的體驗影響都?較?；

• 平臺?持數據表的關聯查詢，但是 ClickHouse 的多表關聯查詢性能?佳，涉及 Join 的查詢往往都需要 10s 以上，數據量?的查詢甚?直接超時?法返回結果。

從運維?度

• ClickHouse不?持事務性的 DDL 與 DML 操作，?且多副本模式的元數據管理強依賴于 ZooKeeper，表結構變更時常常出現不同副本之間元數據不一致的問題，往往定位到最后都是 ZooKeeper 的原因，排查、運維的成本都?較?；

• 隨著數據量的增多，集群需要擴容時，ClickHouse缺少?動的 Resharding 機制，橫向擴容時需要借助第三??具或者?動 Reshard，成本?較?。

針對前?提到的實時場景，我們在使? ClickHouse 的 Replacing 引擎中也遇到一些痛點：

• 查詢慢，Replacing 引擎使?的是 Merge-On-Read 的模式，數據寫?時保存多個版本，在查詢時需要指定 FINAL 關鍵字進?去重取出最新版本的數據。這導致對于 Replacing 引擎表的查詢，SQL 中的謂詞?法下推，同時在低版本的 ClickHouse 中，對于 FINAL 語義的查詢也不?持多線程處理，?乎每次查詢都需要單線程掃描全表數據，涉及 Replacing 引擎的查詢響應時間往往在 10s 以上；

• Replacing 引擎只?持數據的更新，并不?持數據的刪除。對于 Delete 操作，當前的做法是通過額外字段來標記當前數據是否已經被刪除，同時借助 TTL 功能來定時清除已經被刪除的數據。這樣一??需要額外的定制處理，另一??新增的標記字段進一步拖慢了查詢的性能；

• Replacing 引擎只能對同一分?上同一分區的數據去重，這意味著我們在設計表分區時，以及寫?數據時，都需要做??的處理，增加了開發的成本。

上?描述的問題中，有一些涉及 ClickHouse 底層的缺陷，有一些場景利? ClickHouse 提供的其他引擎或者 MaterializedView 等特性可以做一些定制的優化，但是掣肘于平臺分析查詢場景的多樣性，我們很難做一些通?性的優化。基于這樣的情況，我們決定需求新的 OLAP 技術選型。

三、StarRocks comes to the rescue

StarRocks 是新一代 MPP 型 OLAP 分析引擎。我們通過調研發現，對于許多遇到的痛點，StarRocks 都提供了對應的解決?案：

• ?持多并發查詢，部分場景可以達到1 萬以上 QPS；

• ?持 Shuffle Join，Colocate Join 等多種分布式 Join ?式，多表關聯性能更優；

• ?持事務性的 DDL 與 DML 操作，兼容 MySQL 協議；

• FE、BE 架構簡單，不依賴外部組件，運維更加簡單；

• 數據?動均衡，集群隨業務增??平擴展?便。

對于實時的場景，StarRocks 在 1.19 版本發布了Primary Key模型。對? ClickHouse 的 Replacing 引擎與 StarRocks ??的 Unique Key 模型，Primary Key 模型通過在內存中維護主鍵索引，?持頻繁實時更新的同時，保證同一個主鍵下僅存在一條記錄，解決了 Merge-on-Read ?式讀取時在線合并，并且謂詞?法下推和索引失效的問題。通過犧牲微?的寫?性能和內存占?提升了查詢的性能，?常符合我們實時數倉的場景。

調研之后，我們也對 StarRocks 和 ClickHouse，使?SSB數據集做了相應的性能對?測試。一共使?到四臺 8c32g 的機器：StarRocks 1FE/4BE 混部，ClickHouse 兩分?雙副本。StarRocks 使?的版本是 2.1.0，ClickHouse 使?的版本是 21.9.5。測試中為了屏蔽掉系統緩存的影響，對于?并發的場景，每次查詢前都會通過往 drop_cache ?件中寫?來清除緩存。

測試的結果驗證了 StarRocks 在多并發與多表關聯場景下強悍的性能，同時也發現了?前 StarRocks 不?的一些地?：

• 單表?并發的場景，除個別 SQL 外，StarRocks 的查詢速度與 ClickHouse 基本持平，但是 StarRocks 的 CPU 負載偏低，是 ClickHouse 的 25%~50%；

• 單表多并發的場景，除個別 SQL 外，StarRocks 的平均查詢速度? ClickHouse 快1.8倍；

• 多表關聯?并發的場景，StarRocks 平均? ClickHouse 快1.8倍；

• 多表關聯多并發的場景，StarRocks 平均? ClickHouse 快8倍；

• 數據實時寫?實時查詢的場景，不同的查詢場景下，StarRocks 的 Primary Key 模型查詢速度? ClickHouse 的 Replacing 引擎快3~10倍，且查詢性能較 ClickHouse 更加穩定（Replacing 引擎由于后臺不斷地 Merge 操作，查詢的性能會隨底表數據量的起伏對應地波動）；

• 數據批量導?的場景，我們?較了不同批次??下的寫?性能，StarRocks 的寫?速率平均? ClickHouse 要慢20%~30%左右。

基于上述的?點考慮與測試的結果，我們決定在平臺的 OLAP 架構中引? StarRocks，并優先在實時數倉的場景落地應?。

在集智平臺的實時數倉?，業務庫的 Binlog 數據與?志、事件數據會?先經由采集?具發送到 Kafka ?，中間通過 Flink 完成初步的數據清洗、轉換，再次輸出到 Kafka 做為 DWD/DIM 層。這一層的數據再次經過 Flink 處理，完成數據的關聯、聚合，最后在 DWS 層?成不同主題的多維度明細寬表與指標匯總寬表。DWS 層的寬表會同時實時同步在 OLAP 引擎?，通過實時看板提供給業務同學查詢。

實時數倉的場景對 OLAP 引擎提出了許多挑戰，也是之前我們基于 ClickHouse 架構遇到的一?難題場景

• 業務同學需要根據實時看板隨時調整投放策略，要求看板數據實時更新，快速響應；

• 實時看板的查看頻率?離線看板普遍?出 3~5 倍，并且查詢結果?法做緩存處理；

• 為了聯合查詢不同主題的數據，DWS 層的寬表之間往往還需要在 OLAP 層做關聯操作；

• 為了滿?多維分析的需求，落在 OLAP 層的是明細數據，數據量?；

• 為了保障數據的可維護性與數據快速修正的能?，這些明細數據需要?持按主鍵更新。

本就不擅?多并發與多表關聯查詢的 ClickHouse，再疊上 Replacing 引擎的 Debuff，導致許多實時的看板常常需要??秒才能返回查詢結果，不能很好地滿?業務的需求。同時給集群的 CPU 負載也造成了不?的壓?，有時會造成集群整體查詢性能的波動。

為此，我們計劃使? StarRocks 的 Primary Key 模型來替換 ClickHouse 的 Replacing 引擎，針對線上的實時看板，我們模擬了真實的場景，選取了一個 4 張寬表關聯的復雜查詢，對兩種不同的引擎做了對?測試，結果如下：

從結果中可以看到，在沒有并發的場景下，StarRocks 的查詢速度是 ClickHouse 的 2 倍左右，在多并發的場景下，StarRocks 的查詢速度是 ClickHouse 的 3~3.5 倍左右。

除了查詢性能提升之外，Primary Key 模型也可以?持數據的刪除，并且不?數據開發額外地維護分?與分區的寫?規則，降低了數據開發的成本。

四、集智平臺集成 StarRocks 的功能應用

為了提升集智在查詢加載??的性能，同時將 StarRocks 極速查詢及?并發相關能?更好的賦能給業務同學，集智在產品側深度集成了 StarRocks，?戶可以在平臺上快速完成一站式的實時看板搭建。

在集智平臺中，搭建一個分析看板前需要先創建數據模型，當數據開發同學?對業務?較為復雜或查詢量較?的分析需求時，可在創建數據模型時選擇 StarRocks 的優化?式，除了基礎的索引字段、數據分布字段以及時間分區等字段外，還可選擇對應的模型引擎以及填寫數據保留的時?。

實時模型創建成功后，?戶可以在模型的詳情?拿到對應的 StarRocks表連接信息，以及?動?成的Flink SQL Sink 語句。

之后，?戶可以在平臺的數據 ETL 模塊新建一個實時 Flink 任務，往對應的實時模型中寫?數據。

數據寫?模型之后，?戶就可以在搭建看板時使?了，可以在模型上做一些字段的數據格式調整、字段編輯、基于原始字段新增復合字段等操作，以及圖表樣式的調整，滿?業務?不同場景下的業務?徑與展?需求。

看板搭建完成后可以進?發布操作?成一個固定鏈接，就可以提供給業務同學使?啦。

五、集成 StarRocks 對于業務的提升

以保險產品中線上渠道投放場景為例，當保險產品開始對外發售前后，市場?員會將產品投放到多個渠道進?推?曝光，通過經營的核?報表實時核算每個渠道的投放成本以及其對應的 ROI，根據數據表現情況實時調整投放策略，控制渠道營銷流程中的獲客單價和投放費?。

因此數據反饋的快慢也會決定業務?員在定位問題、調整策略等事件上是否占據最佳時機。

?集智使? StarRocks 的模型作為實時報表的底層數據?撐后，在業務場景中的數據查詢表現會怎么樣，以下為真實場景測試結果：

1）在報表數據加載速度??：過去業務?打開報表需要加載10s+，常常因為打開速度過慢致使業務偶爾在關鍵節點上?法及時得到事故反饋，導致投放成本難以控制，嚴重影響后續的投放策略；

?使? StarRocks 后加載速度只需3s左右，超強的響應速度讓業務同學可以很快抓準業務實時的變動節點，及時對活動策略做出調整優化。

2）在查詢數據量?持??：過去使? ClickHouse 的實時更新模型只能?持千萬級數據量，更?數據量的實時更新+查詢常常超時，嚴重影響業務進展，也會因此錯過一些關鍵時機；

?使? StarRocks 后可?持近億級數據量，能夠適配更多?數據量下的業務場景，同時也能更好的維持業務穩定性，增加了業務同學對平臺的信任和粘性，極?的提?了?產效率。

六、總結與規劃

從以上的調研和測試結果來看，StarRocks 的單表查詢性能和 ClickHouse 不相上下，在多并發與多表關聯查詢的場景下性能明顯優于 ClickHouse，特別是針對實時數倉的?頻更新場景，StarRocks 的 Primary Key 模型能很好地解決 ClickHouse 的 Replacing 引擎遇到的一些痛點。此外，StarRocks 的 DDL/DML和數據導入具備事務保證，兼容 MySQL 協議，集群相對 ClickHouse 也更容易運維，對于研運同學來說更加友好。

之后除了在實時數倉場景的應?落地之外，眾安也計劃在其他場景中逐步推進 StarRocks 的應?，例如以下場景：

• 離線場景的數據也逐步接? StarRocks，?統一的 OLAP 引擎完成全場景，批流一體的數據分析；

• 探索 StarRocks 作為輕量級數倉，以及統一查詢引擎的能?；

• 探索 StarRocks 在?戶?為數據分析、?戶畫像等其他業務場景中的應?。

線上直播

4?13?眾安將與 StarRocks舉辦一場線上聯合直播，直播中會詳細講解在集智平臺落地 StarRocks 的過程及經驗。掃描下?海報?維碼，提前鎖定直播名額！

關于眾安保險

作為國內?家互聯?保險公司，眾安保險是一家以技術創新帶動?融發展的?融科技公司。區別于傳統保險公司的運營模式，眾安保險業務流程全程在線，全國均不設任何分?機構，完全通過互聯?進?承保和理賠服務。目前已服務超5億用戶，2021 年總保費突破 200 億元，同比增長 21.9%。

由“保險+科技”雙引擎驅動，眾安保險專注于應用新技術重塑保險價值鏈，圍繞健康、數字生活、消費金融、汽車四大生態，以科技服務新生代，為其提供個性化、定制化、智能化的新保險。

在科技賦能保險的同時，眾安保險將經過業務驗證的科技對外輸出，海外合作伙伴包括日本歷史最悠久的財產保險公司 SOMPO、東南亞領先的 O2O 平臺Grab、新加坡最大的綜合保險機構 Income 等知名企業。