水滴籌基於阿里雲 EMR StarRocks 實戰分享

摘要：水滴籌大數據部門的數據開發工程師韓園園老師爲大家分享水滴籌基於阿里雲EMR StarRocks的實戰經驗。

本篇內容將會圍繞以下五個方面展開：

1.公司介紹
2.StarRocks 概覽
3.場景實戰
4.最佳實踐
5.未來規劃

一、公司介紹

 

水滴創立於2016年，業務包括水滴籌、水滴保險商城等，於2021年5月7日上市。水滴以“用互聯網科技助推廣大人民羣衆有保可醫，保障億萬家庭”爲使命，致力於爲用戶提供健康保障解決方案。希望聯合合作伙伴打造中國版聯合健康集團，讓用戶以更低的費用享受到更好的診療。

自2016年7月至2022年末，水滴籌平臺的捐款人達到了4.3億，有超過277萬的大病患者得到了幫助，總計籌集醫療資金達到569億元，並提供了755個保險產品。

二、StarRocks 概覽

使用歷程

首先來梳理一下水滴籌在OLAP方面的發展歷程。

• 2018年，引入ClickHouse，主要用於監控報警和用戶相關的行爲分析工作，包括漏斗、留存等。
• 2020年，引入TiDB，主要用於OLAP分析和報表展示。
• 2021年，針對當時組件的一些痛點，也爲了探索更多的OLAP引擎，引入StarRocks v1.17.8（DorisDB）版本，自建StarRocks集羣，用於OLAP分析。
• 2022年2月，升級StarRocks集羣到v1.19.5版本，用於報表展示。
• 2022年10月，遷移自建StarRocks集羣至阿里雲EMR StarRocks，並將大數據的TiDB所有的服務遷移到StarRocks上，版本爲v2.3.2。
• 2023年3月，參加阿里雲EMR Serverless StarRocks集羣公測，並將集羣新功能嘗試應用於新業務中。

水滴現狀

從上表可以看到水滴對各個組件的使用場景，以前以TiDB作爲主要組件進行OLAP分析和OLTP，少部分服務使用StarRocks；實時監控、用戶行爲分析還在ClickHouse中。

隨着近幾年業務的發展、實驗的沉澱， OLAP組織架構也存在一些問題，如組件維護困難，數據冗餘存儲，數據收口和出口不統一等情況。水滴大數據希望引入一款實時OLAP數據庫，統一數據的監控和查詢，用於解決各業務線對數據高效實時數據查詢和數據統計分析的需求。

水滴OLAP組件技術選型

水滴對OLAP引擎最關注的有四點，分別是：併發能力，物化視圖，join能力和寫入實時。

上表是基於水滴通過近幾年的實踐得到的結論，可以看出：

• StarRocks在併發能力、物化視圖、join能力和寫入實時方面整體都是比較優秀的。
• ClickHouse的併發能力和join能力相對較弱。
• TiDB的併發能力和join能力中等，但是不支持物化視圖，導致用戶體驗不是很好。

基於幾個組件的使用和綜合考慮，水滴最後決定將StarRocks作爲最終的OLAP引擎，將TiDB的服務遷移到StarRocks中，開始實施組件的統一。

三、場景實戰

概覽

水滴OLAP整體架構如上圖所示。主要分爲如下幾個部分：數據源、數據同步、OLAP引擎、應用場景和數據管理平臺。

數據源又分爲離線數據和實時數據。

• 離線數據主要存儲在MaxCompute，通過BrokerLoad、SparkLoad兩種同步方式，同步到StarRocks中，時效性是T+1或者小時級別。
• 實時數據主要是一些業務和埋點數據，存儲在MySQL、TiDB和Kafka中，通過Flink-CDC、Flink-SQL以及自研Galaxy平臺進行實時同步。

數據進入OLAP引擎後，水滴主要用到三種表模型，分別是：明細模型，聚合模型和主鍵模型。

• 明細模型用於存儲明細數據和業務統計完成之後的數據。
• 聚合模型用於存儲根據業務場景預聚合的數據。
• 主鍵模型用於存儲業務的實時數據。

數據模型主要用到寬表、星型模型和雪花模型三種。

數據管理平臺主要包括：元數據管理，穩定性保障，質量管理，以及數據安全。

目前水滴的集羣規模爲，包含3臺FE和7臺BE，每日查詢量300萬次。

數據寫入方面，有1500多個離線任務，每日實時更新行數100萬行以上，每日寫入數據量1T以上。

下面以兩個具體的場景爲例來介紹水滴的StarRocks實戰。

場景一：報表平臺OLAP引擎統一

第一個場景是報表平臺OLAP引擎統一。

