作者：林豪，愛奇藝大數據 OLAP 服務負責人

小編導讀：

本文整理自愛奇藝工程師在 StarRocks 年度峯會的分享，介紹了愛奇藝 OLAP 引擎演化及引入 StarRocks 後的效果。

• 在廣告業務中，StarRocks 替換 Impala+Kudu 後，接口性能提升 400%，P90 查詢延遲縮短 4.6 倍。
• 在“魔鏡”數據分析平台中，StarRocks 替代 Spark 達 67%，P50 查詢提升 33 倍，P90 提升 15 倍，節省 4.6 個人天。

愛奇藝 OLAP 體系簡介

愛奇藝數據分析場景

在愛奇藝的大數據分析場景中，通常需要實現兩個核心目標：一是看過去，包括生成報表、分析劇集熱度以及會員運營等；二是知未來，即預測用户增長和預估收入。雖然我們的最終目標是精準預測未來，但由於這一任務難度較大，我們更多地是通過精準的報表和歷史數據分析，挖掘數據中的潛在價值，從而為未來決策提供支持。

愛奇藝 OLAP 架構

上圖是愛奇藝 OLAP 架構的總體設計。底層存儲層包括傳統的 Hive（用於離線存儲）和 Kafka（用於實時數據倉庫），近年來還引入了 Iceberg 作為近實時的存儲解決方案。在存儲層之上是多種查詢引擎，隨着 OLAP 引擎的快速發展，我們引入了多種引擎以滿足不同需求。再往上是我們自研的智能 SQL 網關，它可以屏蔽底層眾多引擎的接入細節，最上層則是各種應用場景。

如此多樣的引擎帶來了巨大的運維負擔。因此，我們需要對引擎進行整合，以降低運維複雜性。

愛奇藝 OLAP 引擎演化

接下來，我將從兩個角度介紹我們引擎的發展歷程：傳統數倉（存算一體）場景 和 數據湖（存算分離）場景。這種劃分並非絕對，而是基於實際需求和客觀約束形成的兩種技術形態。

在數倉場景中，我們通常需要滿足高併發、低延遲的在線查詢需求，因此需要獨立的存儲。早期，我們使用 MySQL 或 Elasticsearch（ES），但 MySQL 的規模較小，而 ES 則是性能較差。隨後，我們引入了 Impala 結合 Kudu，雖然性能有所提升，但規模仍受限。對於大規模時序數據，我們引入了 Druid，但它不支持明細查詢和 Join 操作。為了追求極致性能，我們又引入了 ClickHouse。

在數據湖場景中，我們更多地用於即席分析和故障排查等場景，這些場景對性能要求不高，但對數據規模和成本控制要求較高。最初，我們使用 Hive，隨着需求增長，我們引入了 Spark 和 Trino。然而，近期我們發現 StarRocks 能夠實現數倉和數據湖計算引擎的統一。在數倉場景中，StarRocks 能夠達到與 ClickHouse 相當的查詢性能，同時替代 Druid，支持大規模數據下的明細分析。在數據湖場景中，StarRocks 的性能也優於 Spark 和 Trino。

高性能實時數倉：StarRocks vs. ClickHouse

接下來，我將介紹在數倉場景中實時數據處理的典型應用。以我們內部的廣告場景為例，其核心需求是高併發、低延遲和數據一致性。在傳統的 Lambda 架構中，我們同時進行實時數據寫入和離線數據覆蓋，以處理反作弊等行為。早期，我們使用 Kudu 和 HDFS 分別保存實時和離線數據，並通過 Impala 提供統一查詢接口。這一方案在很長一段時間內能夠滿足業務需求。

然而，隨着數據量的持續增長和查詢頻率的提升，現有方案的性能瓶頸愈發明顯。為了追求更高性能，我們考慮了 ClickHouse，但其在數據一致性方面存在不足，最終選擇了 StarRocks。接下來，我將詳細闡述為何放棄 ClickHouse，轉而選擇 StarRocks 來滿足這一場景需求。

ClickHouse 和 StarRocks 在很多方面有相似之處，例如它們都追求極致性能，採用 MPP 架構，支持向量化執行和物化視圖。但今天我更想強調它們的不同點，尤其是 ClickHouse 的侷限性。主要問題可以歸納為三個方面：數據一致性問題、存算分離的支持程度以及運維複雜度。以下我將分別展開討論這三個方面：

數據一致性

第一個問題是數據一致性。假設我們使用 Flink 從 Kafka 消費數據並寫入 ClickHouse，其官方的連接器通常只能保證“至少一次（at least once）”的語義。這意味着當 Flink 任務因集羣或節點問題重啓時，可能會導致 ClickHouse 中的數據重複。相比之下，StarRocks的 Flink 連接器支持“精確一次（exactly once）”語義，這是一個非常重要的特性，能夠有效避免數據重複問題。

