*本文根據 vivo 大數據工程師王可在「StarRocks Summit 2023」上演講整理，感興趣可前往峰會官網，檢視直播回放。
前言
在大數據時代，數據分析和處理能力對於企業的決策和發展至關重要。
vivo 作為一家全球行動網際網路智慧終端公司，需要基於行動終端的制造、物流、銷售等各個方面的數據進行分析以滿足業務決策。
而隨著公司數位化服務的演進，業務訴求和技術架構有了新的調整，已有的基於 Trino 的架構面臨著數據時效、查詢效能、並行能力、復雜運維等方面的瓶頸，為此 vivo 大數據團隊進行了一系列技術架構的探索和實踐。
vivo 業務快速發展
帶來更多數據挑戰
在數位化演進的過程中，vivo 面臨著業務訴求和技術架構方面的新挑戰，主要包括時效性要求提升、存取量大、計算場景復雜和運維難等問題。
vivo 原有數據平台是基於 Trino+Hive 的架構來實作，一方面透過 Trino 來抽取業務柯瑞的數據（MySQL、Oracle、SQLserver 等），另一方面將抽取的數據寫入到 Hive 中，根據業務側需求進行數倉的加工處理。
1. 時效性挑戰，業務分析決策需加速
隨著數位化行程推進，制造、行銷、銷售等業務對實分時析的套用越來越多，基於 Trino+Hive 架構的小時級數據時效性已無法滿足業務需求，業務側需要數倉架構能夠即時抽取業務側數據並加工，從而實作上層報表的即時呈現，以便更好地支持相關的決策分析。
2. 存取量挑戰，效能與穩定性亟待提高，支撐業務穩定執行
隨著業務規模向全球發展，vivo 的分銷代理系統覆蓋使用者量級飛速增長，行銷、計價、訂單、庫存等業務系統均需要即時數據來保證銷售業務精準穩定營運，這使得原有數倉架構的存取量持續增長，同時，隨著各種大數據分析相關新業務的上線， Trino 負載越來越高，逐漸無法滿足存取量持續增長帶來的查詢壓力。
3. 計算場景挑戰，難以滿足業務復雜查詢需求
在業務側的實際分析需求中，經常會有十幾張表 Join 的場景，業界存在 Flink 和 Trino 兩種方案。
第一種方案是在寫入數倉前利用 Flink 等提前做好相關表的 Join 計算，將其加工成大寬表寫入數倉中，但 Join 後的數據儲存占用代價高。
第二種方案則是直接將各個維表儲存在數倉中，分析查詢的時候再進行 Join 計算，但 Trino 在處理多表 Join 時效能一般，難以滿足業務側實際的查詢需求。
這兩種方案都沒有辦法很好的平衡表 Join 的效能和數據儲存占用的問題。
4. 運維挑戰，使用者查詢體驗需最佳化
在實際運維使用 Trino 的過程中，vivo IT 部門發現 Trino 不支持高可用和多副本的問題，在業務高峰期，Trino 負載較高，會影響到數據平台的穩定性和使用者查詢體驗，降低業務決策效率，甚至有可能收到使用者對數據平台的投訴 。
StarRocks 破局：
OLAP 選型與實踐
面對上述挑戰，vivo 開始尋找一款新的 OLAP 引擎以提升數據平台的效能。
vivo IT 部門調研了幾款當前比較流行的 OLAP 引擎，包括 Trino、Clickhouse、StarRocks 和 Doris，並從查詢延遲、SQL 型別、並行效能、Join 效能和運維成本等多個維度進行了對比：
Trino 當前的查詢效能和並行能力是無法滿足需求的，且 Join 查詢的能力也相對較弱。
Clickhouse 雖然查詢延遲表現很優秀，但由於其支持的 SQL 型別為非標準 SQL，可能會涉及到較多的業務改造，同時其並行能力和 Join 能力也無法滿足需求，且運維起來比較復雜。
StarRocks 在調研的各個維度上表現都非常好，能夠很好地解決當前數倉架構所面臨的問題。
Doris 在選型時還不支持向量化引擎，其查詢表現和 StarRocks 相比還存在一定的差距。
經過深入調研與測試，vivo IT 部門總結了 StarRocks 的一些優勢：
查詢效能優秀： 查詢延遲在亞秒級別，Join 效能優秀，能夠滿足 vivo 對即時大數據分析的需求
使用方便： 支持數據匯入、匯出等功能
數據模型豐富： 支持明細模型、聚合模型、更新模型、主鍵模型，其中主鍵模型能夠很好地滿足 vivo 大數據的場景
運維成本低： 支持高可用、線上擴縮容、數據分片自動均衡
基於以上的對比與考量，最終選擇了使用 StarRocks 來作為數據平台的 OLAP 引擎。
StarRocks 套用
為業務搭建數據橋梁
在過去 2 年裏，vivo IT 部門深度套用 StarRocks，並透過 StarRocks 進一步完善數據架構，幫助業務更好地使用和查詢數據。
vivo IT 部門對接的業務主要有 視覺化報表、BI 數據探索、行銷分析、駕駛艙、數據大屏 等，另外對應的還有 研發系統和運維系統 。
vivo 的數據主要來自於手機相關的訂單、ERP、MES 以及其他數據，在升級數據分析平台架構後，他們將StarRocks 套用在查詢引擎中，為業務團隊搭建數據橋梁，支撐上層業務套用更快地查詢，更準地分析。
vivo當前數據分析平台的架構
1. 數據鏈路最佳化，讓查詢更便捷
vivo 的數據鏈路分為離線和即時鏈路，其中離線鏈路主要是透過 Trino 進行離線抽數到 Hive 中，經過 Hive 加工處理為大寬表，再推到 Clickhouse 中進行離線場景數據的查詢；
即時鏈路則透過 Flink 加工後寫入到 Kafka 中，然後透過 Flink 消費處理寫入到 StarRocks 中進行即時表的查詢。
數據鏈路最佳化
2. 列更新（Partial Update），最佳化效能同時降低資源消耗
StarRocks 的 Join 效能表現很好，不過頻繁的 Join 查詢會帶來計算資源的大量消耗。基於此，vivo IT 部門使用 Flink 將多個維表打平為大寬表，寫入 StarRocks 來進行查詢，在節省 StarRocks 計算資源的同時，查詢體驗也更好。
針對維表歷史數據變更的場景，他們使用 StarRocks 提供的部份列更新（Partial Update）功能，在 Flink 寫入主鍵模型大寬表的過程中，透過一些簡單的配置開啟部份列更新，實作以較小的代價靈活地更新大寬表中對應的列數據。
3. 集群監控告警，靈活、便捷運維
在常規的監控告警方面，由於 StarRocks 提供了豐富的 Metrics 介面，便於Prometheus 采集並儲存 StarRocks 集群各個節點的狀態資訊，以供 Grafana 生成各種視覺化的 Panel。
另外 vivo IT 部門還會對集群的審計 SQL 進行采集分析，透過 ELK 將各個 FE 節點的審計日誌采集後寫入到 ES 中，透過配置規則，篩選出其中的慢 SQL，推播到告警系統中，以提醒相應的同事關註及最佳化。
4. 彈性方案，降本增效
vivo 的業務特點是業務存取量存在波峰波谷，且波峰波谷之間的存取量差異明顯、時間界限明顯，業務對存取持續時間更短的波峰期效能要求高，伺服器資源使用率考核壓力大。
對於國內集群，vivo IT 部門采取了多集群的模式來分擔高峰期的查詢存取量，透過負載均衡將流量分攤到主備集群。
海外集群則依賴於 StarRocks 的多副本高可用機制，采用各個節點輪詢升降配實作集群配置的擴縮容。 具體的流程如下圖所示，vivo IT 部門將整個流程透過程式碼的方式嵌入到運維平台裏，透過程式自動化排程執行，提高擴縮容執行的效率 。
結語
在過去兩年多的探索中，vivo 發現 StarRocks 具有便捷運維、便捷部署與彈性擴縮容能力，同時提供了卓越的查詢效能，足以應對高並行查詢場景。借助 StarRocks 資料庫，vivo 打造了即時大數據分析平台，為業務實分時析提供高效支持。
在未來，vivo 將在雲原生建設、存算分離等場景與 StarRocks 進行更加深入的探索，以實作數據平台的持續演進，同時也將關註 StarRocks 社群的發展，與其他企業和開發者共同推動計畫進步 。
1.直播回放。 若對本場演講感興趣，可點選前往峰會官網，檢視直播回放。
2 .PPT 獲取。 如需獲取本次峰會 PPT 資料，可在後台回復「峰會」 獲取 。
