在大數(shù)據(jù)時(shí)代，數(shù)據(jù)分析和處理能力對于企業(yè)的決策和發(fā)展至關(guān)重要。

vivo 作為一家全球移動互聯(lián)網(wǎng)智能終端公司，需要基于移動終端的制造、物流、銷售等各個(gè)方面的數(shù)據(jù)進(jìn)行分析以滿足業(yè)務(wù)決策。

而隨著公司數(shù)字化服務(wù)的演進(jìn)，業(yè)務(wù)訴求和技術(shù)架構(gòu)有了新的調(diào)整，已有的基于 Trino 的架構(gòu)面臨著數(shù)據(jù)時(shí)效、查詢性能、并發(fā)能力、復(fù)雜運(yùn)維等方面的瓶頸，為此 vivo 大數(shù)據(jù)團(tuán)隊(duì)進(jìn)行了一系列技術(shù)架構(gòu)的探索和實(shí)踐。

vivo 業(yè)務(wù)快速發(fā)展帶來更多數(shù)據(jù)挑戰(zhàn)

在數(shù)字化演進(jìn)的過程中，vivo 面臨著業(yè)務(wù)訴求和技術(shù)架構(gòu)方面的新挑戰(zhàn)，主要包括時(shí)效性要求提升、訪問量大、計(jì)算場景復(fù)雜和運(yùn)維難等問題。

vivo 原有數(shù)據(jù)平臺是基于 Trino+Hive 的架構(gòu)來實(shí)現(xiàn)，一方面通過 Trino 來抽取業(yè)務(wù)庫里的數(shù)據(jù)（MySQL、Oracle、SQLserver 等），另一方面將抽取的數(shù)據(jù)寫入到 Hive 中，根據(jù)業(yè)務(wù)側(cè)需求進(jìn)行數(shù)倉的加工處理。

時(shí)效性挑戰(zhàn)，業(yè)務(wù)分析決策需加速

隨著數(shù)字化進(jìn)程推進(jìn)，制造、營銷、銷售等業(yè)務(wù)對實(shí)時(shí)分析的應(yīng)用越來越多，基于 Trino+Hive 架構(gòu)的小時(shí)級數(shù)據(jù)時(shí)效性已無法滿足業(yè)務(wù)需求，業(yè)務(wù)側(cè)需要數(shù)倉架構(gòu)能夠?qū)崟r(shí)抽取業(yè)務(wù)側(cè)數(shù)據(jù)并加工，從而實(shí)現(xiàn)上層報(bào)表的實(shí)時(shí)呈現(xiàn)，以便更好地支持相關(guān)的決策分析。

訪問量挑戰(zhàn)，性能與穩(wěn)定性亟待提高，支撐業(yè)務(wù)穩(wěn)定運(yùn)行

隨著業(yè)務(wù)規(guī)模向全球發(fā)展，vivo 的分銷代理系統(tǒng)覆蓋用戶量級飛速增長，營銷、計(jì)價(jià)、訂單、庫存等業(yè)務(wù)系統(tǒng)均需要實(shí)時(shí)數(shù)據(jù)來保證銷售業(yè)務(wù)精準(zhǔn)穩(wěn)定運(yùn)營，這使得原有數(shù)倉架構(gòu)的訪問量持續(xù)增長，同時(shí)，隨著各種大數(shù)據(jù)分析相關(guān)新業(yè)務(wù)的上線， Trino 負(fù)載越來越高，逐漸無法滿足訪問量持續(xù)增長帶來的查詢壓力。

計(jì)算場景挑戰(zhàn)，難以滿足業(yè)務(wù)復(fù)雜查詢需求

在業(yè)務(wù)側(cè)的實(shí)際分析需求中，經(jīng)常會有十幾張表 Join 的場景，業(yè)界存在 Flink 和 Trino 兩種方案。

第一種方案是在寫入數(shù)倉前利用 Flink 等提前做好相關(guān)表的 Join 計(jì)算，將其加工成大寬表寫入數(shù)倉中，但 Join 后的數(shù)據(jù)存儲占用代價(jià)高。

第二種方案則是直接將各個(gè)維表存儲在數(shù)倉中，分析查詢的時(shí)候再進(jìn)行 Join 計(jì)算，但 Trino 在處理多表 Join 時(shí)性能一般，難以滿足業(yè)務(wù)側(cè)實(shí)際的查詢需求。

