一、開源 OLAP 綜述

近年來開源領(lǐng)域涌現(xiàn)出了眾多優(yōu)秀產(chǎn)品，如 StarRocks、Doris、湖數(shù)據(jù)、湖格式、Spark 以及早期的 HBase、Presto 等。種類繁多的開源工具為用戶帶來了便利，同時也帶來了選擇難題。

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

二、OLAP 場景思考

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

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

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

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

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

末端運營分析類場景，例如鏈家等企業(yè)的經(jīng)紀(jì)人績效計算以及買菜類應(yīng)用的團長報表等。這些業(yè)務(wù)的一個共同特點是，經(jīng)紀(jì)人不斷變動，組織架構(gòu)頻繁調(diào)整，導(dǎo)致尾表變化愈發(fā)頻繁。

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

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

從引擎?zhèn)葋砜?，需要支持大寬表以滿足業(yè)務(wù)需求。然而，更新大寬表時，不能每次都能更新兩三千列數(shù)據(jù)，因此更新能力顯得尤為重要。此外，多流 join 支持以及 join 查詢能力優(yōu)化也是關(guān)鍵。在此基礎(chǔ)上，還要求引擎支持 bitmap 精確查詢，以滿足用戶畫像業(yè)務(wù)的高效處理需求。

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

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

在打造一款 OLAP 引擎產(chǎn)品時，需要重點關(guān)注以下幾個基礎(chǔ)方面：

首先，強化多表關(guān)聯(lián)（join）的能力支持，包括功能層面的語法支持和性能層面的優(yōu)化。多表關(guān)聯(lián)是 OLAP 查詢的核心環(huán)節(jié)，對于處理復(fù)雜數(shù)據(jù)場景至關(guān)重要。

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

此外，并發(fā)能力也是一項重要指標(biāo)。在高并發(fā)場景下，OLAP 引擎需要具備穩(wěn)定的性能表現(xiàn)和擴展性。在數(shù)據(jù)寫入方面需要提高性能，高效的數(shù)據(jù)寫入能力有助于 OLAP 產(chǎn)品更好地滿足業(yè)務(wù)場景需求。

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

最后，還要考慮架構(gòu)的運維便利性。良好的 OLAP 產(chǎn)品應(yīng)具備簡潔的運維方式，便于平臺側(cè)進行管理和維護。

三、開源數(shù)據(jù)湖/流式數(shù)倉解決方案

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

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

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

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

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

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

實時數(shù)據(jù)湖架構(gòu)也是 EMR 平臺上常見的一種數(shù)據(jù)處理架構(gòu)。在這種架構(gòu)中，實時數(shù)據(jù)從 CDC 模式或直接從 Kafka 攝入，并在各個層次上進行增量處理。相較于 Lambda 架構(gòu)，實時數(shù)據(jù)湖架構(gòu)在數(shù)據(jù)鏈路上實現(xiàn)了統(tǒng)一，從而降低了數(shù)據(jù)校驗等環(huán)節(jié)的工作量。

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

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

基于 StarRocks 進行實時數(shù)據(jù)分析，其優(yōu)勢包括當(dāng)前應(yīng)用以及未來可能的演進方向。在這種架構(gòu)中，我們采用物化視圖策略，首先將基礎(chǔ)數(shù)據(jù)同步到 StarRocks 內(nèi)部。然后，通過離線物化視圖的批量調(diào)度能力，實現(xiàn)各層次數(shù)據(jù)的刷新。

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

四、StarRocks 介紹

接下來詳細介紹 StarRocks 的架構(gòu)和核心特性。

StarRocks 的核心優(yōu)勢在于，它能夠有效應(yīng)對前面所提及的各種場景。它具有如下四個關(guān)鍵特點：

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

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

以 StarRocks 為核心，包括數(shù)據(jù)導(dǎo)入、查詢等等在內(nèi)，整個生態(tài)鏈路完備。

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

FE 主要負責(zé)查詢解析和優(yōu)化，生成物理執(zhí)行計劃。FE 采用了高可用設(shè)計，確保在出現(xiàn)故障時能夠自動進行容錯處理。通過內(nèi)部實現(xiàn)的一致性協(xié)議元數(shù)據(jù)同步，即使在 FE 宕機的情況下，系統(tǒng)也能保持穩(wěn)定運行。

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

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

StarRocks 全面向量化引擎的優(yōu)勢表現(xiàn)在以下幾個方面：

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

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

通過 CBO，StarRocks 能夠?qū)崿F(xiàn) Join 操作的順序調(diào)整和改寫，從而支持多種 Join 類型，使其在復(fù)雜業(yè)務(wù)場景下具有優(yōu)越的性能。這也是 StarRocks 能夠應(yīng)對多種多轉(zhuǎn)場景的核心技術(shù)之一。

StarRocks 在 Join 操作方面主要支持兩種模式：Shuffle Join 和 Colocation Join。這兩種模式相結(jié)合可以實現(xiàn)高效的數(shù)據(jù)處理和分析。

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

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

前面介紹了 StarRocks 在查詢側(cè)的關(guān)鍵性能優(yōu)化點，接下來介紹導(dǎo)入側(cè)的特點。在實時分析鏈路圖中可以看到，StarRocks 支持實時導(dǎo)入組件模型。

組件模型相對于傳統(tǒng)更新模型（如 Doris 早期的更新模型）在設(shè)計上進行了優(yōu)化，實現(xiàn)了寫入和查詢之間的性能平衡。在傳統(tǒng)更新模型中，導(dǎo)入速度較快，但查詢時可能需要合并多個小文件，導(dǎo)致內(nèi)存操作較重。

組件模型的核心優(yōu)勢在于：

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

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

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

以上是另一份性能報告。

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

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

最后一項核心能力是數(shù)據(jù)間的均衡。散落的數(shù)據(jù)之間的均衡依賴于存儲和計算的分離，這種分離使得 StarRocks 能夠?qū)崿F(xiàn)彈性的擴容。

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

五、未來規(guī)劃

StarRocks 3.x 版本演進的關(guān)鍵點包括：

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

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