一、開源 OLAP 綜述

基于歷史發(fā)展和開源社區(qū)的火熱，現(xiàn)在的 OLAP 技術(shù)可以用百花齊放四個(gè)字來(lái)形容。

如圖中最左邊這一部分，是現(xiàn)在比較流行或者已經(jīng)是業(yè)界標(biāo)準(zhǔn)的 OLAP 數(shù)據(jù)倉(cāng)庫(kù) / LakeHouse，包括 StarRocks、Doris、ClickHouse。第二部分是 SQL on Hadoop，該技術(shù)于 10 年前開始，以 HDFS 平臺(tái)或者 OSS 為存儲(chǔ)底座，包括 Presto 以及分支出來(lái)的 Trino、Impala。第三部分是預(yù)處理 / Cube/NoSQL，已經(jīng)使用得越來(lái)越少，麒麟、Druid 社區(qū)以及背后的商業(yè)化公司活躍度不高，Hbase 目前主要用在 Serving 的場(chǎng)景，社區(qū)相對(duì)比較老，穩(wěn)定性尚可，解決了一部分業(yè)務(wù)場(chǎng)景，應(yīng)用規(guī)模不小，但熱度在逐漸下降。第四列是離線部分，目前的事實(shí)標(biāo)準(zhǔn)是 Spark，比較老的技術(shù)棧則是 Hive。

最底下這一部分是數(shù)據(jù)湖格式，之所以放在最下面，是有原因的。Delta Lake 在 2019 年推出了增量數(shù)據(jù)湖格式，后期包括 Hudi，Iceberg，被大家稱作數(shù)據(jù)湖三劍客。它們主要解決數(shù)據(jù)增量更新的問題。在大多情況下，作為 Presto、StarRocks 的外表，以讀的方式作為 OLAP 來(lái)使用。Apache Paimon 是 Flink 社區(qū)推出的，原來(lái)叫 Flink Table Store，目前也貢獻(xiàn)到了 Apache 社區(qū)，以 Flink 為基礎(chǔ)，把整個(gè)存儲(chǔ)留在湖里。

二、OLAP 場(chǎng)景思考

典型業(yè)務(wù)場(chǎng)景

OLAP 的業(yè)務(wù)場(chǎng)景主要有四大類：

第一類是面向用戶的報(bào)表，比如一個(gè)比較典型的場(chǎng)景，給第三方廣告主出報(bào)表，它可能是一個(gè) ToB 的公司，利用 OLAP 引擎去做 Serving 服務(wù)；

第二類是面向經(jīng)營(yíng)人員、數(shù)據(jù)分析人員、老板的一些經(jīng)營(yíng)的報(bào)表，也是傳統(tǒng) BI 的 OLAP 行為；

第三類是用戶畫像，在游戲等行業(yè)里用得非常多，主要是把所有的用戶標(biāo)簽統(tǒng)一到一張比較寬的表里，可以用各個(gè)維度去篩選出需要的客戶；

第四類是流式的、實(shí)時(shí)的場(chǎng)景，包括直播、風(fēng)控、實(shí)時(shí)預(yù)測(cè)。

接下來(lái)將介紹這幾種業(yè)務(wù)場(chǎng)景對(duì) OLAP 技術(shù)的需求及解決方案。

面向客戶的報(bào)表

面向客戶的報(bào)表，業(yè)務(wù)特點(diǎn)是按照客戶的 ID 去檢索數(shù)據(jù)，需要低延遲、高并發(fā)，而且需要明細(xì)數(shù)據(jù)，不僅僅是聚合模型。基于明細(xì)可以實(shí)現(xiàn)更靈活的自助分析，或者稱作實(shí)時(shí) OLAP。但是實(shí)時(shí) OLAP 性能也會(huì)受限制，比如三張表、十張表的 Join 查詢的 latency 可能會(huì)非常的高，所以我們需要去做物化視圖?？偨Y(jié)起來(lái)，業(yè)務(wù)場(chǎng)景的需求是明細(xì)加上物化視圖。

在技術(shù)上的需求，第一點(diǎn)是數(shù)據(jù)過(guò)濾，比如前綴索引、Bloom filter，以及一些更高級(jí)的 filter，通過(guò)一些統(tǒng)計(jì)值有效過(guò)濾，減少讀取的數(shù)據(jù)，使得點(diǎn)查或者范圍查詢更加快速。

