一、開源 OLAP 綜述

近年來開源領域涌現出了眾多優秀產品，如 StarRocks、Doris、湖數據、湖格式、Spark 以及早期的 HBase、Presto 等。種類繁多的開源工具為用戶帶來了便利，同時也帶來了選擇難題。

上圖中對各種數據庫做了簡單的分類。例如，StarRocks、Doris 和 CK 等，它們在過去主要是存算一體的 AP 數據庫。而 Presto、Trino 和 Impala 等則是經典的基于 Hadoop 的 MPP 引擎。此外，Kylin、Hbase 和 Druid 等在預處理方面有較多應用。還有一類是近年來流行的湖格式（湖存儲）工具，其中包括 Delta lake、Hudi、Iceberg，以及幾個月前剛孵化的 Apache Paimon 等。

二、OLAP 場景思考

OLAP 場景涉及的技術棧眾多，應該如何選擇呢？回答這個問題，首先從場景層面去思考。OLAP 涉及的典型業務場景包括，面向用戶的報表、面向經營的報表、用戶畫像、運營分析、訂單分析以及自助分析等。

面向廣告主、門店經理以及 ToB 端的報表業務，這些場景有一個共同特點，即需要根據用戶的 User ID 等屬性進行快速檢索，對查詢性能有較高要求，同時存在一定量的并發請求。當然，這里的并發與 ToC 的場景有所不同。

針對這些特點，一款優秀的 OLAP 引擎在技術上應滿足以下要求：首先，具備前綴索引功能，這樣在構建好索引之后，查詢性能將得到顯著提升；其次，向量化引擎也是一個重要趨勢，最早由 CK 提出，如今許多引擎都在朝這個方向發展，向量化確實能夠在很大程度上提高查詢速度；此外，數據分布的均衡和自動反向處理也是關鍵，有助于避免數據傾斜等問題。

經營報表類場景中，例如實時大屏展示、實時風控、實時監控和審計等業務，它們的核心需求是數據的實時性，即在業務數據寫入后，盡可能早地獲取到這些數據。實時性的重要性在于，它會影響后續策略響應的速度。同時，在查詢過程中，我們希望查詢性能足夠優秀。

此外，這些業務還有一個重要特點，即需要對接商業化的 BI 工具。這意味著我們的 SQL 處理流程需具備較高的多樣性，以滿足不斷變化的分區需求。在此基礎上，我們還需要對數據模型進行精細設計，以滿足多樣化的需求。

末端運營分析類場景，例如鏈家等企業的經紀人績效計算以及買菜類應用的團長報表等。這些業務的一個共同特點是，經紀人不斷變動，組織架構頻繁調整，導致尾表變化愈發頻繁。

此外，這些業務對查詢性能和數據可見性有一定要求。最重要的特點是計算邏輯復雜，即 join 條件繁多。因此，OLAP 引擎要能夠支持靈活的數據模型，而不僅僅局限于大寬表。針對新型 join 支持方面，當前市面上的部分產品仍不夠完善。為了提升性能，大家普遍希望在物化視圖等方面具備一定能力。

在用戶畫像這一業務場景中，面臨的主要需求是大寬表的處理。CK 引擎在用戶畫像領域得到了廣泛應用。然而，某些場景下需要處理不同標簽的組合查詢。此外，用戶畫像業務對精確去重有較高要求。

從引擎側來看，需要支持大寬表以滿足業務需求。然而，更新大寬表時，不能每次都能更新兩三千列數據，因此更新能力顯得尤為重要。此外，多流 join 支持以及 join 查詢能力優化也是關鍵。在此基礎上，還要求引擎支持 bitmap 精確查詢，以滿足用戶畫像業務的高效處理需求。

訂單分析場景中，數據實時性和復雜的查詢邏輯是兩個核心要點。實際上，回顧前面提到的各個場景，我們會發現訂單分析場景與其他場景在業務特點和技術要求方面存在一定程度的共性。

訂單分析業務對實時性有較高要求，以便快速響應業務變化。同時，由于訂單數據的豐富性和多樣性，查詢邏輯往往較為復雜。這意味著我們需要為訂單分析場景提供高性能、易用且支持復雜查詢的解決方案。

在打造一款 OLAP 引擎產品時，需要重點關注以下幾個基礎方面：

