StarRocks存算分離在得物的降本增效實踐

得物技术發表於2024-12-02

一、背景

OLAP引擎在得物的客服、風控、供應鏈、投放、運營、ab實驗等大量業務場景發揮重要作用，在報表、日誌、實時數倉等應用場景都有廣泛的應用。

得物引入和使用OLAP引擎的過程中，每個業務都基於自己的需求選擇當時最適合自己的引擎。現在得物內部同時使用阿里雲上的Hologres、ADB、Clickhouse與ECS自建的開源Clickhouse與StarRocks 5種引擎產品，從業務使用成本和運維維護的角度長遠看都是不利的。

2024年，我們開始向只保留1到2個引擎的方向努力。最近，我們把一套4000+核的業務，最複雜的Clickhouse叢集遷移到了存算分離的自建StarRocks上，成本節約40%，查詢耗時降低一半，單節點不可用導致的叢集不可用耗時從15分鐘減少到了30s。

二、Clickhouse在大資料量下的困境

Clickhouse雖然單機效能首屈一指，但分散式架構存在水平擴充套件性、後設資料管理、資料一致性、join查詢效能等一系列問題。被遷移的這個Clickhouse叢集服務於得物的智慧運營平臺，使用了超過4000核，儲存超過500TB。隨著業務增長，叢集面臨一些實際問題。

物化檢視缺乏透明改寫能力

智慧運營平臺日常需要查詢周/月/季/年 環比/同比，查詢時間跨度長，並且為了加速查詢建立了40+物化檢視。Clickhouse沒有自動的透明物化檢視改寫能力，需要由外部程式碼主動管理、建立物化檢視和改寫SQL去查詢物化檢視。在需要重刷歷史資料時，由外部程式碼管理的物化檢視的重刷尤為複雜。

缺乏離線匯入功能

開源Clickhouse缺少bulkload能力，智慧運營需要每天從離線平臺匯入大量資料到Clickhouse，匯入鏈路存在格式轉換，效率低的問題，並且會佔用大量Clickhouse叢集資源，匯入鏈路的資料產出有時會晚於基線。
圖片

擴容困難

雖然使用了很多物化檢視，但叢集負載仍然開始接近硬體能力上限。業務想要繼續擴容，但面臨了兩個問題：

  1. 垂直擴容沒有空間：叢集使用的Clickhouse單機規格已經是頂配，沒有升配空間。
  2. 水平擴容停機需停機一週：因為Clickhouse水平擴容後為了查詢正確性考慮，已經按指定欄位分桶的表，需要重新匯入資料才能正確的resharding，這個過程需要一週的停服擴容和匯入。

業務方只能搭建了一個小一些的備份叢集，儲存最核心的資料，與主叢集構成雙活來分流部分查詢，來減小主叢集負載，這樣增加了50%+成本。

在得物增加了對StarRocks的研發投入後，智慧運營下定決心基於StarRocks存算分離做POC，並最終順利遷移到自建的StarRocks上。

三、基於StarRocks降本增效

存算分離帶來成本下降

StarRocks 3.0起支援存算分離，在3.3版本已經比較成熟了。

StarRocks存算分離架構：
圖片
(cn是compute node，是無狀態計算節點+本地快取盤)

安全可靠使用的單副本

對比存算一體的3副本模式，存算分離使用單副本。存算分離的全量資料資料儲存在遠端物件儲存上(上圖的Distributed Storage，我們使用的是阿里雲的OSS)，即使CN節點掛了，其他CN節點也仍然可以查詢到資料(雖然需要重新拉取快取資料，查詢耗時會增加)，所以是可以安全可靠使用的單副本模式。這帶來2/3的儲存成本下降(本地盤只作為data cache之用)。

只快取必要資料

並且存算分離不需要把所有的資料都儲存在本地盤，而只需要快取常用資料即可，在單副本之上又節省大筆儲存成本，並且查詢效能在使用本地快取後能做效能一致。

並且大量使用物化檢視，減少基表實際需要儲存在data cache中的資料量。
圖片

上圖說明506TB的資料實際只在快取中儲存了342TB經過評估存算分離部署模式能帶來40%+的成本下降，儲存成本下降1 - (1/3*3/5)=4/5。

擴縮容無需搬遷資料

