vivo 湖倉架構的性能提升之旅

作者：郭小龍 vivo互聯網大數據高級研發工程師

導讀：本文整理自 vivo互聯網大數據高級研發工程師郭小龍在 StarRocks 年度峰會上的分享，聚焦 vivo 大數據多維分析面臨的挑戰、StarRocks 落地方案及應用收益。

在 即席分析 場景，StarRocks 使用占比達 70%，查詢速度提升 3 倍，P50 耗時從 63.77 秒縮短至 22.30 秒，查詢成功率接近 98%。

在 敏捷 BI 領域，StarRocks 已完成 25% 切換，月均查詢成功數超 25 萬，P90 查詢時長縮短至 5 秒，相比 Presto 提升 75%。

在 研發工具平臺 方面，StarRocks 支持準實時數據查詢，數據可見性縮短至 3 分鐘，查詢加速使 P95 延遲降至 400 毫秒，開發效率提升 30%。

vivo大數據多維分析場景面臨的挑戰

在即席分析方面，我們的解決方案主要基于 Spark 和 Presto 兩大計算引擎。作為 vivo 大數據研發治理平臺的重要組成部分，即席分析模塊因其高頻率的使用而顯得尤為關鍵。通過用戶調研我們了解到，現有系統存在查詢響應時間較長的問題，這直接影響了工作效率；同時，語法兼容性的不足也給用戶帶來了不便。因此，針對該模塊進行優化，以提升查詢速度和增強語法兼容性，已經成為我們團隊工作的重中之重。

在敏捷 BI 方面，我們采用Presto作為數據查詢引擎時，遇到了用戶反映查詢響應時間較長的問題，同時發現對這些查詢進行性能優化存在較大挑戰，找不到有效的方案。

在研效工具平臺方面，早期數據規模較小時，該平臺基于 MySQL 結合內存計算模式運行。然而，隨著數據規模的增長，這一模式已無法滿足業務需求。我們曾嘗試采用 ClickHouse 作為解決方案，但在實踐中遇到了諸多問題，最終未能落地。具體問題包括查詢性能低、內存計算易發生內存溢出、數據清洗與加工時間過長（通常需要多個小時甚至一天），以及實時更新和刪除流程復雜。計算邏輯較為繁瑣，用戶在構建報表時需要編寫大量 Java 代碼，消耗大量開發人力。這已成為一個常見的痛點。

此外，由于歷史原因，我們在用戶權限管理及計算資源分配方面長期缺乏有效的認證與管控機制。

Presto 相關痛點

在 Presto 方面，我們遇到的主要問題包括：

多級緩存能力較弱；
CBO（成本優化器）能力有限；
缺乏物化視圖及表級加速方案；
無物理隔離機制；
Coordinator 采用單點部署，存在單點故障風險；
經過 JVM 調優及集群擴容后，仍會周期性地出現相同或類似的問題；
社區活躍度較低，性能優化方案較少。

ClickHouse 相關痛點

雖然 ClickHouse 在寬表應用場景中表現優異，但在湖倉一體架構下的加速能力有限，且數據導入期間的存儲成本偏高，這成為用戶特別關注的問題。另外，ClickHouse 在 Join 操作上的處理能力有所欠缺，包括CBO（基于代價的優化）、Reorder（重排序）以及Runtime Filter（運行時過濾）等關鍵優化措施遲遲未能落地，導致 SQL 調優時常需手動調整用戶 SQL ，極大降低了用戶體驗。

與此同時，盡管 ClickHouse 提供了部分實時更新和刪除的功能，但這些特性的性能并未得到根本性提升，進一步影響了用戶體驗。SQL 兼容性也僅達到一般水平，而集群擴縮容流程復雜，尤其是在執行節點擴展、縮減或副本調整時，故障機器的恢復與替換需要大量的人工介入。即使存在一些解決方案，這些問題依然顯著影響運維效率，給用戶體驗帶來了負面影響。

經過大量組件調研、功能與性能測試、行業案例分析以及 StarRocks 社區的技術指導，我們最終選擇 StarRocks 作為新一代多維分析引擎，并確立其為湖倉加速的唯一標準。

StarRocks 優勢

StarRocks 在湖倉加速方面具備顯著優勢，支持標準 SQL 并兼容 MySQL 協議。其強大的 Join 處理能力、默認啟用的 CBO（成本優化器）優化規則、多級緩存機制，以及智能物化視圖加速，使其在復雜查詢場景下表現優異。此外，StarRocks 提供完整的資源隔離機制，最新的 3.3.5 版本更是引入了 CG Group CPU 硬隔離方案，進一步提升了資源管理的穩定性和可控性。