第二點(diǎn)是向量化引擎，Presto、Hive、Spark 在某一個(gè)時(shí)間點(diǎn)上都有 OLAP 的嘗試。當(dāng)然現(xiàn)在 Presto、Trino 社區(qū)還是非?；钴S的，尤其是在國(guó)外，它們是通過(guò) Java 技術(shù)棧實(shí)現(xiàn)的，但是 Java 技術(shù)棧從語(yǔ)言層面而言沒有 C++ 快，同時(shí)因?yàn)?JVM 向量化現(xiàn)在還不是特別成熟，也不能利用 JVM 的向量化模式。當(dāng)然 Trino 社區(qū)在不斷地去做這件事，不過(guò)到現(xiàn)在還沒有一個(gè)完整的產(chǎn)品。另外 Presto，也在做 Native 的 Engine，去解決 OLAP 加上向量化的問題。但是有一些數(shù)據(jù)庫(kù)，包括 ClickHouse、StarRocks、Doris，在幾年前就已經(jīng)布局了向量化引擎，因?yàn)槠湔麄€(gè)執(zhí)行引擎本來(lái)就是用 C++ 寫的，所以會(huì)更快。

第三點(diǎn)是數(shù)據(jù)在機(jī)器的合理分布，數(shù)據(jù)分布對(duì)查詢影響也是比較大的，包括數(shù)據(jù)是否有序、是否是 shard。

最后一點(diǎn)是對(duì)物化視圖的支持是否足夠好。

面向經(jīng)營(yíng)的報(bào)表

面向經(jīng)營(yíng)的報(bào)表，一般是企業(yè)內(nèi)部提供給老板和數(shù)據(jù)分析人員查看的報(bào)表，比較典型的是實(shí)時(shí)風(fēng)控場(chǎng)景。業(yè)務(wù)特點(diǎn)首先是需求變化特別快，要有明細(xì)表的存在，不只聚合成一種預(yù)設(shè)的模式，一般要把明細(xì)表直接導(dǎo)入到數(shù)據(jù)倉(cāng)庫(kù)中。第二是要求響應(yīng)低延遲，對(duì)查詢性能要求很高。

低延時(shí)對(duì)技術(shù)的需求包括向量化極速查詢、多表關(guān)聯(lián)查詢能力、物化視圖等等。

ClickHouse 針對(duì)寬表的場(chǎng)景，把整個(gè)數(shù)據(jù)通過(guò) shard 分布，每一臺(tái)機(jī)器進(jìn)行分布式計(jì)算，最后將結(jié)果匯總起來(lái)形成查詢的結(jié)果。ClickHouse 寬表比較快，但是寬表維護(hù)起來(lái)比較麻煩。所以我們思索是否有一種引擎可以對(duì)明細(xì)模型做高效的分布式 Join，在具有多機(jī)多核的同時(shí)也有核的向量化。

用戶畫像

用戶畫像場(chǎng)景是以一個(gè) ID 為主鍵，構(gòu)成一張列特別多的寬表。在 StarRocks 出現(xiàn)之前，更多用的是 Flink 或者 Spark 在外圍加工出一張可能上千列的寬表，再直接 load 到數(shù)據(jù)庫(kù)中，比較常見的是 ClickHouse 中。現(xiàn)在由于 StarRocks 逐漸崛起，很多需求都落到了 StarRocks 上。因?yàn)槎啾黻P(guān)聯(lián)的能力也是需要的，如果用戶畫像只用寬表來(lái)做，還是有一些限制。在跟客戶交流的過(guò)程中了解到，ClickHouse 這條鏈路會(huì)存在煙囪式開發(fā)的問題，維護(hù)起來(lái)有難度，所以 ClickHouse 的高效是犧牲了一定的運(yùn)維能力。另外 ClickHouse 對(duì)人員的要求也比較高，因?yàn)闃I(yè)務(wù)線的人員更多的是關(guān)注業(yè)務(wù)，這時(shí)要求業(yè)務(wù)線的人員去對(duì) ClickHouse 進(jìn)行維護(hù)就會(huì)存在困難。