首先，強化多表關聯（join）的能力支持，包括功能層面的語法支持和性能層面的優化。多表關聯是 OLAP 查詢的核心環節，對于處理復雜數據場景至關重要。

其次，現代化引擎解決方案的必備能力，如 CBO（Cost-Based Optimization）和向量化查詢等。這些能力可以使產品在市場上具有競爭力，更好地解決各類業務場景問題。

此外，并發能力也是一項重要指標。在高并發場景下，OLAP 引擎需要具備穩定的性能表現和擴展性。在數據寫入方面需要提高性能，高效的數據寫入能力有助于 OLAP 產品更好地滿足業務場景需求。

其他方面包括功能和架構的優化，如開發效率、UDF（用戶自定義函數）支持等。以 Java UDF 為例，相比 C++ UDF，Java 的易用性更高，有利于提高開發效率。

最后，還要考慮架構的運維便利性。良好的 OLAP 產品應具備簡潔的運維方式，便于平臺側進行管理和維護。

三、開源數據湖/流式數倉解決方案

下面介紹阿里云 EMR（E-MapReduce）平臺上常見的開源數據倉庫及數據湖的架構。首先，來介紹一下 EMR 的整體架構。

EMR 基礎架構的最底層是云資源，主要包括 ECS（彈性計算服務）和 ACK（阿里云容器服務）。在此基礎上，我們采用調度器來協調和控制數據處理流程。此外，我們還提供 JindoFS，這是一種與 Hadoop 兼容的分布式文件系統，便于用戶存儲和管理數據。

接下來進一步討論阿里云 EMR 平臺上計算引擎的多樣化應用，包括離線批處理、實時 Flink 以及 OLAP 相關引擎。

目前，典型的數據倉庫架構仍以離線批處理為主。這種架構中，實時數據通過 CDC 技術收集，并通過 Kafka 等消息隊列傳輸至 Flink 等實時處理引擎。經過處理后的數據直接落地到 OLAP 引擎，以支持快速數據分析。

離線部分主要包括 ODS/ DWD 等分層，采用傳統的 Hive 技術進行數據處理。然而，這種架構中實時與離線數據處理相對獨立，因此數據對齊成為一個常見問題。

為解決這一問題，近年來興起了近實時數據湖架構，如 Delta、Iceberg、Hudi 等。這些新型數據存儲格式旨在提高數據存儲和處理的性能，同時簡化數據對齊問題。新興的 Apache Paimon 也為解決數據對齊問題提供了有效支持。

實時數據湖架構也是 EMR 平臺上常見的一種數據處理架構。在這種架構中，實時數據從 CDC 模式或直接從 Kafka 攝入，并在各個層次上進行增量處理。相較于 Lambda 架構，實時數據湖架構在數據鏈路上實現了統一，從而降低了數據校驗等環節的工作量。

在這種架構中，常見的 OLAP 查詢引擎直接訪問數據湖，或者作為末端的 ADS層為業務部門提供服務。通過實時數據湖架構，企業可以更高效地處理和分析數據，進而提升業務決策的敏捷性和準確性。

下面來描述一個典型的數據倉庫架構。在該架構中，借助 Kafka 作為消息隊列，使用 Flink 進行各層次的數據處理。同時，將處理后的數據同步到類似 StarRocks 的分析型數據庫，以提高用戶分析的性能。

基于 StarRocks 進行實時數據分析，其優勢包括當前應用以及未來可能的演進方向。在這種架構中，我們采用物化視圖策略，首先將基礎數據同步到 StarRocks 內部。然后，通過離線物化視圖的批量調度能力，實現各層次數據的刷新。

這種架構的主要優勢在于，整個數據分析過程都在 StarRocks 引擎內完成，降低了引入復雜引擎和組件的需求。從維護角度來看，這種架構使得平臺更加簡潔，方便運維和管理。

四、StarRocks 介紹

接下來詳細介紹 StarRocks 的架構和核心特性。

StarRocks 的核心優勢在于，它能夠有效應對前面所提及的各種場景。它具有如下四個關鍵特點：