在運維方面，StarRocks 具備較高的易用性。無論是集群擴容還是縮容，僅需執行簡單的命令并進行觀察即可完成，極大降低了運維成本。可以看到，StarRocks 的諸多優勢正好彌補了 Presto 和 ClickHouse 的短板，有效解決了我們在 OLAP 領域所面臨的挑戰和痛點。

此外，我們的 OLAP 團隊經歷了從 Druid、Kylin、Presto 到 ClickHouse 等多種組件的演進，且當前維護多個 OLAP 組件，研發人力分散。為提升研發效率，我們未來專注于 StarRocks 和 ClickHouse 的使用，每一位研發人員都需要深入學習并熟練掌握這兩個核心組件。

StarRocks 服務建設落地的技術解決方案

上圖展示了 vivo 大數據平臺的整體架構，StarRocks 處在查詢層和數據存儲層，扮演著關鍵角色。

在查詢層，主要涉及即席分析、BI 報表、湖倉一體等應用，同時涵蓋基礎建設和業務系統。目前，查詢引擎包括 Spark、ClickHouse、Druid、Presto 和 StarRocks，未來 StarRocks 將完全替代 Presto。
在數據加工層，離線計算采用 Spark，實時計算則基于 Flink。數據存儲方面，涉及 Hive、Paimon、ClickHouse、StarRocks、Druid 和 HBase。其中，Druid 目前僅用于基礎設施監控及部分廣告業務，后續計劃逐步將相關場景遷移至 StarRocks 或 ClickHouse。
數據介質層主要包括 HDFS、自研對象存儲，以及 HDD 和 SSD 文件系統。右側則是公司自研的服務平臺，涵蓋數據開發、任務調度、實時計算等功能，并負責 StarRocks 的建庫、建表及物化視圖管理等操作。

湖倉查詢加速架構

上圖展示了最新的湖倉查詢加速架構。

在數據倉庫方面，我們主要采用 Hive，其中 90% 以上的表使用 ORC 格式，約 7%–8% 為 Text 格式。目前，我們正在推進 Text 表向 ORC 格式的遷移，目標是使 Hive 數倉中 99% 的表采用 Apache ORC。

Paimon 建設已持續約一年，目前 100% 采用 ORC 格式。在查詢加速層面，我們引入了 StarRocks 作為核心引擎。

在引入 StarRocks 過程中，ORC 格式的性能優化是首要任務。此前，StarRocks 在湖倉查詢加速（尤其是 Hive 查詢加速）方面的優化主要基于 Parquet 格式，但在 ORC 方面的優化相對較少。因此，我們針對 ORC 格式進行了專項優化，以提升查詢性能，使其更適用于現有的數據架構。

ORC 性能優化

當前使用 StarRocks 的用戶，Hive 數據格式基本上是 Parquet ，因此 StarRocks 在 Parquet 格式的優化上非常成熟，而對于 ORC 格式的支持相對較少。為了解決這一問題，我們與社區團隊緊密合作，共同解決了大量的性能和功能方面的問題，極大地提升了 ORC 格式 Hive 表的查詢性能。我們通過修改相關代碼并重放了數十萬條線上SQL，確保所有修改既準確又高效。

修復 ORC 數據多讀問題：優化了數據讀取邏輯，減少了不必要的數據讀取，顯著提升了查詢性能。
優化 ORC 延遲物化性能：通過延遲物化技術，減少了內存占用和計算開銷，進一步提升了查詢效率。
優化 ORC tiny stripe 處理：改進了 tiny stripe 的處理方式，提升了小文件的查詢性能，特別是在處理大量小文件時表現優異。
支持使用 column id 下推 search argument 謂詞：通過下推謂詞，減少了不必要的數據掃描，提高了查詢速度。
FE 打亂 scan range 順序：優化了 scan range 的調度順序，提升了探查 SQL 的性能，特別是在處理復雜查詢時效果顯著。
統一 Map Key 行為與 Presto 一致：調整了 Map Key 的行為，使其與 Presto 保持一致，確保了查詢的一致性和穩定性。
優化 ORC is null/is not null 謂詞下推能力：增強了對 is null 和 is not null 謂詞的下推能力，減少了不必要的數據讀取，提升了查詢性能。
降低 DataCache cache miss 后從遠端讀取的 IOPS ：優化了 DataCache 的緩存機制，減少了 cache miss 后從遠端讀取的 IOPS ，降低了網絡延遲，提升了整體性能。
Data Cache 異步填充：大幅降低緩存填充對數據讀操作的影響。
壓縮格式支持：vivo 數倉的Text格式占比：約 10%，ORC 格式占比約 90%，支持的壓縮格式繁多，包括 NONE、SNAPPY、ZLIB 、LZ4、ZSTD、GZIP、BZIP2、LZO、DEFLATE 等，我們與社區團隊緊密合作，共同解決了所有壓縮格式的兼容性問題。