訂單分析

訂單分析場(chǎng)景，在沒有增量數(shù)據(jù)湖格式出現(xiàn)之前，用 Hive 或 Spark 一般是 T+1 的形式，如果要進(jìn)一步提高時(shí)效，可能會(huì)用更短的時(shí)間去建分區(qū)，比如一個(gè)小時(shí)一個(gè)分區(qū)，但如果對(duì)這類分區(qū)表做全量刷新則會(huì)非常不友好，無(wú)論是對(duì)數(shù)據(jù)湖還是調(diào)度，壓力都非常大。現(xiàn)在希望實(shí)時(shí)或者準(zhǔn)實(shí)時(shí)地去分析數(shù)據(jù)，增量數(shù)據(jù)湖，包括 Delta Lake、Hudi、Iceberg 就是為了解決這一問題。

在線教育、企業(yè)訂單、打車軟件等場(chǎng)景，常常需要數(shù)據(jù)回刷，這對(duì)數(shù)據(jù)湖來(lái)說(shuō)是一個(gè)非常大的挑戰(zhàn)。在有了更新模型之后，很多企業(yè)開始把整個(gè)鏈路加到 Hudi，或者 Delta Lake 上面。比如上一次的數(shù)據(jù)是一個(gè)小時(shí)之前的數(shù)據(jù)，下一個(gè)小時(shí)去更新這一批數(shù)據(jù)，但是如果做 OLAP 查詢，速度會(huì)比較慢。因?yàn)橹苯硬楹系臄?shù)據(jù)，受網(wǎng)絡(luò) IO 影響比較大。另外數(shù)據(jù)湖后臺(tái)的 Compaction 要求比較高，尤其流量特別大的時(shí)候，很難同時(shí)保證數(shù)據(jù)查詢的新鮮度和查詢性能的要求。

StarRocks 引出了一部分主鍵模型，能夠直接把 MySQL 或者原始數(shù)據(jù)直接打到主鍵模型里，通過(guò)主鍵的方式去更新，同一個(gè)主鍵，實(shí)現(xiàn)部分列的更新，是一種最佳實(shí)踐。

技術(shù)需求思考

通過(guò)上述場(chǎng)景分析，對(duì)技術(shù)需求可以總結(jié)為如下幾大類：

多表關(guān)聯(lián)

首先是對(duì) SQL 的支持，比如是否支持 IC SQL，還是會(huì)違背 IC SQL 的語(yǔ)法，有很多自己的 SQL 語(yǔ)法。引申就是有沒有一些 MySQL 協(xié)議或者是 PG 協(xié)議，直接可以去對(duì)接更好的 BI 工具，能夠較少地去改動(dòng)。

其次是對(duì) Join 的支持。對(duì)比 StarRocks 和 CK，可以看出來(lái)，StarRocks 對(duì)于分布式 Join 的支持是特別好的，因?yàn)樗?FE 去做整個(gè)的 CBO，比如有 5 張表去做 Join a，Join b，Join c，Join d、 Join e 以怎樣的順序去做 Join，這時(shí)就需要通過(guò) CBO 算法來(lái)挑出一個(gè)最好的方式。

另外是分布式 Join 的支持。StarRocks 還有一些其它的特性，通過(guò)數(shù)據(jù)的分布，實(shí)現(xiàn)一些 Join 的高級(jí)特性，比如 broadcast Join、shuffle Join，對(duì)比起來(lái) CK 這幾點(diǎn)就比較弱，因?yàn)?CK 最開始的時(shí)候是類似于以單機(jī)的形式拓展的分布式，它不是 MPP 架構(gòu)，而是 Scatter-Gather 的架構(gòu)。Scatter-Gather 架構(gòu)需要去手動(dòng)地把整個(gè)數(shù)據(jù)分成不同的 Shard，每一臺(tái)機(jī)器計(jì)算自己的 Shard，再把整個(gè)數(shù)據(jù)回吐到一個(gè)中心節(jié)點(diǎn)，這樣就相當(dāng)于是兩層架構(gòu)，對(duì)于 Join 的支持是很有限的。

多維查詢