• 高查詢性能：StarRocks 以其卓越的查詢性能脫穎而出，能夠迅速返回查詢結果，滿足用戶對實時數據的需求。
• 高效數據導入：StarRocks 在數據導入方面表現出色，具有較高的吞吐量和較小的延遲，能夠保證數據的快速導入和同步。
• 良好的并發支持：StarRocks 具備強大的并發處理能力，可支持多個并發任務同時進行，提高系統性能和利用率。
• 豐富的數據模型：StarRocks 提供了多樣化的數據模型，便于進行多維數據分析。用戶可以根據實際需求，選擇合適的數據模型進行數據處理和分析。

在業務側的整體分層架構中，StarRocks 在分析層發揮著關鍵作用。它實現了極速統一的解決方案，能夠覆蓋前面提到的各種業務場景。通過 StarRocks 的高性能、高吞吐量、低延遲等特點，用戶可以快速地獲取數據，實現高效的數據分析。在此基礎上，StarRocks 豐富的數據模型支持多種數據處理和分析方式，進一步滿足用戶在多維數據分析方面的需求。

以 StarRocks 為核心，包括數據導入、查詢等等在內，整個生態鏈路完備。

StarRocks 具有架構清晰、簡單的特點。整體上，分為兩個角色：FE 和 BE。

FE 主要負責查詢解析和優化，生成物理執行計劃。FE 采用了高可用設計，確保在出現故障時能夠自動進行容錯處理。通過內部實現的一致性協議元數據同步，即使在 FE 宕機的情況下，系統也能保持穩定運行。

BE 在存算分離之前，扮演計算執行引擎和存儲引擎的角色。BE 通常采用多副本策略，以確保數據安全性。當某臺 BE 宕機時，數據系統會自動進行遷移，不會影響查詢性能。同時，系統具備自愈功能，能夠在其他機器上自動補全缺失的副本，保證數據的完整性和一致性。

從性能層面來看，全面向量化引擎是 StarRocks 的一個重要特點。之所以強調“全面”，是因為只有在整個處理鏈路上都沒有短板，才能實現高效的向量化引擎。目前市場上許多產品都聲稱具備向量化能力，但真正能實現全面向量化的引擎并不多。

StarRocks 全面向量化引擎的優勢表現在以下幾個方面：

• 避免性能瓶頸：全面向量化引擎在 Shuffle 和 Join 等環節都能高效處理數據，避免了單一環節成為性能瓶頸。
• 更高的查詢性能：通過引入向量化技術，StarRocks 在核心計算環節相對于傳統引擎有顯著優勢。例如，虛函數調用和 CPU 調度等操作都能實現高效優化。
• 優化系統資源利用：全面向量化引擎能夠更充分地利用系統資源，進一步提高整體性能。

第二個對性能有重大影響的是 StarRocks 采用了代價驅動的優化策略（CBO）。CBO 主要針對 Join 場景，通過計算每個 Join 操作的代價，動態調整 Join 順序和優化查詢計劃。這張圖是業界參考的經典論文，展示了 CBO 引擎的工作原理。在 CMU 的相關課程中也有對 CBO 的介紹。

通過 CBO，StarRocks 能夠實現 Join 操作的順序調整和改寫，從而支持多種 Join 類型，使其在復雜業務場景下具有優越的性能。這也是 StarRocks 能夠應對多種多轉場景的核心技術之一。

StarRocks 在 Join 操作方面主要支持兩種模式：Shuffle Join 和 Colocation Join。這兩種模式相結合可以實現高效的數據處理和分析。

Shuffle Join：包括 Broadcast Join 在內的 Shuffle Join 模式，主要用于總體匯總場景。在這種模式下，StarRocks 通過對數據進行隨機分發和重組，實現不同表之間的 Join 操作。

Colocation Join：針對某些特殊業務場景，StarRocks 建議使用 Colocation Join 方式。這種模式可以根據業務需求，保證兩張表的數據分布完全一致。在查詢過程中，避免了遠端數據傳輸帶來的延遲，提高了處理效率。

前面介紹了 StarRocks 在查詢側的關鍵性能優化點，接下來介紹導入側的特點。在實時分析鏈路圖中可以看到，StarRocks 支持實時導入組件模型。

組件模型相對于傳統更新模型（如 Doris 早期的更新模型）在設計上進行了優化，實現了寫入和查詢之間的性能平衡。在傳統更新模型中，導入速度較快，但查詢時可能需要合并多個小文件，導致內存操作較重。

組件模型的核心優勢在于：

