開源大數據 OLAP 的思考及最佳實踐

導讀 本文將介紹開源 OLAP 及其在不同場景下的需求。文章將從 EMR 的角度，簡要介紹 OLAP 的數據架構。並重點講解 StarRocks 的核心功能和後續發展規劃。

本次分享主要分為以下五個部份：

1. 開源 OLAP 綜述

2. OLAP 場景思考

3. 開源數據湖/流式數倉解決方案

4. StarRocks 介紹

5. 未來規劃

分享嘉賓｜ 周康 阿裏雲 技術專家

01

開源 OLAP 綜述

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

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

02

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 產品應具備簡潔的運維方式，便於平台側進行管理和維護。

03

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

下面介紹阿裏雲 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 引擎內完成，降低了引入復雜引擎和元件的需求。從維護角度來看，這種架構使得平台更加簡潔，方便運維和管理。

04

StarRocks 介紹

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

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

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

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

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

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

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

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

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

第二個對效能有重大影響的是 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 致力於為使用者帶來更好的分析體驗，特別是在查詢效能方面。為了實作這一目標，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 就能保證數據的完整性和可靠性。

05

未來規劃

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

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

以上就是本次分享的內容，謝謝大家。

分享嘉賓

INTRODUCTION

周康

阿裏雲

技術專家

阿裏雲端運算平台開源大數據技術專家，StarRocks Committer，負責 EMR OLAP 產品研發，包括 StarRocks、ClickHouse、Presto(Trino)等開源元件。曾參與基於開源元件構建的分布式排程平台、分布式計算平台、數據分析平台的建設 。