需要關(guān)注性能和索引的支持是否完備，以及一些高級(jí)的特性比如物化視圖。物化視圖在 StarRocks 里是一種比較重要的特性，包括同步物化視圖、異步物化視圖、單表物化視圖、多表物化視圖等。

實(shí)時(shí)導(dǎo)入和查詢

是否有 Exactly Once 的語(yǔ)法保證。StarRocks 是能夠保證的。CK 也是支持事務(wù)的，但分布式事務(wù)存在一些缺陷。是否有 Update 功能，包括 Partial Update。Schema Change 的感知。列數(shù)的限制，寬表限制了 1000 列還是 1 萬(wàn)列是有本質(zhì)區(qū)別的。

開發(fā)效率、架構(gòu)和運(yùn)維

對(duì)于企業(yè)，開發(fā)效率、架構(gòu)、運(yùn)維難度可能更加重要，很多情況下企業(yè)人員并不是那么充足，運(yùn)維的簡(jiǎn)便就很重要，比如能否以最小代價(jià)彈性縮容，能否根據(jù)擴(kuò)縮容來(lái)自動(dòng)均衡，是否能夠達(dá)到高可用等等，都是非常實(shí)際的問題。開發(fā)效率方面，比如函數(shù)的支持是否完備，UDF 支持是否完備?，F(xiàn)在越來(lái)越多的客戶也都是湖倉(cāng)的架構(gòu)，本身有一些湖數(shù)據(jù)，這些數(shù)據(jù)是否可以不導(dǎo)進(jìn)來(lái)，可以直接查詢，也是一個(gè)特別常見的剛需。

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

整體架構(gòu)

上圖是 EMR 的整體架構(gòu)。以 ECS 或 Kubernetes 作為底座，主推方向是存算分離。左邊是 JindoFS 加上 OSS，我們叫做 HCFS， Hadoop Compatible FS。Spark、Presto 這些計(jì)算引擎，不需要更改任何接口，直接能夠?qū)右?OSS 為底座的 HCFS。其中有一些引擎是比較活躍的，也有一些基本上已經(jīng)退出了歷史舞臺(tái)。

上面是一些數(shù)據(jù)分析或者數(shù)據(jù)應(yīng)用平臺(tái)的組件，下面將介紹的是企業(yè)架構(gòu)。

Lambda 架構(gòu)

第一個(gè)是 Lambda 架構(gòu)，是最傳統(tǒng)的一套架構(gòu)，也是大廠現(xiàn)在用得最多的。離線和實(shí)時(shí)分別走不同的鏈路。圖中這一塊分層 ODS、DWD、DWS，放在 OLAP 的數(shù)據(jù)倉(cāng)庫(kù)里，這一層直接體現(xiàn)了報(bào)表的查詢響應(yīng)速度，可以用類似 Presto、Trino 這類引擎去查詢，這是比較傳統(tǒng)的架構(gòu)，這里最終加工出來(lái)的最后一層的報(bào)表，直接放在 OLAP 里。

實(shí)時(shí)數(shù)據(jù)湖解決方案

第二個(gè)是相對(duì)比較新的一種架構(gòu)，它提供了按主鍵 merger into 的能力，解決增量更新的場(chǎng)景。

這套架構(gòu)計(jì)算會(huì)比較頻繁，原來(lái)只是 T+1，現(xiàn)在則需要實(shí)時(shí)或者近實(shí)時(shí)，比如半小時(shí)，幾分鐘去做更新，逐漸向流批一體靠攏。因?yàn)?Iceberg、Hudi 兩個(gè)數(shù)據(jù)湖格式對(duì)批引擎和流引擎是完全適用的，這點(diǎn)在選型時(shí)大家也會(huì)著重考慮。對(duì)于查詢數(shù)據(jù)湖，有越來(lái)越多的客戶，從 Trino 或者 Presto 遷移到 StarRocks 上，因?yàn)槟壳?StarRocks 對(duì)于 Data Lake Analytics（DLA），也就是讀外表的數(shù)據(jù)，支持是非常好的。

大家如果關(guān)注 StarRocks 社區(qū)版 3.0 會(huì)了解到，除了 UDF，StarRocks 能夠提供和 Presto 一模一樣的語(yǔ)法，叫做 Presto Gateway，可以在不改 Presto 的 SQL 的情況下，就能夠查詢湖數(shù)據(jù)。這個(gè)能力將會(huì)包含在 EMR 2.5 的版本上。