此外，我們需要通過離線數據覆蓋實時數據，例如在反作弊處理後校準實時數據。然而，ClickHouse 的分佈式表不支持原子替換操作，替換時需逐個節點操作，增加了複雜性。如果臨時表數據為空，可能導致空數據覆蓋目標表。雖然可以通過技術手段解決，但無疑增加了數據流程的複雜性。StarRocks 在這方面表現更為出色，支持分區級別的原子替換操作，確保離線覆蓋時的安全和高效。

湖倉融合特性

接下來討論第二個特點：湖倉融合能力。湖倉融合是當前數據處理領域的一個重要趨勢，許多企業都在探索如何更好地整合數據湖和數據倉庫。

雖然 ClickHouse 支持湖倉查詢，但其能力相對有限，主要通過外部表訪問數據湖，而非通過統一的 Catalog 管理。此外，在與 Iceberg 等數據湖技術的集成上，ClickHouse 的支持並不友好。下面我使用一個場景來做對比：

上圖展示的是一個故障級降級場景：業務通過 Hive 離線同步到 ClickHouse 提供日常服務。如果要為此業務提供高可用方案，ClickHouse 通常需要搭建災備集羣並進行數據同步，主集羣故障時切換到災備集羣。這種方案成本高且需額外管理同步鏈路。

相比之下，StarRocks 的方案更簡單。當主集羣故障時，只需啓動一個 StarRocks 彈性計算集羣，並通過外表模式直接訪問 Hive 表。關鍵在於訪問 Hive 外表的性能能否接近 StarRocks 內表的性能。我們的測試表明，在大多數查詢場景中，StarRocks 訪問 Hive 外表的性能能夠與內表相近，甚至在某些大數據規模場景下（如 Q2），直接查詢 Hive 外表的性能更快。

運維複雜度--擴縮容

最後討論運維複雜性，尤其是集羣的擴縮容問題。ClickHouse 在這方面更像“手動擋”汽車，需要大量手動調優。擴容時，ClickHouse 的歷史數據無法自動重新分佈，只有新數據會自動分配到新節點。若某節點宕機，需手動處理，否則可能導致副本數量不足，甚至數據丟失。此外，ClickHouse 的縮容操作幾乎無法實現。

相比之下，StarRocks 在擴縮容方面更為自動化，類似“自動擋”汽車。StarRocks 支持無縫擴縮容，能夠自動進行數據均衡，節點宕機或縮容時，StarRocks 能自動同步副本，無需人工干預。

引入 StarRocks 與上線效果

在引入 StarRocks 後，我們的整體架構如下：

1. 集羣部署：同時部署物理機上的存算一體集羣和彈性計算集羣，滿足高性能需求並具備靈活擴展能力。
2. 緩存優化：當前使用基於 Alluxio 的緩存機制，未來可能引入 StarRocks 自帶的 DataCache 緩存機制或結合 Alluxio 進行對比測試。
3. 智能 SQL 網關：在架構上層部署自研的智能 SQL 網關，屏蔽底層引擎的複雜性（如用户名和密碼等細節），支持高可用性（HA）並基於集羣健康度和性能動態調度。查詢攔截功能通過網關實現，所有 SQL 查詢都通過網關處理，為未來的性能優化和物化視圖分析提供數據基礎。

廣告業務上線效果：

在廣告業務場景中，我們將原有的 Impala+Kudu 替換為 StarRocks 後，接口性能顯著提升，整體性能提升了 400%，P90 查詢延遲加快了 4.6 倍。

湖上即席查詢：從 SparkSQL 到 StarRocks

引擎選擇

愛奇藝內部有一個名為“魔鏡”的一站式數據分析平台，每天支持 500+ 用户和 1400 多個查詢。此前，我們使用 Spark 查詢引擎進行即席查詢，性能較慢，導致分析師在交互過程中需要等待數據返回，嚴重影響了分析效率。經過評估，我們發現每天因查詢延遲浪費的分析師人力相當於 12.5 個人天。

在 SQL 引擎方面，我們原本計劃從 Spark 切換到 Trino，但鑑於兩者語法差異較大，最終決定直接切換到 StarRocks。經過測試，StarRocks 不僅與 SparkSQL 兼容性良好，性能也比 Trino 快 2 到 3 倍。

Pilot 雙跑平台

我們進行切換的核心目標是對業務完全透明，讓業務方感知不到底層使用的是 Spark 還是 StarRocks。為此，我們依託內部的 Pilot 雙跑平台，該平台支持多種場景需求，如引擎切換、版本升級、參數驗證以及機型選擇變更等。