水滴報表平臺之前主要使用TiDB作爲存儲和查詢引擎，後來又引入了StarRocks，由多個組件構成了我們的OLAP引擎。這樣的架構存在如下三個痛點：

• 組件多，維護不便；
• 成本高；
• TiDB的併發限制和慢SQL的問題，導致客戶體驗不佳。

報表查詢面對三大挑戰：

• 查詢高併發
• 響應低延遲
• 大數據量多表Join

在水滴報表平臺之前的流程中，無論是離線數據還是實時數據，都會寫入到TiDB和StarRocks中，然後提供報表平臺或者業務系統進行使用。經過一段時間的測試和使用，評估StarRocks可以作爲水滴報表平臺的主要引擎，後續會將TiDB遷移到StarRocks中。

切換之前，水滴對兩個平臺做了壓測對比。

上圖中，左邊是兩個集羣的詳細參數。

首先將TiDB的所有數據同步到StarRocks中，保證壓測的數據是完全一致的；然後，使用報表平臺的所有SQL查詢，在相同數據、相同SQL、相同併發的情況下，同時在TiDB和StarRocks中循環遍歷執行這些SQL，經過一段時間的測試，基於水滴的使用場景和水滴數據針對兩個引擎的查詢性能得到了如下的結論，下面以TiDB中SQL的響應時間分成三部分進行對比，因爲大部分響應時間都在這三個分段內：

• 在TiDB中，執行時間在400ms以內的SQL在StarRocks中執行時間爲200ms以內
• 在TiDB中，執行時間在400ms到1.5s的SQL在StarRocks中執行時間在184ms到300ms以內
• 在TiDB中，執行時間在1.5s到4s的SQL在StarRocks中執行時間爲198ms到500ms以內

水滴大數據部門經過架構優化後，統一了OLAP引擎爲StarRocks，將離線和實時數據寫到StarRocks之中，提供給業務系統以及報表平臺使用。

新架構的優點是結構比較清晰，也維護了統一的數據口徑。

上圖從三方面展示了架構遷移後的效果：

• 通過將TiDB遷移到StarRocks，實現了組件統一，系統的運營成本得到了一定程度的降低。平臺整體成本降低了58%，整體性能提升了40%。
• 觀測TiDB和StarRocks響應時間的tp99，可以看到TiDB響應時間的tp99在3秒左右，而StarRocks響應時間的tp99基本是幾百毫秒，在1秒以內。
• 數據離線同步耗時以及慢SQL，StarRocks都有一定程度的提升。

在遷移StarRocks的過程中也遇到一些問題：

• StarRocks的DDL和DML與TiDB/MySQL相比雖然兼容90%場景，還是存在一些不兼容問題，上表中列舉了一些不兼容的情況以及相應的解決方案。
• 數據沒辦法直接從MaxCompute同步到StarRocks，必須中間有一層OSS的中轉。

場景二：數據服務遇到問題

場景二是公司的財務推帳系統。

財務推帳系統使用TiDB作爲數據存儲查詢引擎，面臨的核心挑戰是：

• 數據實時性要求高；
• 數據一致性要求高；
• 數據的計算邏輯複雜；
• 數據分析需求靈活。

財務推帳系統所需的數據涉及多張表，每張標的數據量都是上億級別，推帳需要多張上億級別的表相互Join才能實現。因爲TiDB的併發和內存的限制，目前沒辦法對這些表多表關聯直接聚合處理，所以水滴先根據ID進行分段聚合，然後通過代碼的聚合方式，寫到中間表中。因爲推帳是分場景的，處理時間最長的場景需要30分鐘的時間，所有300多個場景併發處理，最終也需要4-5小時的時間。對財務同學的工作效率，有一定的影響。

改造之後的流程爲：

數據首先實時寫入TiDB中，然後從TiDB實時寫入StarRocks中，因爲中間聚合的數據進行反推，因此需要先進行快照數據留存後，StarRocks中的數據可以直接分場景聚合處理，單場景的最大耗時爲30秒左右。

架構升級後，性能直接提升60倍，TiDB只參與存儲不再參與計算，其引擎壓力降低了70%，但是由於數據同時留存在TiDB和StarRocks中，存儲成本有一定程度的增加。

四、最佳實踐

表設計方面

• 絕大部分表都按照時間字段進行了分區，使用常用的查詢列以及關聯的關鍵列作爲分桶；
• 將經常過濾和group by的列作爲排序鍵，優先使用整型作爲排序鍵；
• 對於明細數據，由於數據量比較大，用動態分區做數據過期的設置；
• 建表時儘量使用精確的字段類型，例如：數字類型數據不用字符串類型，INT能滿足的不用BIGINT，知道字符串長度範圍的數據不用String類型；
• 數字列儘量放到字符串的列之前。