最開始我們是最后一層 ADS 導(dǎo)入到 OLAP 中，現(xiàn)在有很多客戶是希望 ODS、DWD、DWS 里面挑選一些比較關(guān)鍵的表，提供比較高的性能，也導(dǎo)入到 OLAP 中，然后通過(guò) OLAP 完成高效的查詢。

實(shí)時(shí)分析解決方案

上圖是傳統(tǒng)的 Kappa 架構(gòu)，對(duì)于一些垂直業(yè)務(wù)線部門，不是數(shù)據(jù)中臺(tái)部門，需要做這樣一套數(shù)倉(cāng)來(lái)解決其業(yè)務(wù)問題。通常是用 Flink CDC 把 MySQL 的數(shù)據(jù)同步到 Kafka 里，數(shù)據(jù)一般存儲(chǔ) 7 天或者 3 天。雖然商業(yè)版的 Kafka 可以提供 KSQL，但在 Kafka 里查詢數(shù)據(jù)，性能一直都是不太好的。

所以通常把整個(gè) Kafka 數(shù)據(jù)通過(guò) routine load 直接導(dǎo)到數(shù)據(jù)倉(cāng)庫(kù)里面，或者直接導(dǎo)到 StarRocks 里面，這樣就能保證 ODS、DWD、DWS 這三層數(shù)據(jù)全部可以增量查到，也能夠去做整個(gè)的 OLAP，ODS 和 DWD 這兩層的表也可以去做一些 Join。

StarRocks 的物化視圖會(huì)在 2. 5 版本或者之后的幾個(gè)小版本才能夠比較穩(wěn)定地跑起來(lái)，現(xiàn)在提供的是類似于全量物化視圖，或是分區(qū)物化視圖，而不是那種完全的 Incremental 物化視圖。另外 2. 5 版本有外表物化視圖，也可以把一些比較重的表，或者是我們通常叫做大湖小倉(cāng)，把所有的數(shù)據(jù)放到湖里，需要的數(shù)據(jù)導(dǎo)到倉(cāng)里。導(dǎo)入到倉(cāng)里的時(shí)候也提供了一種比較暖心的方式，會(huì)去做外表的優(yōu)化視圖進(jìn)行數(shù)據(jù)的導(dǎo)入。比如按時(shí)間，每 10 分鐘導(dǎo)一次，把外表物化視圖直接導(dǎo)進(jìn) StarRocks 里邊，而不是用灌數(shù)據(jù)的方式。直接通過(guò)物化視圖的方式，內(nèi)部也會(huì)起更多的物化視圖，也會(huì)在物化視圖里邊去建物化視圖，這樣把每一層的數(shù)據(jù)全部都物化起來(lái)，這也是 StarRocks 社區(qū)版中主推的。

四、StarRocks 介紹

接下來(lái)介紹 StarRocks 的價(jià)值和一些關(guān)鍵技術(shù)。

StarRocks 價(jià)值 & 架構(gòu)

StarRocks 主打極速統(tǒng)一的概念，3. 0 也會(huì)主打云原生這一概念。統(tǒng)一方面，StarRocks 可以進(jìn)行多維分析、實(shí)時(shí)分析，包括高并發(fā)查詢、AD hoc 查詢，包括前面介紹的所有場(chǎng)景，希望能夠都統(tǒng)一起來(lái)，逐步在演化過(guò)程中，也慢慢地都開始做到了。在極速方面，StarRocks 對(duì)特別多的細(xì)節(jié)優(yōu)化得也相當(dāng)?shù)轿?。通過(guò) StarRocks 可以解決目前的大部分問題。

StarRocks 架構(gòu)簡(jiǎn)單。FE 如果是高可用，則是有三個(gè)節(jié)點(diǎn)，它是通過(guò) BDB 的庫(kù)去做 journal log 同步，類似于 raft 協(xié)議。BE 包括執(zhí)行引擎和 IO 的引擎。比如查數(shù)據(jù)湖時(shí)，數(shù)據(jù)不在本地，所以整個(gè) BE 節(jié)點(diǎn)，沒必要去啟動(dòng)存儲(chǔ)引擎，只需要計(jì)算引擎就可以。