這兩種方案都沒有辦法很好的平衡表 Join 的性能和數(shù)據(jù)存儲占用的問題。

運(yùn)維挑戰(zhàn)，用戶查詢體驗(yàn)需優(yōu)化

在實(shí)際運(yùn)維使用 Trino 的過程中，vivo IT 部門發(fā)現(xiàn) Trino 不支持高可用和多副本的問題，在業(yè)務(wù)高峰期，Trino 負(fù)載較高，會影響到數(shù)據(jù)平臺的穩(wěn)定性和用戶查詢體驗(yàn)，降低業(yè)務(wù)決策效率，甚至有可能收到用戶對數(shù)據(jù)平臺的投訴。

StarRocks 破局：OLAP 選型與實(shí)踐

面對上述挑戰(zhàn)，vivo 開始尋找一款新的 OLAP 引擎以提升數(shù)據(jù)平臺的性能。

vivo IT 部門調(diào)研了幾款當(dāng)前比較流行的 OLAP 引擎，包括 Trino、ClickHouse、StarRocks 和 Doris，并從查詢延遲、SQL 類型、并發(fā)性能、Join 性能和運(yùn)維成本等多個(gè)維度進(jìn)行了對比：

• Trino 當(dāng)前的查詢性能和并發(fā)能力是無法滿足需求的，且 Join 查詢的能力也相對較弱。
• ClickHouse 雖然查詢延遲表現(xiàn)很優(yōu)秀，但由于其支持的 SQL 類型為非標(biāo)準(zhǔn) SQL，可能會涉及到較多的業(yè)務(wù)改造，同時(shí)其并發(fā)能力和 Join 能力也無法滿足需求，且運(yùn)維起來比較復(fù)雜。
• StarRocks 在調(diào)研的各個(gè)維度上表現(xiàn)都非常好，能夠很好地解決當(dāng)前數(shù)倉架構(gòu)所面臨的問題。
• Doris 在選型時(shí)還不支持向量化引擎，其查詢表現(xiàn)和 StarRocks 相比還存在一定的差距。

經(jīng)過深入調(diào)研與測試，vivo IT 部門總結(jié)了 StarRocks 的一些優(yōu)勢： 查詢性能優(yōu)秀：查詢延遲在亞秒級別，Join 性能優(yōu)秀，能夠滿足 vivo 對實(shí)時(shí)大數(shù)據(jù)分析的需求

使用方便：支持?jǐn)?shù)據(jù)導(dǎo)入、導(dǎo)出等功能

數(shù)據(jù)模型豐富：支持明細(xì)模型、聚合模型、更新模型、主鍵模型，其中主鍵模型能夠很好地滿足 vivo 大數(shù)據(jù)的場景

運(yùn)維成本低：支持高可用、在線擴(kuò)縮容、數(shù)據(jù)分片自動均衡

基于以上的對比與考量，最終選擇了使用 StarRocks 來作為數(shù)據(jù)平臺的 OLAP 引擎。

StarRocks 應(yīng)用為業(yè)務(wù)搭建數(shù)據(jù)橋梁

在過去 2 年里，vivo IT 部門深度應(yīng)用 StarRocks，并通過 StarRocks 進(jìn)一步完善數(shù)據(jù)架構(gòu)，幫助業(yè)務(wù)更好地使用和查詢數(shù)據(jù)。

vivo IT 部門對接的業(yè)務(wù)主要有可視化報(bào)表、BI 數(shù)據(jù)探索、營銷分析、駕駛艙、數(shù)據(jù)大屏等，另外對應(yīng)的還有研發(fā)系統(tǒng)和運(yùn)維系統(tǒng)。

vivo 的數(shù)據(jù)主要來自于手機(jī)相關(guān)的訂單、ERP、MES 以及其他數(shù)據(jù)，在升級數(shù)據(jù)分析平臺架構(gòu)后，他們將 StarRocks 應(yīng)用在查詢引擎中，為業(yè)務(wù)團(tuán)隊(duì)搭建數(shù)據(jù)橋梁，支撐上層業(yè)務(wù)應(yīng)用更快地查詢，更準(zhǔn)地分析。