數據同步方面

• 離線寫入主要用的是BrokerLoad和SparkLoad兩種同步方式；
• 實時寫入採用Flink-CDC和自研Galaxy平臺同步方式；
• 實時寫入需要控制數據寫入的頻率，降低後臺合併的頻率，保證程序穩定和數據的一致性；
• 使用UniqueKey的replace_if_not_null對部分列進行更新，PrimaryKey直接支持部分列更新。

運維和監控方面

• 對FE進行四層的負載均衡，保證查詢請求的高可用，同時也保證查詢請求的負載均衡；
• 優化集羣參數，來提高集羣的查詢性能：
  • 提高StarRocks的查詢併發(parallel_fragment_exec_instance_num)
  • 提高單個查詢內存限制(exec_mem_limit)
• 使用Prometheus+Grafana進行集羣監控告警；
• 對查詢歷史進行分析，統計和監控慢SQL、大SQL，及時告警和優化。

權限與資源方面

• 細分賬戶，避免混用，實現更好的監控和維護，方便將大SQL、慢SQL準確定位用戶；
• 根據業務和實際使用場景來劃分資源組，對查詢進行資源隔離，保證業務之間不互相影響；
• DDL操作權限收斂到統一平臺，增加數據的安全和集中控制。

數據管理與質量方面

• 根據查詢記錄定期分析使用情況，做好表生命週期管理；
• 離線同步數據T+1進行數據質量校驗；
• 實時同步小時和天級別進行數據質量校驗。

當前問題

• 業務需要但是目前沒有支持AUTO_INCREMENT和CURRENT_TIMESTAMP；
• String類型的數據長度有限制，對於某些長度較大的字段智能過濾或者無法適用；
• 現有日誌格式對於錯誤日誌分析不是很友好;
• 實時數據的寫入頻率不好把控，寫入太快會造成版本合併的問題，寫入太慢又有數據延遲問題；
• 時間字段不支持毫秒；
• CPU無法完全隔離；
• 表權限目前還不能控制到行級別。

五、未來規劃

水滴大數據部門的未來規劃主要從三方面入手，分別是用戶畫像、監控報警和用戶行爲分析。

用戶畫像

• 當前組件：HBase+ES
• 業務場景：消息推送、用戶圈選
• 場景特點：更新頻繁，每天20-30億的數據更新量，數據量大，列動態更新
• 當前痛點：因爲業務主要通過ES進行用戶圈選，查詢效率比較低，無法實現多表Join；
• 切換難點：如果要切換StarRocks，重點考慮的問題是，一張1000億+的列，14億數據的大寬表，需要頻繁動態更新列，平臺是否能夠支持。

監控報警

• 當前組件：埋點上報+ClickHouse
• 業務場景：實時監控
• 場景特點：實時性要求高，查詢可物化
• 當前痛點：併發收到受限，讀會影響數據寫入
• 切換難點：切換到StarRocks的難點在於，監控需要分鐘級或者更短的時間，對數據的準實時性要求高

用戶行爲分析

• 當前組件：ClickHouse
• 業務場景：漏斗，留存，路徑分析
• 場景特點：數據量大，單表1000億+數據，每天增量數億；查詢週期長，用戶需要查一個月、三個月、半年以上的數據；大表join，需要將用戶行爲表與用戶畫像進行關聯分析，實現數據的圈選或者查詢操作
• 當前痛點：兩個以上的大表join性能不佳

切換難點：切換到StarRocks的難點在於，當前系統使用了大量的ClickHouse內置窗口函數和數組函數，在StarRocks對應的替代函數的準確率和適配度等有待驗證。

水滴大數據部門對2023年StarRocks相關的計劃包括：

• 2023年上半年，將更多業務場景接入StarRocks中，實現更全面的權限控制和資源隔離；
• 2023年7月，升級StarRocks到2.5以上版本，使用嵌套物化視圖探索更多業務場景，將StarRocks應用於數據畫像，嘗試替代ES；
• 2023年10月，將埋點數據和Binlog數據實時寫入StarRocks中，探索StarRocks在漏斗、留存、行爲分析場景的使用，嘗試替代ClickHouse；
• 2023年底，水滴大數據部門的規劃目標是實現OLAP引擎統一，探索更多新功能、新場景。

六、致謝

在分享的最後，感謝阿里雲StarRocks團隊對我們的技術支持，使得我們更快更好地將StarRocks應用於各種場景中。水滴也會跟緊社區的步伐，更好地解決場景需求。

最後祝阿里雲StarRocks發展得越來越好。

原文鏈接

本文爲阿里雲原創內容，未經允許不得轉載。