StarRocks 核心技術(shù)特性

上圖中列出了向量化的優(yōu)化效果（2.1 版本）。對(duì)于幾個(gè)算子，比如 filter、group、shuffle Join、broadcast Join 等算子的性能提升是比較明顯的。只要查詢是非常重計(jì)算，輕 IO 的，最后整個(gè)查詢的性能提升會(huì)非常明顯。

StarRocks CBO 優(yōu)化器采用 Cascades 框架。其中 Join 的推算是用動(dòng)態(tài)規(guī)劃算法實(shí)現(xiàn)的。

分布式 Join 的能力包括 Shuffle Join、Bucket Join、Colocation Join 等。Colocation Join 是指不需要網(wǎng)絡(luò)傳輸，事先把兩張表的數(shù)據(jù)，需要被 Join 的 key 置于同一臺(tái)機(jī)器上，可以不走網(wǎng)絡(luò)，不走 shuffle 的過(guò)程，這樣能夠顯著加速 Join 的過(guò)程。但這種方式使用起來(lái)還是有一些門檻的，實(shí)際中不僅需要非常懂業(yè)務(wù)，還需要懂 Colocation Join 命中的規(guī)則，才能將其真正用起來(lái)。但是一般情況下 Shuffle Join，Bucket Join，Broadcast Join 也都?jí)蛴昧恕?/p>

實(shí)時(shí)分析方面，StarRocks 有一個(gè)比較重要的特性 —— 主鍵模型，也是不斷地在優(yōu)化中。1. 9 的版本開始出現(xiàn)主鍵模型，一直優(yōu)化到 2. 5 版本，經(jīng)歷了一年多，所以穩(wěn)定性、內(nèi)存的使用、以及 Partial Update 這些方面都表現(xiàn)優(yōu)異。

整體性能方面，如果是查詢數(shù)據(jù)湖外表，采用 TPCH 的標(biāo)準(zhǔn)跟 Trino 對(duì)比是 3- 5 倍的差距，數(shù)據(jù)來(lái)源 StarRocks 官網(wǎng)，或者是阿里云 EMR 官網(wǎng)。如果是在自己的業(yè)務(wù)，自己的 SQL 上，可能會(huì)有差異，但是有好有壞，如果查詢是 IO 瓶頸的，那無(wú)論計(jì)算還是索引優(yōu)化得多么好，也不一定有多大的提升，瓶頸卡在 IO 上，StarRocks 的向量化計(jì)算，包括一些高級(jí)的索引都沒用上。但 IO 用的不是特別多，主要都是在函數(shù)計(jì)算，或其它方面，算子運(yùn)行時(shí)間長(zhǎng)，那么提升可能會(huì)非常多。

SSB 100G 對(duì)比的是單表場(chǎng)景，數(shù)據(jù)來(lái)源 ClickBench 網(wǎng)站。在 CK 的優(yōu)勢(shì)領(lǐng)域，單表查詢上，StarRocks 目前表現(xiàn)也是比較突出。如果感興趣可以訪問 ClickBench 官網(wǎng)。

StarRocks 目前也有資源隔離能力，如果要自建 StarRocks，資源隔離能力用得是比較多的。如果是在阿里云的場(chǎng)景上，或者后續(xù)要推出存算分離的場(chǎng)景，資源隔離能力，可以去官網(wǎng)上參考，但是在我們的客戶里邊用的并不是特別多。

最后是副本自動(dòng)平衡的能力。如果去擴(kuò)一臺(tái)機(jī)器或者縮一臺(tái)機(jī)器，不需要去手動(dòng)做副本平衡，或者一臺(tái)機(jī)器壞了，或者一個(gè)副本壞了，都是由 FE 的 task 去做平衡。

五、客戶案例

某社交領(lǐng)域客戶

第一個(gè)案例是某社交領(lǐng)域客戶，他們最開始用的是 CK。在 StarRocks 2. 1 時(shí)，他們開始用 StarRocks 去做整個(gè)的關(guān)聯(lián)查詢，用 CK 去做寬表的查詢。但后來(lái)他們不愿意去維護(hù)兩個(gè)技術(shù)棧，所以就去掉了 CK，目前基本上用 StarRocks 支撐了所有的業(yè)務(wù)，包括用戶畫像、點(diǎn)查，以及傳統(tǒng)的 OLAP 多表關(guān)聯(lián)查詢。