通過這些優化措施，我們與社區團隊共同顯著提升了 StarRocks 在處理 ORC 格式 Hive 表的性能和穩定性，為用戶提供更加高效、流暢的查詢體驗。這些改進不僅解決了當前存在的問題，還為未來的性能提升奠定了堅實的基礎。

Data Cache 性能優化

在數據緩存優化方面，我們最終選擇了 NVME SSD 作為存儲介質，磁盤使用率達到 95%。在當前 StarRocks 3.2.5 版本中，我們提前引入了 3.3.x 版本的異步緩存寫入能力，并計劃在未來升級至最新版本，以進一步利用 Data Cache 相關特性，提升查詢性能。

在完成 ORC 格式的性能優化并準備正式上線時，我們在回放測試中發現查詢性能未達預期。進一步分析后，問題的復雜性在于回放過程中慢查詢的 SQL 特征并不固定，每次出現的慢 SQL 都有所不同，增加了問題定位的難度。

HDFS 慢節點性能優化

在優化過程中，我們回溯查詢日志，深入分析 BE 的 HDFS 訪問日志，最終發現大量 HDFS 超時問題。由于公司內部 HDFS 負載高，Spark、Flink 以及各種查詢任務都會對其造成較大壓力，從而影響查詢性能。

針對這一問題，我們嘗試調整超時時間，從 60 秒依次降低至 10 秒、5 秒、2 秒，并觀察性能變化。結果顯示，2 秒的超時時間在性能和穩定性方面表現最佳，但也導致少量失敗情況。進一步分析發現，部分 HDFS 數據節點（DataNode）存在較為普遍的慢節點問題，即使經過多次重試仍可能失敗。

為解決該問題，我們自研了動態重試機制，即：

首次重試：5 秒
第二次重試：10 秒
后續重試遞增

這一優化方案有效解決了 HDFS 慢節點導致的超時問題，確保了系統的穩定性和查詢效率。完成該優化后，我們順利完成 StarRocks 的正式上線，并實現了查詢性能的最大化提升。本次優化帶來的價值與收益見下文。

元數據緩存和性能優化StarRocks 上線后，我們發現了一個新的性能瓶頸，即元數據緩存導致的查詢延遲與結果一致性問題。我們的即席分析用戶主要是數據開發人員，他們在數據導入完成后，希望能夠立即查詢最新數據，但卻發現數據未能實時更新。

經過分析，我們發現開源版本的元數據緩存刷新周期較長，支持庫表級別和分區級別的定期刷新，但該刷新周期可能長達 1-3 小時，導致數據更新滯后。此外，范圍查找緩存機制影響了精確查找的查詢效率，使部分查詢無法及時獲取最新數據。

針對這一問題，我們自研了一套優化后的元數據緩存方案，并計劃通過配置開關的方式貢獻至社區。優化后的方案大幅縮短了元數據的刷新時間至 5 分鐘內，確保數據能夠更快更新。同時，我們調整了查詢緩存策略，使范圍查找和精確查找（為空）不再緩存，以保證查詢結果的準確性。此外，在 get_partitions_by_names 方法的優化上，我們采用了多線程查詢，有效提升了大跨度查詢的性能。

該優化方案上線后，成功解決了元數據查詢的性能問題，同時確保了查詢結果的一致性。

語法兼容在語法兼容性方面，我們采用了一套自研解決方案，目前 Presto 語法兼容性已達到 100%，確保用戶可以無縫遷移。對于 Spark 語法，我們的目標是實現 90% 以上的兼容性，目前已達到 85%，仍在持續優化中，以進一步提升兼容能力。

在 Paimon 兼容優化方面，我們在 StarRocks 3.2.5 版本中，將 Paimon 0.7.0 客戶端升級至 0.9.0，引入了 Caching Catalog 機制。升級后，Paimon 在并發查詢和單次查詢場景下，性能均提升 5 倍，大幅優化了查詢效率和系統穩定性。