數(shù)據(jù)鏈路優(yōu)化，讓查詢更便捷

vivo 的數(shù)據(jù)鏈路分為離線和實(shí)時(shí)鏈路，其中離線鏈路主要是通過 Trino 進(jìn)行離線抽數(shù)到 Hive 中，經(jīng)過 Hive 加工處理為大寬表，再推到 ClickHouse 中進(jìn)行離線場景數(shù)據(jù)的查詢；

實(shí)時(shí)鏈路則通過 Flink 加工后寫入到 Kafka 中，然后通過 Flink 消費(fèi)處理寫入到 StarRocks 中進(jìn)行實(shí)時(shí)表的查詢。

列更新（Partial Update），優(yōu)化性能同時(shí)降低資源消耗

StarRocks 的 Join 性能表現(xiàn)很好，不過頻繁的 Join 查詢會帶來計(jì)算資源的大量消耗?；诖耍瑅ivo IT 部門使用 Flink 將多個(gè)維表打平為大寬表，寫入 StarRocks 來進(jìn)行查詢，在節(jié)省 StarRocks 計(jì)算資源的同時(shí)，查詢體驗(yàn)也更好。

針對維表歷史數(shù)據(jù)變更的場景，他們使用 StarRocks 提供的部分列更新（Partial Update）功能，在 Flink 寫入主鍵模型大寬表的過程中，通過一些簡單的配置開啟部分列更新，實(shí)現(xiàn)以較小的代價(jià)靈活地更新大寬表中對應(yīng)的列數(shù)據(jù)。

集群監(jiān)控告警，靈活、便捷運(yùn)維

在常規(guī)的監(jiān)控告警方面，由于 StarRocks 提供了豐富的 Metrics 接口，便于Prometheus 采集并存儲 StarRocks 集群各個(gè)節(jié)點(diǎn)的狀態(tài)信息，以供 Grafana 生成各種可視化的 Panel。

另外 vivo IT 部門還會對集群的審計(jì) SQL 進(jìn)行采集分析，通過 ELK 將各個(gè) FE 節(jié)點(diǎn)的審計(jì)日志采集后寫入到 Elasticsearch 中，通過配置規(guī)則，篩選出其中的慢 SQL，推送到告警系統(tǒng)中，以提醒相應(yīng)的同事關(guān)注及優(yōu)化。

彈性方案，降本增效

vivo 的業(yè)務(wù)特點(diǎn)是業(yè)務(wù)訪問量存在波峰波谷，且波峰波谷之間的訪問量差異明顯、時(shí)間界限明顯，業(yè)務(wù)對訪問持續(xù)時(shí)間更短的波峰期性能要求高，服務(wù)器資源使用率考核壓力大。

對于國內(nèi)集群，vivo IT 部門采取了多集群的模式來分擔(dān)高峰期的查詢訪問量，通過負(fù)載均衡將流量分?jǐn)偟街鱾浼骸?/p>

海外集群則依賴于 StarRocks 的多副本高可用機(jī)制，采用各個(gè)節(jié)點(diǎn)輪詢升降配實(shí)現(xiàn)集群配置的擴(kuò)縮容。具體的流程如下圖所示，vivo IT 部門將整個(gè)流程通過代碼的方式嵌入到運(yùn)維平臺里，通過程序自動化調(diào)度執(zhí)行，提高擴(kuò)縮容執(zhí)行的效率。

結(jié)語

在過去兩年多的探索中，vivo 發(fā)現(xiàn) StarRocks 具有便捷運(yùn)維、便捷部署與彈性擴(kuò)縮容能力，同時(shí)提供了卓越的查詢性能，足以應(yīng)對高并發(fā)查詢場景。借助 StarRocks 數(shù)據(jù)庫，vivo 打造了實(shí)時(shí)大數(shù)據(jù)分析平臺，為業(yè)務(wù)實(shí)時(shí)分析提供高效支持。

在未來，vivo 將在云原生建設(shè)、存算分離等場景與 StarRocks 進(jìn)行更加深入的探索，以實(shí)現(xiàn)數(shù)據(jù)平臺的持續(xù)演進(jìn)，同時(shí)也將關(guān)注 StarRocks 社區(qū)的發(fā)展，與其他企業(yè)和開發(fā)者共同推動項(xiàng)目進(jìn)步。