某電商領(lǐng)域客戶

第二個(gè)案例是一個(gè)電商領(lǐng)域的客戶，它們有著非常強(qiáng)烈的統(tǒng)一 OLAP 的需求。之前他們的 OLAP 由于歷史原因用得特別亂，運(yùn)維人員又比較少，維護(hù)困難。最后統(tǒng)一到了 StarRocks 里。首先，他們看中了阿里云的專家支持能力；同時(shí)，也看中了社區(qū)的發(fā)展，在社區(qū)中提出的問題總能得到較快的回答；另外，StarRocks 基本滿足了他們所有的需求。

某在線教育客戶

在線教育這個(gè)案例中，之前是通過(guò) Hive 做小時(shí)級(jí)的更新，也無(wú)法實(shí)現(xiàn) Upsert 場(chǎng)景，后面遷移到了 Hudi 數(shù)據(jù)湖上，中間鏈路除了 Flink 也使用了 Spark。屬于大湖小倉(cāng)，他們把一些關(guān)鍵的、性能要求高的數(shù)據(jù)都導(dǎo)到 StarRocks 里，對(duì)性能要求不那么高的就通過(guò)外表的方式直接查詢 Hudi。經(jīng)過(guò)數(shù)月的生產(chǎn)實(shí)踐，目前已非常穩(wěn)定。

六、未來(lái)規(guī)劃

StarRocks3.x：極速統(tǒng)一 & 云原生

最后來(lái)介紹一下 StarRocks 3.x 版本的規(guī)劃。

包括幾條線，第一，繼續(xù)堅(jiān)持極速統(tǒng)一這一特性；第二，積極配合去做云原生，存算分離。

大家可能會(huì)有一個(gè)比較大的困惑，如果用 StarRocks 做倉(cāng)，那么我們提供的都是云盤，畢竟從成本上來(lái)看是要比 OSS 貴不少。所以是否能夠類似于 Snowflake，把整個(gè)數(shù)據(jù)全部放到 OSS 里邊，只是把云盤作為緩存層去做。

在 LakeHouse 這一部分，2. 3 的版本外表查詢已經(jīng)比較完備了，但是對(duì)于 Iceberg、 Hudi 的支持，還有很多工作要做。因?yàn)?StarRocks 社區(qū)是全球化的，在海外客戶對(duì)于 Iceberg 用的還是比較多的。

在 ETL 方面和 Snowflake 對(duì)標(biāo)，從 3. 0 StarRocks 已經(jīng)不是純內(nèi)存去做 ETL 了，會(huì)有 spill 框架。如果做一個(gè)比較大的 ETL 可以 Spill，有限的內(nèi)存就可以把數(shù)據(jù)算好。比如做 Hashmap，Hashmap 就可以去不斷地往磁盤里面去寫，有 Spill 的框架去支撐整個(gè)算子。

做 ETL 的時(shí)候并不像 Spark 那樣 stage by stage，把每一個(gè) stage 數(shù)據(jù)都存下來(lái)，保證容錯(cuò)性。思路是做得足夠快，比 Spark 快上幾倍，即使中間有問題，直接可以通過(guò)重算 Job 來(lái)解決。

但是 ETL 也有資源隔離的問題。資源硬隔離，指的不是用現(xiàn)在已有資源組的方式，而是用跟 Snowflake 一樣的架構(gòu)，不同的節(jié)點(diǎn)去算不同的數(shù)據(jù)，相當(dāng)于 OLAP 用一系列節(jié)點(diǎn)， ETL 用一系列節(jié)點(diǎn)，數(shù)據(jù)都存在 OSS 里邊，這樣能夠保證兩個(gè) Workload 同時(shí)發(fā)生，但互不影響，這也是很多客戶需要的。

目前 StarRocks 也在做多模的物化視圖，包括增量的物化視圖，流式的物化視圖。

還有一些比較小的點(diǎn)，包括統(tǒng)一導(dǎo)入、半結(jié)構(gòu)化數(shù)據(jù)。

編輯：黃飛

?