整個切換流程大致分為四個階段：

1. SQL 集合篩選：從歷史 SQL 執行記錄中，通過篩選或手動錄入的方式，圈定需要雙跑的 SQL 集合。
2. 配置實驗：定義對照組（Spark）和實驗組（StarRocks）。為每個 SQL 分別生成子任務，分別在對照組和實驗組中執行。
3. SQL 改寫與執行：對 SQL 進行改寫，例如將寫入線上表的語句改為寫入臨時表，避免影響生產環境。所有子任務執行完成後，我們會進行行列級別的數據校驗，只有數據完全一致才視為對數通過。
4. 生成實驗報告：對於通過驗證的 SQL 集合，我們可以進行切換；對於未通過的集合，我們會分析具體問題，並進行參數調優。

上圖 Pilot 雙跑平台的頁面示意圖清晰展示了每個子任務的耗時和對數結果。如果發現某個子任務失敗或數據不一致，可以通過詳情頁面查看具體細節。雙跑平台極大地簡化了我們的數據切換工作。

雙跑對數-5 輪結果彙總

我們對歷史數據進行了多輪對數驗證，並將 Spark 與 StarRocks 的切換情況分為以下三種場景：

1. 切換到 StarRocks 後執行失敗：這種情況可以接受，可能由於 UDF 不支持、語法兼容問題或數據規模較大等原因導致。如果 StarRocks 執行失敗，平台會自動降級到 Spark 執行，從業務感知上來説，最終 SQL 仍然執行成功。因此，只要將失敗比例控制在較低水平即可。
2. StarRocks 執行成功，但數據存在不一致：這種情況不能接受，因為用户無法判斷哪些查詢可以切換到 StarRocks。因此，修復數據不一致問題非常重要。我們最終修復了 13 個不一致問題，將不一致的比例從 19% 降低到 0%。
3. StarRocks 執行成功且數據一致：這是我們追求的理想場景。在雙跑驗證中，最終能夠成功切換的比例約為 78%。

對數不一致常見問題

• 精度問題：某些字段最初的小數保留位數較少，經過調整後，我們增加了保留位數，從而實現了數據的一致性。我們設定了一個標準：精度誤差不超過萬分之一，即可視為一致。
• 函數語義不同：例如，from_unixtime 函數在不同系統中的支持類型有所不同。StarRocks 官方支持的類型有限，而我們在生產環境中遇到了多種類型，因此我們對其進行了擴展支持，以確保兼容性。類似的，日期函數和 split 函數的適配也遵循這一原則，確保能夠支持類似正則表達式的識別功能。

• 其他：例如數組的起始下標或類型轉換。以 StarRocks 為例，如果嘗試將一個帶有小數點的值轉換為 BIGINT，Spark 能夠正確處理，但 StarRocks 會返回 NULL。

切換效果

針對上述提到的一些問題，我們已經進行了修復，以下是修復後的上線效果：

目前，StarRocks 的切換比例為50%。這一比例尚未達到更高，並非因為存在技術限制，而是許多業務在查詢時明確指定了使用 Spark 引擎。現階段，我們優先尊重業務的指定選擇。未來，我們會積極推動業務逐步提高使用 StarRocks 的比例。

在已切換的業務中，StarRocks 成功替換 Spark 的比例約為67%，即三分之二左右。這一比例略低於我們此前雙跑測試時的預期，但對於切換成功的部分，效果非常顯著：P50 查詢速度提升了 33 倍，P90 查詢速度提升了 15 倍。

此外，我們通過優化節省了 4.6 個人天。從柱狀圖中可以看出，前兩個柱子代表純 Spark 的查詢，後面的柱子代表部分切換到 StarRocks 後的查詢。切換到 StarRocks 後，查詢耗時大幅減少，節省了大量時間。

未來展望與規劃

存算一體

• 技術升級：我們將升級至3.3版本，並驗證物化視圖的加速效果，同時考慮引入分級存儲，將歷史數據轉存到 HDFS。
• 引擎收斂：未來一年，我們將重點替換 ClickHouse 和 Druid，逐步統一數據處理引擎，降低運維複雜度。

存算分離

• 擴大規模：目前切換成功比例為三分之二。未來，我們將擴大切換規模，解決 UDF 兼容性不足的問題，進一步提升切換成功率。
• 性能優化：針對外表查詢性能不夠理想的情況，我們將通過物化視圖實現透明加速，並計劃替換 Trino 引擎，提升整體性能。

更多交流，聯繫我們：https://wx.focussend.com/weComLink/mobileQrCodeLink/33412/2b42f