內表&異步物化視圖工作

在高性能多表 JOIN 查詢場景下，ClickHouse 無法滿足我們的需求，同時我們還需要支持低時延數據攝入，頻繁的數據更新與刪除，以及物化視圖的多層 ETL 清洗和加工。此外，我們希望實現湖倉表與內表的聯邦查詢，以提升查詢效率并優化數據處理流程。

在研發工作方面，我們主要開展了三項關鍵優化：

首先，我們將 StarRocks 從 3.2.5 版本升級至 3.3.5，解決了庫鎖和死鎖問題，并優化了物化視圖的刷新邏輯，使其支持多事實表刷新。此優化上線后，成功解決了某業務場景中的長期問題，系統現已穩定運行。此外，我們修復了部分物化視圖改寫問題，并引導用戶使用分區刷新策略，降低刷新頻率，以提高系統整體性能。

其次，我們基于 3.3.5 版本，構建了物化視圖測試方案，并整理了相關的使用樣例與指導手冊，幫助用戶更高效地利用物化視圖功能。

StarRocks 組件建設

StarRocks 組件建設共分為三個階段：基礎能力建設、穩定性建設和運營指標建設。

基礎能力建設

在版本管理上，我們選擇3.2.5作為集群版本，版本代碼在 GitLab 中維護。認證與鑒權利用大數據研發治理平臺的鑒權系統、公司的權限系統以及 Hive 鑒權，實現了統一的認證機制。
關于功能管理，相比 Presto ，StarRocks 擁有更強大的功能集。但在項目初期，我們選擇僅開放查詢功能，并對DDL和DML操作加以限制，以降低誤操作對集群穩定性的影響。后續，將通過內部平臺化的流程管理和逐步解禁這些功能。
我們的目標是在SQL兼容性支持上，構建圍繞 StarRocks 、Trino 和 Spark 為核心的統一語法體系，從而實現更流暢的互操作性和更高的開發效率。

穩定性建設

采用 systemd 進行進程管理，確保進程異常退出后能夠自動拉起，并配備監控腳本進行啟停監測。系統可在進程崩潰時觸發告警并自動恢復。同時，具備自動化 crash 監測與恢復能力，能夠識別 BE 進程異常并進行分析和修復。目前 BE crash 發生率較低，但仍保持持續監測。
在監控告警體系中，依托主機級告警與 Grafana 監控，初期設定較低的告警閾值，以便及時發現潛在問題，并在優化過程中逐步調整至合理范圍。

運營指標建設

注重平臺化管理。研發人員及數據產品經理可通過統一平臺完成建庫、建表及物化視圖創建等操作，以提升管理規范性。StarRocks 兼容內表、外表，并支持 Hive 和 Paimon。因此，對日報、周報、月報等運營指標進行分類管理，并定期（每周或每季度）進行分析和優化。
在審計日志管理上，我們基于開源審計日志框架進行了擴展，新增了記錄用戶查詢唯一ID、查詢用戶和查詢屬性等關鍵字段。系統自動保存慢查詢的Profile，并記錄HMS接口調用（例如 getTable 、getPartition ）及其相關的性能指標。此外，我們還對存儲數據的性能進行了統計分析，旨在發現可能的性能瓶頸并優化資源配置。所有成功落地的優化方案都會被歸檔，為后續 StarRocks 相關功能的推廣提供支持。

此外，基于業務需求，我們開發了一些重要的自研功能。由于手機廠商對用戶信息的高度安全性要求，所有內部數據都采用加密字段存儲。為了讓 StarRocks 能夠替代 Presto 和 Spark 的部分能力，必須支持對加密數據的讀取與處理。為此，我們在BE模塊中對Apache ORC的版本進行了優化，使其能夠通過密鑰讀取Hive中的加密字段。此功能的實現加快了 StarRocks 在數據分析場景下替代Presto的進度。

引入 StarRocks 的效果和收益

即席分析切換歷程

在介紹即席分析的收益之前，先回顧整個切換過程。

2024年1月：切換專項成立進行價值分析與目標討論，明確即席分析切換的核心目標和工作計劃。
2月-3月：性能攻關階段

解決 ORC 格式 Hive 表的功能及性能問題。

進行 HDFS 慢節點分析與優化。

重放SQL快速測試能力建設。

解決結果一致性問題，并進行雙跑測試。
4月：灰度 5% 階段

使用 StarRocks 3.2.5 版本進行灰度測試。

