繼去年 Streaming Lakehouse Meetup 順利舉辦後，Streaming Lakehouse Meetup · Online EP.2｜Paimon × StarRocks 共話實時湖倉 於12月10日重磅迴歸。在這場直播中，阿里雲計算平台事業部開發工程師張慶玉聚焦 StarRocks 與 Apache Paimon 的深度集成實踐，探討如何構建真正意義上的 Lakehouse Native 數據引擎。
在數據湖已成為企業數字化轉型重要基礎設施的當下，如何在一個統一的計算引擎中高效處理多種數據源，成為業界關注的焦點。StarRocks 通過與 Paimon 的深度融合，正逐步構建一套完整的 Lakehouse Native 解決方案——不僅支持多源聯邦分析，更在性能、功能與可觀測性上實現系統性突破。
StarRocks 數據湖總體架構：單一引擎，多源聯邦分析
StarRocks 與 Paimon 的結合，首先體現在統一的架構設計理念上。藉助統一的 Catalog 機制，StarRocks 能夠在一個引擎內同時管理內部表和外部數據湖（如 Paimon 表），並支持跨 Catalog 的聯邦查詢。
這種設計延續了 StarRocks 存算分離的核心思想。雖然數據存儲在遠端的數據湖中，但查詢執行仍能充分利用 StarRocks 在 OLAP 場景下的全部優化能力——從底層的 CPU 指令集加速、向量化執行引擎，到 IO 層面的緩存策略與合併讀取，都可無縫應用於 Paimon 表的查詢過程。這使得數據湖不再只是“冷存儲”，而真正成為高性能分析的一部分。
StarRocks+Paimon 發展歷程
StarRocks 對 Paimon 的支持並非一蹴而就，而是經歷了多個版本的持續打磨。
- StarRocks 3.1: 首次引入 Paimon 外表，通過 JNI （Java Native Interface）實現基本讀取能力，並支持 Paimon 物化視圖加速查詢和謂詞下推。這一階段主要解決“能不能用”的問題。
- StarRocks 3.2: 性能迎來顯著提升—— FE 計劃階段引入 Metadata cache，緩存表分區和 manifests 等元數據，大幅加快計劃生成；同時支持表級與列級統計信息採集，提升執行計劃質量。3.2 版本還實現了物化視圖的分區級別刷新功能，避免了全量刷新帶來的資源浪費。此外，該版本進一步增強了對 Paimon DV 表的支持——StarRocks 查詢引擎現在可以通過 Native Reader 直接讀取 DV 表，相比之前基於 MOR（Merge-On-Read）表結構的 JNI 讀取實現，讀取性能獲得大幅提升，尤其適用於高吞吐、低延遲的實時分析場景。
- StarRocks 3.3: 標誌着 StarRocks 向 Lakehouse Native 邁出關鍵一步，多項核心特性相繼落地——相關細節將在下文逐一展開。
StarRocks+Paimon 最新進展
功能增強
- Time Travel：StarRocks 現已支持通過
VERSION AS OF或TIMESTAMP AS OF查詢歷史快照或指定時刻的數據。這一能力在數據審計、故障回滾、AB Test 等場景中具有重要價值，讓數據湖具備了更強的時間維度管理能力。
- Paimon Format Table：作為 Paimon 的一種兼容 Hive 格式的表類型，它允許用户將現有 Hive 表直接遷移到 Paimon，而 StarRocks 能無縫識別並高效查詢，極大降低了遷移成本。
性能優化
- Native Reader/Writer: 在未開啓 DV 的情況下，MOR 表需要在查詢時實時合併多個版本的增量數據，只能通過 JNI 調用 Java 層處理，存在類型轉換、行列格式轉換、JVM GC 等開銷，效率低下且易引發 OOM。如今，StarRocks 基於 Paimon CPP SDK，在 BE 的 C++ 代碼中直接實現 Paimon Native Scanner，實測顯示 MOR 表讀取性能提升超過 5 倍。寫入側同樣受益，Native Writer 顯著提升了寫入吞吐。
Paimon Native Reader
Paimon Native Writer
- Distributed Plan: 面對超大規模表（數十萬文件），manifest 解析曾是 FE 的性能瓶頸。為此，StarRocks 引入 Distributed Plan 機制，當 manifest 數量過多時，FE 將解析任務分發至多個 CN 節點並行執行，各節點完成本地謂詞下推後返回所需文件列表。這一設計使 plan 階段的解析能力隨 BE 資源線性擴展，有效緩解單點壓力。
- DV Index Cache: 在高併發查詢 Paimon 主鍵表時，index manifest 的全局反序列化會造成嚴重讀放大——即使只查一個分桶，也要加載全量索引。於是，DV Index Cache 應運而生：按桶級別緩存 DV index 對象，避免重複解析。由於緩存的是 Java 對象而非序列化字節，還省去了反序列化開銷。實測表明，該優化在高併發場景下 QPS 提升超 80%。
主鍵表點查在高併發下導致 FE CPU 和內存負載過高，主要因 Plan 階段頻繁從緩存讀取 index manifest
可觀測性：完善profile指標
StarRocks 完善了 Profile 指標體系，覆蓋 plan 與執行兩個階段。在 plan 階段，用户可查看 manifest 緩存命中率、遠程讀次數、謂詞下推效果及最終掃描文件數，用於判斷是否需調大緩存或優化查詢條件。在 BE 執行階段，則能清晰區分 JNI 與 native 讀取的比例——若 JNI 佔比較高，可能提示需要對錶進行 full compaction，或考慮切換至 DV 表模式。
未來規劃：性能對齊內表
StarRocks 團隊的長期目標很明確：讓查詢 Paimon 的性能與體驗對齊查詢 StarRocks 本地表。
目前，BE 執行層的差距已不大——兩者均基於列存格式（如 Parquet/ORC），具備類似索引結構，IO 優化策略也高度通用。真正的挑戰在於 FE 的 plan 階段：Paimon 的 manifest 解析可能因 cache miss 觸發高延遲的遠程讀，導致 plan 耗時波動，影響整體查詢穩定性。
未來工作將聚焦於消除 plan 階段的 latency-sensitive IO，通過更智能的緩存預熱、異步解析、元數據壓縮等手段，使 Paimon 查詢的延遲變得穩定、可預測，徹底告別“毛刺”。
結語
StarRocks 與 Paimon 的深度融合，代表了現代湖倉架構的重要演進方向。它不只是“能查數據湖”，而是真正“懂數據湖”——從架構統一、功能完善到性能極致優化，每一步都圍繞真實業務場景展開。
這套 Lakehouse Native 方案已在阿里集團內部多個高併發、低延遲場景中落地驗證，為電商、物流、金融等業務提供堅實支撐。隨着社區生態的持續壯大，我們有理由相信，StarRocks + Paimon 將成為企業構建下一代實時數據平台的核心引擎。