StarRocks存算一體可以任意水平擴容，無需停機，擴容後自動均衡搬遷資料。StarRocks存算分離更做到了擴縮容無需搬遷資料，擴容的新節點馬上就可以被利用，這在使用容器方案部署StarRocks時，尤為方便。

在複雜SQL join能力上大幅領先Clickhouse

圖片
https://docs.starrocks.io/zh/docs/benchmarking/SSB_Benchmarking/

StarRocks更適合星型模型，並且StarRocks與Clickhouse單表查詢效能不相伯仲(資料來源：clickbench 單機效能測試 https://benchmark.clickhouse.com/)

Clickhouse支援的join型別非常有限且使用複雜，StarRocks支援各種Join型別且符合標準SQL語法的預期，這讓使用者無需特別關注Join的特殊寫法帶來的效能問題(指Clickhouse的分散式和local表join問題)，專注於業務邏輯即可。

高效的離線匯入

從Clickhouse換成StarRocks後，離線匯入的流程發生了變化。

首先在離線平臺新建一個OSS外表，然後執行離線平臺的insert sql select語句從離線平臺讀取資料以parquet格式寫入到OSS外表中，然後StarRocks從物件儲存(OSS)直接broker load匯入資料。對比Clickhouse只能insert匯入，雖然還是使用StarRocks叢集資源，但透過控制broker load併發可以把叢集資源的消耗控制在可接受範圍內。壓測顯示離線匯入耗時比Clickhouse方案減少2/3。
圖片

重度使用物化檢視進行提效

透明物化檢視改寫

查詢可以自動透明改寫到物化檢視，使用者無需改SQL，並且保證資料的正確性。以往需要使用者在外圍主動管理Clickhouse物化檢視構建，資料重刷和查詢改寫，這引入了額外的複雜性。現在物化檢視由StarRocks自管理，不再需要外部程式碼主動改寫，減少了出錯的可能，也提供了不侵入使用者邏輯即可提升效能的方式。

使用技巧

1、不命中物化檢視時，在資源組中限制大表時間跨度超過8天就不允許查詢。
圖片

2、approx_count_distinct改寫成hll_union_agg(hll_hash(col))讓查基表與查物化檢視的結果完全一致
3、使用明細物化檢視減少資料讀取量
4、物化檢視只基於單表，方便在各種join sql語句中複用
5、一個物化檢視包括儘量多的指標，查詢時一次性查多個指標
6、materialized_view_rewrite_mode=‘force‘讓一個查詢中多個countdistinct也能命中物化檢視
圖片

物化檢視

推薦手工對SQL分析和建立物化檢視畢竟效率有限，所以我們開發了物化檢視推薦功能。

1、透過在fe中記錄SQL結構，在外部實現基於單表的物化檢視推薦程式
2、能做到對錶/物化檢視欄位的在過濾條件中的命中次數進行統計，用來判斷哪些欄位做排序鍵能適配更多的查詢
圖片

3、能做到對單表的子語句用到的指標和維度列進行分析，找到有高收益的潛在物化檢視，並且排除已經存在的物化檢視。
4、物化檢視啟用collocate group現在物化檢視推薦功能已經初步上線，並還在持續最佳化中。

最佳化選擇策略和效能

1、最佳化選擇的效能，跳過物化檢視與無關表的匹配(https://github.com/StarRocks/starrocks/pull/51010)。
2、提早剔除一些不包含查詢需要的列的物化檢視，減少了後續匹配測試的開銷(https://github.com/StarRocks/starrocks/pull/51044)。
3、優先選中排序鍵匹配查詢過濾條件的物化檢視，再優先選行數最少的物化檢視(https://github.com/StarRocks/starrocks/pull/51511)。

擴充套件物化檢視可用場景

物化檢視作為提升查詢效能的最關鍵也是最有效的手段，在3.3剛釋出時存在一些BUG，導致很多場景下物化檢視不能被命中。其中社群幫助修復一些問題，我們也修復8個命中問題，並且都已經提了PR併合並。(https://github.com/StarRocks/starrocks/pull/46472
https://github.com/StarRocks/starrocks/pull/47648
https://github.com/StarRocks/starrocks/pull/48001
https://github.com/StarRocks/starrocks/pull/48092
https://github.com/StarRocks/starrocks/pull/48142
https://github.com/StarRocks/starrocks/pull/48773
https://github.com/StarRocks/starrocks/pull/48984
https://github.com/StarRocks/starrocks/pull/49168)

修復物化檢視重新整理問題

1、支援重新整理順序為從新分割槽到老分割槽，這樣最近的資料能最快得到加速(https://github.com/StarRocks/starrocks/pull/46691)。
2、修復了force重新整理不生效的問題(https://github.com/StarRocks/starrocks/pull/52081)
3、修復物化檢視在image建立後被非預期inactive，重啟後被強制重新整理的問題(https://github.com/StarRocks/starrocks/pull/51388)。
4、反饋給社群修復了fast schema evolution導致的mv非預期重新整理問題

四、具體遷移過程

圖片

Clickhouse灰度遷移StarRocks

圖片
智慧運營並不直接查詢StarRocks，而是經過中間的ONE DSL平臺翻譯DSL(一種類SQL)成Clickhouse/StarRocks SQL後發給後端引擎。透過查詢時指定DSL目標翻譯型別，決定發到Clickhouse或者StarRocks，這樣在遷移過程中可以按介面灰度，然後逐個的遷移，有問題可以隨時單獨回滾某個介面。

語法相容

相容Clickhouse函式

  • 我們仿造StarRocks中已有的Trino的AstBuilder實現了Clickhouse的AstBuilder，透過新增sql_dialect=clickhouse選項，讓相容改動不汙染StarRocks原來的行為。
  • 我們相容了業務方用到的72個函式，覆蓋了最常用Clickhouse函式，業務方大部分情況下不需要修改查詢SQL，從而減小了遷移需要的工時。可以做到一個Clickhouse函式對應一個StarRocks函式或者多個函式的組合，並且將來新增一個Clickhouse函式對映是非常容易的。
  • 我們還實現了Clickhouse的ArrayJoin函式，能在StarRocks中使用一樣的方式進行列轉行：-- StarRocks原生寫法select u from tbl, unnest(array_column)-- ArrayJoin的寫法select arrayJoin(array_column) from tbl

不過Clickhouse的arrayJoin語法仍然是不支援的，需要手工改寫成StarRocks的unnest語法。

此外，我們還實現了Clickhouse式的別名引用，可以在select的後段引用前段定義的別名(https://github.com/StarRocks/starrocks/pull/43919)：Select id as id_alias, sum(a) as b, concat(b, ',', '_') from xx where  id_alias > 100 group by id_alias

Clickhouse表/物化檢視轉換工具

在引擎之外做了轉換工具，能夠以程式的方式將Clickhouse的建表和建物化檢視的DDL轉為StarRocks的DDL，節約了手工轉換的時間的同時也避免手工轉換時可能發生的改寫錯誤。

最佳化查詢效能

修復特定效能問題
  1. 前面提到的修復多個場景的物化檢視命中問題和最佳化物化檢視選擇策略效能
  2. 分割槽欄位查詢帶函式導致物化檢視分割槽裁剪失敗(https://github.com/StarRocks/starrocks/pull/46786)
  3. 最佳化數值與字串型別隱式轉換(https://github.com/StarRocks/starrocks/pull/50168)：對應sql效能提升20倍。
  4. 最佳化date/datetime被當做字串使用時的規則，從而命中稀疏索引命中(https://github.com/StarRocks/starrocks/pull/50643)：對應sql效能提升30倍。
  5. 減少查詢時存算分離staros的rpc呼叫次數(https://github.com/StarRocks/starrocks/pull/46913) + 簡易rpc結果快取：查詢耗時普遍減少3s+。
建立大量物化檢視

透過持續對io高/cpu高的查詢針對性最佳化，發現有大量查詢是可以用物化檢視加速的。在原有Clickhouse遷移過來的物化檢視之外，又增加了許多物化檢視。目前為止已經有140+物化檢視。最大的3張表佔總儲存的50%，對應了60+物化檢視。

表結構最佳化

StarRocks所有的表結構都繼承自Clickhouse的表結構，在實際線上執行過程中，發現了很多schema不合理的地方。透過對錶和物化檢視的排序鍵、分桶鍵、分桶數量的最佳化讓其符合最常用的過濾條件中的欄位的順序，效能得到極大提升(如何設計合理排序鍵，以便查詢利用字首索引加速https://docs.starrocks.io/zh/docs/table_design/indexes/Prefix...)。比如某張表的排序鍵最佳化後，查詢效能提升了150倍。

找到問題SQL讓使用者修改寫法

透過持續對io高/cpu高的查詢針對性最佳化，發現有很多StarRocks rule不能等價轉換，但從業務角度看是等價的小改動，可以顯著提升效能的場景。

1、換種寫法改進plan
比如下面的極端case的改動提升了250倍效能，因為它導致估算的行數變少，從而最佳化了join order的順序，生成了更好的plan。

brand_id IN (
        SELECT brand_id FROM olap_znyy.st_itg_spu_info_all 
        WHERE brand_level_name IN ('A級品牌', 'B級品牌', 'C級品牌'))
改成
brand_id IN (
        SELECT distinct brand_id FROM olap_znyy.st_itg_spu_info_all 
        WHERE brand_level_name IN ('A級品牌', 'B級品牌', 'C級品牌'))

2、把limit提前到join語句裡

業務上會先join維度表取得更多欄位，最後再order by join左分支中的欄位再limit。改成把limit放到join左分支中，然後再join維度表。這樣減少了join的行數，降低70%耗時。
圖片

3、去除join key上不必要的函式呼叫

業務方join on upper(query)上，但所有join到的表的資料其實都是小寫(這個資訊只有業務方自己才知道)，根本不需要轉成大寫後再join。去除upper函式再join提升至少一倍效能。

4、去除不必要的toString

使用者喜歡join時把數值欄位toString之後join，這樣去掉toString也可以減少計算量提升效能。除了join key，還有很多select地方也喜歡用toString，也都是非必要的。

5、子查詢合併，消除join。收益：效能提升約50%
圖片

6、維度表過濾條件下推，收益：查詢超時->0.1s
圖片

運維和可觀測性增強

除了上面引擎方面的改動，還配合業務方的管理需求，支援了一些特定的Api，比如：

  • 資源水位API
  • SQL複雜度因子API
  • 根據表名獲取物化檢視列表和物化檢視的具體列資訊API
  • 指定custom_query_id，可以非同步kill query的能力(https://github.com/StarRocks/starrocks/pull/47632；https://github.com/StarRocks/starrocks/pull/48114)

五、成果展示

得到社群的給力支援，以及與智慧運營團隊緊密的合作，我們最終順利從Clickhouse遷移到StarRocks，並且在查詢效能耗時減少為Clickhouse查詢耗時的一半。

以下是獲得的收益：

  • 成本收益：智慧運營底層AP引擎費用下降40%，儲存費用下降5/6。
  • 效能和體驗收益：智慧運營的大盤的P95耗時從最初的8.5s降低到當前的4.3s；P0頁面低基維度的耗時從最初的9.07s降低到4.77s，高基維的P95耗時從24.38s降低到11.94s; 查詢成功率從98.57%提升到99.44%。
  • 資料時效性收益：在雙跑期間clickhouse的基線SLA達成率是99.42%，StarRocks的基線SLA達成率是100%。
  • 穩定性收益：叢集因為單節點異常導致叢集不可用的時間從15min縮短到30s內。

我們與社群保持了密切的接觸，會提交一些重大issue，同時也貢獻我們的修復給社群。遷移過程中共提交PR 28個，已merge 24個(https://github.com/StarRocks/starrocks/pulls?q=is%3Apr+author%3Akaijianding)。在遷移過程中，開發了Clickhouse函式相容等10+功能，修復40+個問題（包括反饋給社群修復的）。

六、總結

此次遷移達成了預期的成本和效能的收益目標，也擴充了叢集未來的成長空間，也讓業務團隊和引擎團隊都更加的瞭解StarRocks，收穫大量遷移經驗，為將來遷移其他業務提供了有說服力的範例。

在遷移過程中，我們與社群保持了緊密的聯絡，獲得了社群大量幫助，也貢獻了大量patch給社群，減少社群其他人需要踩的坑。在我們得物內部StarRocks的未來規劃中，我們也將繼續深度參與社群。

往期回顧

1.基於Redis核心的熱key統計實現方案｜得物技術
2.盤點這些年搭建器在使用者體驗最佳化的實踐｜得物技術
3.Java效能測試利器：JMH入門與實踐｜得物技術
4.彩虹橋架構演進之路-負載均衡篇｜得物技術
5.解析Go切片：為何按值傳遞時會發生改變？｜得物技術

文 / Kaijian
關注得物技術，每週更新技術乾貨，要是覺得文章對你有幫助的話，歡迎評論轉發點贊～未經得物技術許可嚴禁轉載，否則依法追究法律責任。

相關文章