處理兼容性問題，部分回滾至 Presto。

上線內部認證與鑒權方案。
5月：灰度 50% 階段

ORC 解密上線。

成本賬單方案上線。

查詢性能優化，兼容性提升至 97%。
6月-7月：灰度 100% 階段

Presto 正式下線，StarRocks 作為核心分析引擎。

解決 Spark 常用函數兼容問題。
8月至今：StarRocks 查詢占比持續提升

查詢占比從 40% 提升至約 70%-80%。

落地 HMS 元數據緩存優化方案。

資源隔離方案逐步實施。

解決 BE 內存熔斷與查詢超時問題。

即席分析引入 StarRocks 收益

在即席分析場景中，StarRocks 的使用占比已達到 70%，相較于 Spark（占比 30%），在查詢性能和穩定性方面展現出顯著優勢。P50 耗時方面，StarRocks 取得了革命性的優化，從 7 月份的 63.77 秒縮短至 22.30 秒，效率提升 65.06%，整體查詢速度提升了 3 倍。

目前，數據趨勢呈下降態勢，我們預計在 StarRocks 占比提升至 80% 后，P50 耗時將實現 4 至 5 倍的性能提升。此外，與 Presto 相比，StarRocks 在查詢穩定性方面更具優勢，查詢成功率已接近 98%，顯著減少了查詢失敗的情況。

敏捷 BI 引入 StarRocks 收益

在敏捷 BI 領域，我們已完成 25% 的切換，月均查詢成功數超過 25 萬次，查詢成功率穩定在 99% 以上。目前，StarRocks 已覆蓋 12 個業務領域，支撐超過 600+ 用戶，并大幅優化查詢效率：

慢查詢（>30 秒）從 2.99% 降低至 1.32%
P90 查詢時長降至 5 秒以內，相比 Presto 的 16 秒，提升 75%，整體性能提升 4 倍

該優化仍在持續推進，我們預計隨著 StarRocks 的進一步優化和應用，查詢性能和穩定性將得到更大提升。

即席分析是我們在查詢性能優化方面面臨挑戰最大的項目，而敏捷 BI 則是我們覆蓋業務范圍最廣的項目。這兩個項目的成功讓我們更加堅定地推進 StarRocks 的應用，我們有信心將其它 Presto 相關項目全面遷移 StarRocks，進一步提升整體查詢性能和系統穩定性。

研發工具平臺引入 StarRocks 的收益

在研發工具平臺中，我們成功構建了 準實時業務庫，使數據從寫入到報表可見的時間縮短至 3 分鐘以內，相比之前的 數小時甚至 T+1 級別，數據可用性大幅提升。

我們基于 物化視圖 實現了數據分層和加工邏輯，開發效率提升約 30%。這一數據是較為保守的估計，隨著用戶對流程的熟悉度提升，預計 效率提升可達 50% 以上。過去，用戶開發報表需要編寫大量 Java 代碼，而現在，僅需配置實時任務并創建物化視圖，即可完成報表開發，極大降低了開發成本。

在數據處理方面，我們通過 Flink CDC 實現數據的準實時寫入，所有需求任務的變更會實時同步至 StarRocks ODS 層基表，并通過多個物化視圖逐步流轉至 DW 層、DM 層、DA 層、ADS 層，最終為用戶提供高效的報表查詢能力。借助 StarRocks 的查詢加速，P95 查詢延遲降低至 400 毫秒。此外，Flink 與 StarRocks 的雙鏈路融合進一步提升了準實時度量能力。

該項目在公司內部獲得了高度認可。作為研發工具平臺能力建設的重要組成部分，其成功落地有效推動了降本增效，進一步提升了企業數據基礎設施的價值。

StarRocks在vivo大數據平臺的未來規劃

Presto 集群切換規劃

我們計劃于 2024 年 12 月 完成 Presto 至 StarRocks 遷移的 30%，目前已完成 25%。由于前期遷移涉及流程梳理和技術攻堅，進展較為緩慢，但后續預計會加速推進。2025 年 6 月，StarRocks 的遷移占比預計達到 80%，年底前完成 100% 遷移。

我們將在遷移過程中持續優化 StarRocks on K8s 的能力，并總結敏捷 BI 和即席分析的實踐經驗，推廣至更廣泛的業務場景。最終，我們計劃將 廣告、AI、DMP 等業務的 Presto 集群 逐步替換為 StarRocks。基于即席分析和敏捷 BI 項目的成功經驗，我們對全面替換 Presto 充滿信心。