阿里雲強力貢獻：如何讓 StarRocks 做到極速資料湖分析
作者
阿里雲 EMR 開源大資料 OLAP 團隊
StarRocks 社群分析湖團隊
StarRocks 是一個強大的資料分析系統，主要宗旨是為使用者提供極速、統一併且易用的資料分析能力，以幫助使用者通過更低的使用成本來更快的洞察資料的價值。通過精簡的架構、高效的向量化引擎以及全新設計的基於成本的優化器（CBO），StarRocks 的分析效能（尤其是多表 Join 查詢）得以遠超同類產品。
為了能夠滿足更多使用者對於極速分析資料的需求，同時讓 StarRocks 強大的分析能力應用在更加廣泛的資料集上，阿里雲開源大資料 OLAP 團隊聯合社區一起增強 StarRocks的資料湖分析能力。使其不僅能夠分析儲存在 StarRocks 本地的資料，還能夠以同樣出色的表現分析儲存在 Apache Hive、Apache Iceberg 和 Apache Hudi 等開源資料湖或資料倉庫的資料。
本文將重點介紹 StarRocks 極速資料湖分析能力背後的技術內幕，效能表現以及未來的規劃。
#01
整體架構
—
在資料湖分析的場景中，StarRocks 主要負責資料的計算分析，而資料湖則主要負責資料的儲存、組織和維護。上圖描繪了由 StarRocks 和資料湖所構成的完成的技術棧。
StarRocks 的架構非常簡潔，整個系統的核心只有 FE（Frontend）、BE（Backend）兩類程序，不依賴任何外部元件，方便部署與維護。其中 FE 主要負責解析查詢語句（SQL），優化查詢以及查詢的排程，而 BE 則主要負責從資料湖中讀取資料，並完成一系列的 Filter 和 Aggregate 等操作。
資料湖本身是一類技術概念的集合，常見的資料湖通常包含 Table Format、File Format 和 Storage 三大模組。其中 Table Format 是資料湖的“UI”，其主要作用是組織結構化、半結構化，甚至是非結構化的資料，使其得以儲存在像 HDFS 這樣的分散式檔案系統或者像 OSS 和 S3 這樣的物件儲存中，並且對外暴露表結構的相關語義。Table Format 包含兩大流派，一種是將元資料組織成一系列檔案，並同實際資料一同儲存在分散式檔案系統或物件儲存中，例如 Apache Iceberg、Apache Hudi 和 Delta Lake 都屬於這種方式；還有一種是使用定製的 metadata service 來單獨存放元資料，例如 StarRocks 本地表，Snowflake 和 Apache Hive 都是這種方式。
File Format 的主要作用是給資料單元提供一種便於高效檢索和高效壓縮的表達方式，目前常見的開原始檔格式有列式的 Apache Parquet 和 Apache ORC，行式的 Apache Avro 等。
Storage 是資料湖儲存資料的模組，目前資料湖最常使用的 Storage 主要是分散式檔案系統 HDFS，物件儲存 OSS 和 S3 等。
FE
FE 的主要作用將 SQL 語句轉換成 BE 能夠認識的 Fragment，如果把 BE 叢集當成一個分散式的執行緒池的話，那麼 Fragment 就是執行緒池中的 Task。從 SQL 文字到分散式物理執行計劃，FE 的主要工作需要經過以下幾個步驟:
-
SQL Parse：將 SQL 文字轉換成一個 AST(抽象語法樹)
-
SQL Analyze：基於 AST 進行語法和語義分析
-
SQL Logical Plan：將 AST 轉換成邏輯計劃
-
SQL Optimize：基於關係代數，統計資訊，Cost 模型對 邏輯計劃進行重寫，轉換，選擇出 Cost “最低” 的物理執行計劃
-
生成 Plan Fragment：將 Optimizer 選擇的物理執行計劃轉換為 BE 可以直接執行的 Plan Fragment。
-
執行計劃的排程
BE
Backend 是 StarRocks 的後端節點，負責資料儲存以及 SQL 計算執行等工作。
StarRocks 的 BE 節點都是完全對等的，FE 按照一定策略將資料分配到對應的 BE 節點。在資料匯入時，資料會直接寫入到 BE 節點，不會通過FE中轉，BE 負責將匯入資料寫成對應的格式以及生成相關索引。在執行 SQL 計算時，一條 SQL 語句首先會按照具體的語義規劃成邏輯執行單元，然後再按照資料的分佈情況拆分成具體的物理執行單元。物理執行單元會在資料儲存的節點上進行執行，這樣可以避免資料的傳輸與拷貝，從而能夠得到極致的查詢效能。
#02
技術細節
—
StarRocks 為什麼這麼快？
CBO 優化器
一般 SQL 越複雜，Join 的表越多，資料量越大，查詢優化器的意義就越大，因為不同執行方式的效能差別可能有成百上千倍。StarRocks 優化器主要基於 Cascades 和 ORCA 論文實現，並結合 StarRocks 執行器和排程器進行了深度定製，優化和創新。完整支援了 TPC-DS 99 條 SQL，實現了公共表示式複用，相關子查詢重寫，Lateral Join， CTE 複用，Join Rorder，Join 分散式執行策略選擇，Runtime Filter 下推，低基數字典優化 等重要功能和優化。
CBO 優化器好壞的關鍵之一是 Cost 估計是否準確，而 Cost 估計是否準確的關鍵點之一是統計資訊是否收集及時，準確。StarRocks 目前支援表級別和列級別的統計資訊，支援自動收集和手動收集兩種方式，無論自動還是手動，都支援全量和抽樣收集兩種方式。
MPP 執行
MPP (massively parallel processing) 是大規模平行計算的簡稱，核心做法是將查詢 Plan 拆分成很多可以在單個節點上執行的計算例項，然後多個節點並行執行。每個節點不共享 CPU，記憶體, 磁碟資源。MPP 資料庫的查詢效能可以隨著叢集的水平擴充套件而不斷提升。
如上圖所示，StarRocks 會將一個查詢在邏輯上切分為多個 Query Fragment(查詢片段)，每個 Query Fragment 可以有一個或者多個 Fragment 執行例項，每個Fragment 執行例項 會被排程到叢集某個 BE 上執行。如上圖所示，一個 Fragment 可以包括 一個 或者多個 Operator（執行運算元），圖中的 Fragment 包括了 Scan, Filter, Aggregate。如上圖所示，每個 Fragment 可以有不同的並行度。
如上圖所示，多個 Fragment 之間會以 Pipeline 的方式在記憶體中並行執行，而不是像批處理引擎那樣 Stage By Stage 執行。
如上圖所示，Shuffle （資料重分佈）操作是 MPP 資料庫查詢效能可以隨著叢集的水平擴充套件而不斷提升的關鍵，也是實現高基數聚合和大表 Join 的關鍵。
向量化執行引擎
隨著資料庫執行的瓶頸逐漸從 IO 轉移到 CPU，為了充分發揮 CPU 的執行效能，StarRocks 基於向量化技術重新實現了整個執行引擎。運算元和表示式向量化執行的核心是批量按列執行，批量執行，相比與單行執行，可以有更少的虛擬函式呼叫，更少的分支判斷；按列執行，相比於按行執行，對 CPU Cache 更友好，更易於 SIMD 優化。
向量化執行不僅僅是資料庫所有運算元的向量化和表示式的向量化，而是一項巨大和複雜的效能優化工程，包括資料在磁碟，記憶體，網路中的按列組織，資料結構和演算法的重新設計，記憶體管理的重新設計，SIMD 指令優化，CPU Cache 優化，C++優化等。向量化執行相比之前的按行執行，整體效能提升了5到10倍。
StarRocks 如何優化資料湖分析？
大資料分析領域，資料除了儲存在數倉之外，也會儲存在資料湖當中，傳統的資料湖實現方案包括 Hive/HDFS。近幾年比較火熱的是 LakeHouse 概念，常見的實現方案包括 Iceberg/Hudi/Delta。那麼 StarRocks 能否幫助使用者更好地挖掘資料湖中的資料價值呢？答案是肯定的。
在前面的內容中我們介紹了 StarRocks 如何實現極速分析，如果將這些能力用於資料湖肯定會帶來更好地資料湖分析體驗。在這部分內容中，我們會介紹 StarRocks 是如何實現極速資料湖分析的。
我們先看一下全域性的架構，StarRocks 和資料湖分析相關的主要幾個模組如下圖所示。其中 Data Management 由資料湖提供，Data Storage 由物件儲存 OSS/S3，或者是分散式檔案系統 HDFS 提供。
目前，StarRocks 已經支援的資料湖分析能力可以歸納為下面幾個部分：
-
支援 Iceberg v1 表查詢
http://github.com/StarRocks/starrocks/issues/1030
-
支援 Hive 外表查詢
外部表 @ External_table @ StarRocks Docs (dorisdb.com)
http://docs.dorisdb.com/zh-cn/main/using_starrocks/External_table
-
支援 Hudi COW 表查詢
http://github.com/StarRocks/starrocks/issues/2772
接下來我們從查詢優化和查詢執行這幾個方面來看一下，StarRocks 是如何實現將極速分析的能力賦予資料湖的。
查詢優化
查詢優化這部分主要是利用前面介紹的 CBO 優化器來實現，資料湖模組需要給優化器統計資訊。基於這些統計資訊，優化器會利用一系列策略來實現查詢執行計劃的最優化。接下來我們通過例子看一下幾個常見的策略。
-
統計資訊
我們看下面這個例子，生成的執行計劃中，HdfsScanNode 包含了 cardunality、avgRowSize 等統計資訊的展示。
MySQL [hive_test]> explain select l_quantity from lineitem;
+-----------------------------+
| Explain String |
+-----------------------------+
| PLAN FRAGMENT 0 |
| OUTPUT EXPRS:5: l_quantity |
| PARTITION: UNPARTITIONED |
| |
| RESULT SINK |
| |
| 1:EXCHANGE |
| |
| PLAN FRAGMENT 1 |
| OUTPUT EXPRS: |
| PARTITION: RANDOM |
| |
| STREAM DATA SINK |
| EXCHANGE ID: 01 |
| UNPARTITIONED |
| |
| 0:HdfsScanNode |
| TABLE: lineitem |
| partitions=1/1 |
| cardinality=126059930 |
| avgRowSize=8.0 |
| numNodes=0 |
+-----------------------------+在正式進入到 CBO 優化器之前，這些統計資訊都會計算好。比如針對 Hive 我們有 MetaData Cache 來快取這些資訊，針對 Iceberg 我們通過 Iceberg 的 manifest 資訊來計算這些統計資訊。獲取到這些統計資訊之後，對於後續的優化策略的效果有很大地提升。
-
分割槽裁剪
分割槽裁剪是隻有當目標表為分割槽表時，才可以進行的一種優化方式。分割槽裁剪通過分析查詢語句中的過濾條件，只選擇可能滿足條件的分割槽，不掃描匹配不上的分割槽，進而顯著地減少計算的資料量。比如下面的例子，我們建立了一個以 ss_sold_date_sk 為分割槽列的外表。
create external table store_sales(
ss_sold_time_sk bigint
, ss_item_sk bigint
, ss_customer_sk bigint
, ss_coupon_amt decimal(7,2)
, ss_net_paid decimal(7,2)
, ss_net_paid_inc_tax decimal(7,2)
, ss_net_profit decimal(7,2)
, ss_sold_date_sk bigint
) ENGINE=HIVE
PROPERTIES (
"resource" = "hive_tpcds",
"database" = "tpcds",
"table" = "store_sales"
);在執行如下查詢的時候，分割槽2451911和2451941之間的資料才會被讀取，其他分割槽的資料會被過濾掉，這可以節約很大一部分的網路 IO 的消耗。
select ss_sold_time_sk from store_sales
where ss_sold_date_sk between 2451911 and 2451941
order ss_sold_time_sk;-
Join Reorder
多個表的 Join 的查詢效率和各個表參與 Join 的順序有很大關係。如 select * from T0, T1, T2 where T0.a=T1.a and T2.a=T1.a，這個 SQL 中可能的執行順序有下面兩種情況：
-
T0 和 T1 先做 Join，然後再和 T2 做 Join
-
T1 和 T2 先做 Join，然後再和 T0 做 Join
根據 T0 和 T2 的資料量及資料分佈，這兩種執行順序會有不同的效能表現。針對這個情況，StarRocks 在優化器中實現了基於 DP 和貪心的 Join Reorder 機制。目前針對 Hive的資料分析，已經支援了 Join Reorder，其他的資料來源的支援也正在開發中。下面是一個例子：
MySQL [hive_test]> explain select * from T0, T1, T2 where T2.str=T0.str and T1.str=T0.str;
+----------------------------------------------+
| Explain String |
+----------------------------------------------+
| PLAN FRAGMENT 0 |
| OUTPUT EXPRS:1: str | 2: str | 3: str |
| PARTITION: UNPARTITIONED |
| RESULT SINK |
| 8:EXCHANGE |
| PLAN FRAGMENT 1 |
| OUTPUT EXPRS: |
| PARTITION: HASH_PARTITIONED: 2: str |
| STREAM DATA SINK |
| EXCHANGE ID: 08 |
| UNPARTITIONED |
| 7:HASH JOIN |
| | join op: INNER JOIN (BUCKET_SHUFFLE(S)) |
| | hash predicates: |
| | colocate: false, reason: |
| | equal join conjunct: 1: str = 3: str |
| |----6:EXCHANGE |
| 4:HASH JOIN |
| | join op: INNER JOIN (PARTITIONED) |
| | hash predicates: |
| | colocate: false, reason: |
| | equal join conjunct: 2: str = 1: str |
| |----3:EXCHANGE |
| 1:EXCHANGE |
| PLAN FRAGMENT 2 |
| OUTPUT EXPRS: |
| PARTITION: RANDOM |
| STREAM DATA SINK |
| EXCHANGE ID: 06 |
| HASH_PARTITIONED: 3: str |
| 5:HdfsScanNode |
| TABLE: T2 |
| partitions=1/1 |
| cardinality=1 |
| avgRowSize=16.0 |
| numNodes=0 |
| PLAN FRAGMENT 3 |
| OUTPUT EXPRS: |
| PARTITION: RANDOM |
| STREAM DATA SINK |
| EXCHANGE ID: 03 |
| HASH_PARTITIONED: 1: str |
| 2:HdfsScanNode |
| TABLE: T0 |
| partitions=1/1 |
| cardinality=1 |
| avgRowSize=16.0 |
| numNodes=0 |
| PLAN FRAGMENT 4 |
| OUTPUT EXPRS: |
| PARTITION: RANDOM |
| STREAM DATA SINK |
| EXCHANGE ID: 01 |
| HASH_PARTITIONED: 2: str |
| 0:HdfsScanNode |
| TABLE: T1 |
| partitions=1/1 |
| cardinality=1 |
| avgRowSize=16.0 |
| numNodes=0 |
+----------------------------------------------+-
謂詞下推
謂詞下推將查詢語句中的過濾表示式計算儘可能下推到距離資料來源最近的地方，從而減少資料傳輸或計算的開銷。針對資料湖場景，我們實現了將 Min/Max 等過濾條件下推到 Parquet 中，在讀取 Parquet 檔案的時候，能夠快速地過濾掉不用的 Row Group。
比如，對於下面的查詢，l_discount=1對應條件會下推到 Parquet 側。
MySQL [hive_test]> explain select l_quantity from lineitem where l_discount=1;
+----------------------------------------------------+
| Explain String |
+----------------------------------------------------+
| PLAN FRAGMENT 0 |
| OUTPUT EXPRS:5: l_quantity |
| PARTITION: UNPARTITIONED |
| |
| RESULT SINK |
| |
| 2:EXCHANGE |
| |
| PLAN FRAGMENT 1 |
| OUTPUT EXPRS: |
| PARTITION: RANDOM |
| |
| STREAM DATA SINK |
| EXCHANGE ID: 02 |
| UNPARTITIONED |
| |
| 1:Project |
| | <slot 5> : 5: l_quantity |
| | |
| 0:HdfsScanNode |
| TABLE: lineitem |
| NON-PARTITION PREDICATES: 7: l_discount = 1.0 |
| partitions=1/1 |
| cardinality=63029965 |
| avgRowSize=16.0 |
| numNodes=0 |
+----------------------------------------------------+-
其他策略
除了上面介紹的幾種策略，針對資料湖分析，我們還適配了如 Limit 下推、TopN 下推、子查詢優化等策略。能夠進一步地優化查詢效能。
查詢執行
前面介紹了，StarRocks 的執行引擎是全向量化、MPP 架構的，這些無疑都會給我們分析資料湖的資料帶來很大提升。接下來我們看一下 StarRocks 是如何排程和執行資料湖分析查詢的。
-
查詢排程
資料湖的資料一般都儲存在如 HDFS、OSS 上，考慮到混部和非混部的情況。我們對 Fragment 的排程，實現了一套負載均衡的演算法。
-
做完分割槽裁剪之後，得到要查詢的所有 HDFS 檔案 block
-
對每個 block 構造 THdfsScanRange，其中 hosts 包含 block 所有副本所在的 datanode 地址，最終得到 List<TScanRangeLocations>
-
Coordinator 維護一個所有 be 當前已經分配的 scan range 數目的 map，每個 datanode 上磁碟已分配的要讀取 block 的數目的 map>，及每個 be 平均分配的 scan range 數目 numScanRangePerBe
-
如果 block 副本所在的 datanode 有be（混部）
-
-
每個 scan range 優先分配給副本所在的 be 中 scan range 數目最少的 be。如果 be 已經分配的 scan range 數目大於 numScanRangePerBe，則從遠端 be 中選擇 scan range 數目最小的
-
如果有多個 be 上 scan range 數目一樣小，則考慮 be 上磁碟的情況，選擇副本所在磁碟上已分配的要讀取 block 數目小的 be
-
-
如果 block 副本所在的 datanode 機器沒有 be（單獨部署或者可以遠端讀）
-
-
選擇 scan range 數目最小的 be
-
-
-
查詢執行
在排程到 BE 端進行執行之後，整個執行過程都是向量化的。具體看下面 Iceberg 的例子，IcebergScanNode 對應的 BE 端目前是 HdfsScanNode 的向量化實現，其他運算元也是類似，在 BE 端都是向量化的實現。
MySQL [external_db_snappy_yuzhou]> explain select c_customer_id customer_id
-> ,c_first_name customer_first_name
-> ,c_last_name customer_last_name
-> ,c_preferred_cust_flag customer_preferred_cust_flag
-> ,c_birth_country customer_birth_country
-> ,c_login customer_login
-> ,c_email_address customer_email_address
-> ,d_year dyear
-> ,'s' sale_type
-> from customer, store_sales, date_dim
-> where c_customer_sk = ss_customer_sk
-> and ss_sold_date_sk = d_date_sk;
+------------------------------------------------
| PLAN FRAGMENT 0
| OUTPUT EXPRS:2: c_customer_id | 9: c_first_name | 10: c_last_name | 11: c_preferred_cust_flag | 15: c_birth_country | 16: c_login | 17: c_email_address | 48: d_year | 70: expr |
| PARTITION: UNPARTITIONED
| RESULT SINK
| 9:EXCHANGE
| PLAN FRAGMENT 1
| OUTPUT EXPRS:
| PARTITION: RANDOM
| STREAM DATA SINK
| EXCHANGE ID: 09
| UNPARTITIONED
| 8:Project
| | <slot 2> : 2: c_customer_id
| | <slot 9> : 9: c_first_name
| | <slot 10> : 10: c_last_name
| | <slot 11> : 11: c_preferred_cust_flag
| | <slot 15> : 15: c_birth_country
| | <slot 16> : 16: c_login
| | <slot 17> : 17: c_email_address
| | <slot 48> : 48: d_year
| | <slot 70> : 's'
| 7:HASH JOIN
| | join op: INNER JOIN (BROADCAST)
| | hash predicates:
| | colocate: false, reason:
| | equal join conjunct: 21: ss_customer_sk = 1: c_customer_sk
| 4:Project
| | <slot 21> : 21: ss_customer_sk
| | <slot 48> : 48: d_year
| 3:HASH JOIN
| | join op: INNER JOIN (BROADCAST)
| | hash predicates:
| | colocate: false, reason:
| | equal join conjunct: 41: ss_sold_date_sk = 42: d_date_sk
| 0:IcebergScanNode
| TABLE: store_sales
| cardinality=28800991
| avgRowSize=1.4884362
| numNodes=0
| PLAN FRAGMENT 2
| OUTPUT EXPRS:
| PARTITION: RANDOM
| STREAM DATA SINK
| EXCHANGE ID: 06
| UNPARTITIONED
| 5:IcebergScanNode
| TABLE: customer
| cardinality=500000
| avgRowSize=36.93911
| numNodes=0
| PLAN FRAGMENT 3
| OUTPUT EXPRS:
| PARTITION: RANDOM
| STREAM DATA SINK
| EXCHANGE ID: 02
| UNPARTITIONED
| 1:IcebergScanNode
| TABLE: date_dim
| cardinality=73049
| avgRowSize=4.026941
| numNodes=0#03
基準測試
—
TPC-H 是美國交易處理效能委員會TPC（Transaction Processing Performance Council）組織制定的用來模擬決策支援類應用的測試集。
It consists of a suite of business oriented ad-hoc queries and concurrent data modifications.
TPC-H 根據真實的生產執行環境來建模，模擬了一套銷售系統的資料倉庫。該測試共包含8張表，資料量可設定從1 GB~3 TB不等。其基準測試共包含了22個查詢，主要評價指標為各個查詢的響應時間，即從提交查詢到結果返回所需時間。
測試結論
在 TPCH 100G規模的資料集上進行對比測試，共22個查詢，結果如下：
StarRocks 使用本地儲存查詢和 Hive 外表查詢兩種方式進行測試。其中，StarRocks On Hive 和 Trino On Hive 查詢的是同一份資料，資料採用 ORC 格式儲存，採用 zlib 格式壓縮。測試環境使用 阿里雲 EMR 進行構建。
最終，StarRocks 本地儲存查詢總耗時為21s，StarRocks Hive 外表查詢總耗時92s。Trino 查詢總耗時307s。可以看到 StarRocks On Hive 在查詢效能方面遠遠超過 Trino，但是對比本地儲存查詢還有不小的距離，主要的原因是訪問遠端儲存增加了網路開銷，以及遠端儲存的延時和 IOPS 通常都不如本地儲存，後面的計劃是通過 Cache 等機制彌補問題，進一步縮短 StarRocks 本地表和 StarRocks On Hive 的差距。
具體測試過程請參考：
StarRocks vs Trino TPCH 效能測試對比報告
http://www.starrocks.com/zh-CN/blog/tpch_2.1
#04
未來規劃
—
得益於全面向量化執行引擎，CBO 優化器以及 MPP 執行框架等核心技術，目前 StarRocks 已經實現了遠超其他同類產品的極速資料湖分析能力。從長遠來看， StarRocks 在資料湖分析方向的願景是為使用者提供極其簡單、易用和高速的資料湖分析能力。為了能夠實現這一目標，StarRocks 現在還有許多工作需要完成，其中包括：
-
整合 Pipeline 執行引擎，通過 Push Based 的流水線執行方式，進一步降低查詢響應速度
-
自動的冷熱資料分層儲存，使用者可以將頻繁更新的熱資料儲存在 StarRocks 本地表上，StarRocks 會定期自動將冷資料從本地表遷移到資料湖
-
去掉顯式建立外表的步驟，使用者只需要建立資料湖對應的 resource 即可實現資料湖庫表全自動同步
-
進一步完善 StarRocks 對於資料湖產品特性的支援，包括支援 Apache Hudi 的 MOR 表和 Apache Iceberg 的 v2 表；支援直接寫資料湖；支援 Time Travel 查詢，完善 Catalog 的支援度等
-
通過層級 Cache 來進一步提升資料湖分析的效能
#05
更多資訊
—
參考連結
[1] 阿里雲 EMR StarRocks 官方文件
http://help.aliyun.com/document_detail/404790.html
[2] 阿里雲 EMR 控制檯
http://emr.console.aliyun.com/
[3] http://github.com/StarRocks/starrocks/issues/1030
[4] http://github.com/StarRocks/starrocks/issues/2772
[5] StarRocks vs Trino TPCH 效能測試對比報告
http://www.starrocks.com/zh-CN/blog/tpch_2.1
活動推薦
今晚7點，國內首家網際網路金融公司眾安保險將與 StarRocks 舉辦一場聯合直播。
眾安保險科學資料應用中心高階總監施興天、StarRocks 聯合創始人&COO 葉謙將以 StarRocks 落地眾安集智平臺為例，分享如何用全新實時分析能力開啟數字化經營新局面。
近年來，眾安保險致力於加速資料價值向業務價值轉化，服務使用者超過 5 億，業務全程線上完成，在金融科技的研發和落地上非常領先。
掃描下⽅海報⼆維碼，鎖定直播！
- 首汽約車駛向極速統一之路！出行平臺如何基於StarRocks構建實時數倉？
- 美團餐飲SaaS基於StarRocks構建商家資料中臺的探索
- "陸戰之王"大潤發如何在零售業數字化轉型中搶佔先機？
- 當打造一款極速湖分析產品時，我們在想些什麼
- 技術內幕 | 阿里雲EMR StarRocks 極速資料湖分析
- 打造一款強大成熟的資料庫有多難？
- 得物基於 StarRocks 的 OLAP 需求實踐
- 得物基於 StarRocks 的 OLAP 需求實踐
- 得物基於 StarRocks 的 OLAP 需求實踐
- 從使用者到開發者是一種思維進化過程 | 訪 StarRocks Committer 周威
- StarRocks 運維工具 StarGo
- StarRocks 技術內幕：向量化程式設計精髓
- 破解雙中臺困局：萬家數科 x StarRocks 數字化技術實踐
- StarRocks 技術內幕 | 基於全域性字典的極速字串查詢
- 技術內幕 | 阿里雲專家解讀StarRocks的Optimizer實現
- StarRocks 在 58 集團全業務線的深度實踐
- 酷開科技 × StarRocks：統一 OLAP 分析引擎，全面打造數字化的 OTT 模式
- 【數智化案例展】StarRocks × 眾安保險：全新實時分析能力開啟數字化經營新局面
- 酷開科技 × StarRocks：統一 OLAP 分析引擎，全面打造數字化的 OTT 模式
- StarRocks 2.3 新版本特性介紹