• 引入主鍵索引：在導入數據時，StarRocks 首先創建主鍵索引，以便知道寫入的 key 在哪個歷史文件中。基于這個信息，可以更新 DELETE 信息以避免無效查詢。
• 高效的實現：盡管引入了主鍵索引，但 StarRocks 保證了寫入性能不會受到太大影響。這是因為主鍵索引的實現較為高效，整體上與傳統導入方式的速度差距不大。
• 查詢性能優化：由于有了 deliver vector 信息，StarRocks 無需進行排序合并。同時，謂詞可以進行下推，進一步提高查詢性能。
• 物化視圖：StarRocks 從 2.5 版本開始，對物化視圖的支持較為完備。物化視圖可以大幅提高實時分析的性能，尤其是針對增量數據。

StarRocks 致力于為用戶帶來更好的分析體驗，特別是在查詢性能方面。為了實現這一目標，StarRocks 重點關注了用戶分析相關的工作，希望能夠吸引 Presto 和 Impala 等產品的用戶，讓他們能夠在 StarRocks 上享受到上層查詢優化能力，同時不影響性能。

StarRocks 在這方面取得了顯著的成果。如下圖所示，相對于 Trino、Presto 等競爭對手，StarRocks 在大多數基準測試和實際客戶案例中，性能提升了 3-5 位。這一成果得益于 StarRocks 不斷優化查詢引擎和底層架構，為用戶提供了更高效、穩定的分析解決方案。

以上是另一份性能報告。

從 2.3 版本開始，StarRocks 推出了 PIPELINE 引擎，旨在進一步提高 CPU 利用率。在并發場景下，基于 PIPELINE 引擎，StarRocks 能夠實現較為良好的資源隔離能力。這種能力使得 StarRocks 在處理大小查詢以及 ETL 任務時，能夠盡量彈性地進行資源分配。例如，當某些 ETL 任務較為繁重時，如果沒有資源隔離，其他在線查詢任務可能會受到較大影響。而 StarRocks 的資源隔離能力則可以有效降低這種影響，確保系統穩定運行。

資源隔離是 StarRocks 核心能力之一，對于并發場景具有顯著的優化效果。通過提高 CPU 利用率和完善資源隔離機制，StarRocks 能夠為用戶提供更高效、穩定的分析解決方案，滿足各種復雜場景下的需求。

最后一項核心能力是數據間的均衡。散落的數據之間的均衡依賴于存儲和計算的分離，這種分離使得 StarRocks 能夠實現彈性的擴容。

當添加新節點時，StarRocks 能夠自動將數據均衡分布到新節點上，確保每個節點的存儲量均衡。在副本方面，即使出現丟失的情況，StarRocks 也能自動進行恢復。只要確保多副本中至少有一個副本可用，StarRocks 就能保證數據的完整性和可靠性。

五、未來規劃

StarRocks 3.x 版本演進的關鍵點包括：

• 存儲和計算分離：這是 StarRocks 3.x 版本的核心優化之一。
• Lake House：StarRocks 3.x 版本將支持硬字聯合力，使得在存儲和計算分離的基礎上，實現多倉庫、多作業的能力變得更加便捷。此外，針對 ETL 場景，StarRocks 也在不斷優化和完善產品自身能力。
• 場景優化：去年，StarRocks 重點關注了 Big House 場景，并已實現較為成熟的能力。目前，許多客戶正在使用這一場景。建議關注這一場景的用戶進行嘗試。
• ETL 能力優化：StarRocks 針對算落盤等場景進行了重點優化，并支持增量物化視圖。實時更新物化視圖的同時，導入端也實現了統一。
• 簡化用戶體驗：StarRocks 致力于簡化導入方式，降低用戶學習成本。針對不同場景，StarRocks 提供了相應的導入方式。例如，Snowflake 在這方面做得非常好，StarRocks 也將借鑒其經驗，優化用戶體驗。
• 半結構化數據類型支持：針對數據庫場景，StarRocks 3.x 版本增加了對半結構化數據類型的支持，以滿足此類場景用戶的需求。

總之，StarRocks 3.x 版本在多個方面進行了優化和升級，包括存儲和計算分離、Lake House、ETL 能力、用戶體驗以及半結構化數據類型支持等。這些改進將幫助用戶更高效地應對各種業務場景，提升大數據分析的處理性能。