隨著開(kāi)源數(shù)據(jù)湖技術(shù)的快速發(fā)展以及湖倉(cāng)一體全新架構(gòu)的提出，傳統(tǒng)數(shù)據(jù)湖在事務(wù)處理、流式計(jì)算以及數(shù)據(jù)科學(xué)場(chǎng)景的限制逐漸得以優(yōu)化解決。 為了滿足用戶對(duì)數(shù)據(jù)湖探索分析的需求，StarRocks 在 2.5 版本開(kāi)始發(fā)布了諸多數(shù)據(jù)湖相關(guān)的重磅特性，為用戶提供更加開(kāi)箱即用的極速湖分析體驗(yàn)。

本文為您揭秘如何利用 StarRocks 特性開(kāi)啟數(shù)據(jù)湖的極速分析體驗(yàn)，同時(shí)展示用戶真實(shí)場(chǎng)景中的落地案例以及性能測(cè)試結(jié)果，最后對(duì) StarRocks DLA (Data Lake Analytics)未來(lái)的產(chǎn)品規(guī)劃做一些分享。

#01

站在Warehouse的當(dāng)下，思考Lakehouse的未來(lái)

—

整個(gè)大數(shù)據(jù)架構(gòu)逐步經(jīng)歷了這么幾個(gè)典型的發(fā)展階段：

Schema-on-Write 架構(gòu)：通過(guò)嚴(yán)格的建模范式約束，來(lái)支撐 BI 場(chǎng)景下的查詢負(fù)載，但在以存算一體為主流系統(tǒng)架構(gòu)的歷史背景下，數(shù)據(jù)量膨脹帶給用戶高昂維護(hù)成本，同時(shí)對(duì)異構(gòu)數(shù)據(jù)缺乏維護(hù)能力。

Scheme-on-Read 架構(gòu)：以 HDFS 為統(tǒng)一存儲(chǔ)層，并提供基礎(chǔ)的文件 API 來(lái)與查詢層進(jìn)行交互。這種架構(gòu)模式雖然一定程度上保證了 TCO 和文件格式開(kāi)放性，但由于應(yīng)用讀時(shí)才能感知數(shù)據(jù)質(zhì)量，也將數(shù)據(jù)治理問(wèn)題帶來(lái)的成本轉(zhuǎn)嫁給了下游應(yīng)用。

云上數(shù)據(jù)湖架構(gòu)：云上對(duì)象存儲(chǔ)逐步代替 HDFS，并逐步演化成：以對(duì)象存儲(chǔ)作為統(tǒng)一離線存儲(chǔ)， 以 Warehouse 作查詢加速雙層架構(gòu)。雖然這種雙層架構(gòu)同時(shí)保障了冷數(shù)據(jù)的存儲(chǔ)成本和熱數(shù)據(jù)的查詢性能，但伴隨而來(lái)的是多輪跨系統(tǒng) ETL，也就引入了 Pipeline 構(gòu)建時(shí)的工程復(fù)雜度。

伴隨數(shù)據(jù)湖架構(gòu)的現(xiàn)代化革新，用戶除了維護(hù)一個(gè) Apache Iceberg（以下簡(jiǎn)稱 Iceberg）/Apache Hudi（以下簡(jiǎn)稱 Hudi）湖存儲(chǔ)，更亟需一款高性能的查詢組件來(lái)滿足業(yè)務(wù)團(tuán)隊(duì)的分析需求，快速?gòu)臄?shù)據(jù)中獲得“見(jiàn)解”驅(qū)動(dòng)業(yè)務(wù)增長(zhǎng)。傳統(tǒng)的查詢引擎，例如 Apache Spark（以下簡(jiǎn)稱 Spark）/Presto/Apache Impala（以下簡(jiǎn)稱 Impala）等組件能夠支撐的數(shù)據(jù)湖上查詢負(fù)載性能有限。部分高并發(fā)低延時(shí)的在線分析場(chǎng)景依舊需要用戶維護(hù)一套 MPP 架構(gòu)的數(shù)倉(cāng)組件，多套組件伴隨而來(lái)的自然是系統(tǒng)復(fù)雜度和高昂的運(yùn)維代價(jià)。所以我們一直在暢想：有沒(méi)有可能使用 StarRocks 來(lái)幫助用戶搞定所有的分析場(chǎng)景？以“幫助用戶屏蔽復(fù)雜度，把簡(jiǎn)單留給用戶”為愿景，那我們可以做些什么？

其實(shí) StarRocks 早在 2.2 版本起，就引入了 Apache Hive（以下簡(jiǎn)稱 Hive）/Iceberg/Hudi 外部表等特性，并在離線報(bào)表、即席查詢等場(chǎng)景積累了成熟的用戶案例。從一條 SQL 的生命周期來(lái)說(shuō)，StarRocks 除了在查詢規(guī)劃階段 FE 節(jié)點(diǎn)對(duì) Hive metastore 發(fā)起元數(shù)據(jù)請(qǐng)求，以及執(zhí)行查詢計(jì)劃時(shí) BE 掃描對(duì)象存儲(chǔ)以外，其他階段可以實(shí)現(xiàn)高度的復(fù)用。這意味，一方面，得益于 CBO 和向量化執(zhí)行引擎帶來(lái)的特性，StarRocks 數(shù)據(jù)湖分析在內(nèi)存計(jì)算階段有明顯的優(yōu)勢(shì)；另一方面，我們也意識(shí)到，元數(shù)據(jù)服務(wù)請(qǐng)求和 DFS/對(duì)象存儲(chǔ)之上 Scan 等環(huán)節(jié)，在整個(gè) SQL 生命周期里可能會(huì)成為影響用戶查詢體驗(yàn)的關(guān)鍵。

從工程效率來(lái)說(shuō)，數(shù)據(jù)湖分析的前置工作，本質(zhì)是便捷高效地完成元數(shù)據(jù)服務(wù)和存儲(chǔ)的訪問(wèn)接入和同步工作。在這一場(chǎng)景里，2.2 版本之前的外部表要求用戶逐個(gè)手動(dòng)完成表結(jié)構(gòu)的配置，和 Presto/Trino 等產(chǎn)品相比，在易用性上還有一定差距。 從數(shù)據(jù)治理的角度來(lái)說(shuō)，構(gòu)架分析鏈路的關(guān)鍵環(huán)節(jié)之一就是，讓查詢層在接入時(shí)能夠遵循企業(yè)的數(shù)據(jù)安全規(guī)范，無(wú)論是元數(shù)據(jù)可見(jiàn)性還是表文件可訪問(wèn)性。如何構(gòu)建可信的數(shù)據(jù)安全屏障，打消架構(gòu)師在技術(shù)選型時(shí)的顧慮，也是 StarRocks 在大規(guī)模生產(chǎn)用例中進(jìn)行落地應(yīng)用的基礎(chǔ)前提。 將當(dāng)下面臨的問(wèn)題抽絲剝繭之后，StarRocks 數(shù)據(jù)湖分析便有了更加清晰的產(chǎn)品目標(biāo)：

Extreme performance：用極致查詢性能賦能數(shù)據(jù)驅(qū)動(dòng)的業(yè)務(wù)團(tuán)隊(duì)，讓用戶快速獲得對(duì)數(shù)據(jù)的見(jiàn)解

Out-of-box：需要提供更加開(kāi)箱即用的數(shù)據(jù)接入體驗(yàn)，以及更加安全合規(guī)的數(shù)據(jù)接入模式

Cost effective：為用戶提供具有性價(jià)比的資源持有方案，成為 Price-performance 維度的技術(shù)選型最優(yōu)解

Uniformed platform：StarRocks 是帶有自管數(shù)據(jù)的現(xiàn)代架構(gòu) MPP 數(shù)據(jù)庫(kù)。當(dāng)用戶分析內(nèi)部數(shù)據(jù)和外部數(shù)據(jù)時(shí)，如何帶來(lái)一致的數(shù)據(jù)管理體驗(yàn)，也是致力于現(xiàn)代湖倉(cāng)架構(gòu)的 StarRocks 面臨的核心挑戰(zhàn)之一。

#02全新的場(chǎng)景與挑戰(zhàn)—1查詢性能的挑戰(zhàn)

我們第一階段目標(biāo)是對(duì)標(biāo)主流的查詢引擎產(chǎn)品（例如 Presto/Trino），為數(shù)據(jù)湖上的查詢負(fù)載帶來(lái) 3-5 倍的性能提升。在團(tuán)隊(duì)向這一目標(biāo)推進(jìn)過(guò)程中，我們的產(chǎn)品也遭遇了場(chǎng)景差異性帶來(lái)的挑戰(zhàn)。不同于查詢內(nèi)表場(chǎng)景，對(duì)元數(shù)據(jù)服務(wù)以及分布式文件存儲(chǔ)的響應(yīng)波動(dòng)的魯棒性直接決定了用戶側(cè)的查詢體驗(yàn)是否平穩(wěn)。

在這里，我們以一條 Query on Hive 的生命周期來(lái)舉例，說(shuō)明不同階段我們遇到的問(wèn)題：

查詢規(guī)劃階段：若用戶查詢歷史明細(xì)數(shù)據(jù)，單條 Query 可能會(huì)同步觸發(fā)大量 Table Partition 的元數(shù)據(jù)請(qǐng)求，Metastore 的抖動(dòng)又會(huì)導(dǎo)致 CBO 等待超時(shí)，最終引發(fā)查詢失敗。這是一個(gè) Adhoc 場(chǎng)景中最典型的案例。在查詢規(guī)劃階段，如何在元信息拉取的全面性和時(shí)效性上做出體驗(yàn)最好的權(quán)衡？

資源調(diào)度階段：Adhoc 場(chǎng)景下的系統(tǒng)負(fù)載有明顯的峰谷差異，從資源成本角度出發(fā)，彈性擴(kuò)縮容自然是一個(gè)查詢組件在公有云場(chǎng)景需要具備的基礎(chǔ)特性。而在 StarRocks 存算一體的架構(gòu)里，BE 節(jié)點(diǎn)擴(kuò)縮容過(guò)程伴隨著數(shù)據(jù)重分布的代價(jià)。因此，如何才能為用戶提供容器化部署以及水平伸縮的可能性？另一方面，在大規(guī)模用例里經(jīng)常會(huì)出現(xiàn)多業(yè)務(wù)部門(mén)共享集群的場(chǎng)景，如何為運(yùn)行在數(shù)據(jù)湖上的查詢負(fù)載提供很好的隔離性，降低業(yè)務(wù)之間的影響？

查詢計(jì)劃生成階段：查詢數(shù)據(jù)湖時(shí)，目標(biāo)數(shù)據(jù)的文件分布決定了 Scan 過(guò)程的 IO 開(kāi)銷，而文件分布一般又取決于上游寫(xiě)入習(xí)慣與文件合并策略。對(duì)于上游 CDC 入湖過(guò)程中里的大量小文件，如何設(shè)計(jì)靈活 Scan Policy 才能緩解 IO 帶來(lái)的查詢性能瓶頸？

查詢執(zhí)行階段：我們都知道在生產(chǎn)環(huán)境中，HDFS 本身由于抖動(dòng)帶來(lái)訪問(wèn)延遲是很常見(jiàn)的現(xiàn)象，而這類抖動(dòng)就直接給查詢速度造成波動(dòng)，很影響業(yè)務(wù)用戶的分析體感。同時(shí)，Adhoc 場(chǎng)景本身的查詢習(xí)慣（例如針對(duì)全量歷史數(shù)據(jù)的一次聚合計(jì)算）決定了瓶頸并不在內(nèi)存計(jì)算而是在 IO 上。如何讓 Query 再快一點(diǎn)？想在外部存儲(chǔ)上直接優(yōu)化 IO 的問(wèn)題，最直接的想法就是針對(duì)局部性較強(qiáng)的查詢場(chǎng)景，提供針對(duì)遠(yuǎn)端存儲(chǔ)的數(shù)據(jù)文件 Cache 能力。

2數(shù)據(jù)管理的挑戰(zhàn) 借助 StarRocks 已有的全面向量化執(zhí)行引擎、全新的 CBO 優(yōu)化器等，這些能力能夠極大地提升我們?cè)趩伪硪约岸啾韺用娴男阅鼙憩F(xiàn)。在這個(gè)基礎(chǔ)之上，針對(duì)數(shù)據(jù)湖分析的場(chǎng)景，我們也增加了新的優(yōu)化規(guī)則。

相信關(guān)注 StarRocks 的讀者中很大一部分是基礎(chǔ)架構(gòu)領(lǐng)域的從業(yè)人員。但凡和業(yè)務(wù)團(tuán)隊(duì)打過(guò)交道，都會(huì)感同身受：推動(dòng)業(yè)務(wù)部門(mén)升級(jí)基礎(chǔ)技術(shù)組件，成本非常的高。對(duì)公司 IT 治理來(lái)說(shuō)，在每一次技術(shù)選型里，能否全面 cover 舊方案的基礎(chǔ)用例、把控業(yè)務(wù)遷移里的 bad case 同樣會(huì)影響選型成敗。此時(shí) StarRocks 就更需要站在工程師朋友的視角上，全面審視湖分析場(chǎng)景中“水桶的短板”到底在哪里。

數(shù)據(jù)安全：數(shù)據(jù)湖作為維護(hù)企業(yè)核心數(shù)據(jù)資產(chǎn)的基礎(chǔ)設(shè)施，一般在企業(yè)內(nèi)都會(huì)為其維護(hù)成熟的訪問(wèn)控制策略，例如，在傳統(tǒng) Hadoop 生態(tài)中基于 Kerberos 來(lái)定制統(tǒng)一認(rèn)證，用 Ranger 做統(tǒng)一 ACL 管理；或者是接入云廠商托管的 IAM 服務(wù)。這些不同場(chǎng)景下數(shù)據(jù)治理的事實(shí)標(biāo)準(zhǔn)，均是考量數(shù)據(jù)湖分析產(chǎn)品成熟度的重要參考。

業(yè)務(wù)遷移：在嘗試用 StarRocks 來(lái)幫助用戶替換存量的 Presto/SparkSQL 查詢負(fù)載的過(guò)程中，用戶需要同步遷移原有的業(yè)務(wù) SQL，甚至是 UDF。系統(tǒng)之間的語(yǔ)法糖差異越大，用戶在遷移過(guò)程里進(jìn)行 SQL 重寫(xiě)的成本就越高昂。面對(duì)引擎之間的語(yǔ)法差異，如何盡可能給用戶帶來(lái)平滑的遷移體感？

元數(shù)據(jù)管理：StarRocks 作為具有自管數(shù)據(jù)的 OLAP 系統(tǒng)，如果同時(shí)接入外部湖上的數(shù)據(jù)，意味著需要統(tǒng)籌管理系統(tǒng)內(nèi)部/外部的元數(shù)據(jù)，并通過(guò) StarRocks 展示統(tǒng)一視圖。系統(tǒng)外部元數(shù)據(jù)同步的數(shù)據(jù)一致性和開(kāi)箱即用如何權(quán)衡？

3社區(qū)協(xié)作的挑戰(zhàn) Eric S. Raymond 在《大教堂和集市》中說(shuō)，一個(gè)項(xiàng)目若想成功，“要將用戶當(dāng)做合作者”。開(kāi)源產(chǎn)品的成功，從來(lái)不止步于完成一個(gè)特性的開(kāi)發(fā)這么簡(jiǎn)單。

歷史上，Hive 在大數(shù)據(jù)生態(tài)中并不是產(chǎn)品力最出眾的，正是其對(duì)計(jì)算引擎的包容普適性逐步造就了其不可替代的位置。StarRocks 站在 OLAP 查詢層的角度也希望為社區(qū)用戶構(gòu)建一種普適性：于湖分析場(chǎng)景來(lái)說(shuō)，任意數(shù)據(jù)源的接入需求，社區(qū)開(kāi)發(fā)者都能夠快速流暢地完成接入開(kāi)發(fā)。優(yōu)雅高度抽象的代碼框架，理想中可以帶來(lái)一種雙贏的協(xié)作模式：用戶的需求能夠以社區(qū)互助的方式得到敏捷響應(yīng)，產(chǎn)品能力也可以像滾雪球一樣愈加豐滿，伴隨社區(qū)生態(tài)不斷成長(zhǎng)。

在這個(gè)愿景下，如何在起步階段定義出一個(gè)好的代碼框架，讓后續(xù)各類數(shù)據(jù)源對(duì)接的開(kāi)發(fā)工作對(duì)社區(qū)的工程師同學(xué)盡可能友好，又能平滑兼容各類外部數(shù)據(jù)系統(tǒng)的差異性，則是數(shù)據(jù)湖研發(fā)團(tuán)隊(duì)一個(gè)重點(diǎn)需要思考的問(wèn)題。

#03

思考和關(guān)鍵行動(dòng)

—

1數(shù)據(jù)湖生態(tài)全面完善

支持 Hudi 的 MOR 表（2.5.0 發(fā)布）

StarRocks 在 2.4 版本就通過(guò) Catalog 提供了 Hudi 數(shù)據(jù)的接入能力。在即將發(fā)布的 2.5.0 版本，StarRocks 將會(huì)支持以 Snapshot query 和 Read optimized query 兩種查詢模式來(lái)支持 Hudi 的 MOR 表。

借助該特性，在數(shù)據(jù)實(shí)時(shí)入湖場(chǎng)景（例如上游 Flink CDC 到 Hudi），StarRocks 就可以更好支持用戶對(duì)實(shí)時(shí)落盤(pán)數(shù)據(jù)的分析需求。

支持 Delta Lake Catalog（2.5.0 發(fā)布）

在 2.5.0 版本中，StarRocks 將正式通過(guò) Catalog 支持分析 Delta lake。目前支持以 Hive metastore 作為元數(shù)據(jù)服務(wù)，即將支持 AWS Glue。未來(lái)還將計(jì)劃逐步對(duì)接 Databricks 原生的元數(shù)據(jù)存儲(chǔ)。

通過(guò)這種方式，在 Spark 生態(tài)里批處理完成的數(shù)據(jù)，用戶就可以無(wú)需重復(fù)拷貝，直接在 StarRock 進(jìn)行交互式分析。

支持 Iceberg V2 表（在 2.5.X 即將發(fā)布）

StarRocks 在 2.4 版本就通過(guò) Catalog 提供了 Iceberg V1 數(shù)據(jù)的接入能力。在未來(lái)的 2.5 小版本中，我們即將正式支持對(duì)接 Iceberg V2 格式，全面打通 Iceberg 與 StarRocks 的數(shù)據(jù)生態(tài)。

支持 Parquet/ORC 文件外表

在部分場(chǎng)景下，用戶的數(shù)據(jù)文件直接由 Spark Job 或者其他方式寫(xiě)入 DFS 生成，并不具備一個(gè)存儲(chǔ)在 Metastore 中的完整 Schema 信息。用戶如果希望直接分析這些文件，按照以往只能全量導(dǎo)入 StarRocks 后再進(jìn)行分析。在一些臨時(shí)的數(shù)據(jù)分析場(chǎng)景下，這種全量導(dǎo)入的模式操作代價(jià)比較昂貴。

從 2.5.0 版本起，StarRocks 提供了文件外表的功能，用戶無(wú)需借助 Metastore 也可以直接對(duì) DFS/對(duì)象存儲(chǔ)的文件直接進(jìn)行分析，更可以借助 INSERT INTO 能力對(duì)目標(biāo)文件進(jìn)行導(dǎo)入前的結(jié)構(gòu)變換和預(yù)處理。對(duì)于上游以原始文件作為數(shù)據(jù)源的分析場(chǎng)景，這種模式更靈活友好。2開(kāi)箱即用的元數(shù)據(jù)接入方案

Multi-catalog (2.3.0已發(fā)布)

StarRocks 在 2.3 版本中發(fā)布了 Catalog 特性，同時(shí)提供了 Internal Catalog 和 External Catalog 來(lái)對(duì) StarRocks 內(nèi)部自有格式的數(shù)據(jù)以及外部數(shù)據(jù)湖中的數(shù)據(jù)進(jìn)行統(tǒng)一管理。

借助 External Catalog，用戶無(wú)需創(chuàng)建外部表即可對(duì)湖中的數(shù)據(jù)進(jìn)行分析，維護(hù) StarRocks 的平臺(tái)團(tuán)隊(duì)也無(wú)需維護(hù)兩個(gè)系統(tǒng)之間的元數(shù)據(jù)一致性。

開(kāi)箱即用的 Meta Cache policy（2.5.0發(fā)布）在 2.5 之前版本的 Hive catalog 里，元數(shù)據(jù)同步存在較多問(wèn)題。一旦 Hive 表發(fā)生了分區(qū)的新增或是分區(qū)內(nèi)數(shù)據(jù)發(fā)生了修改，往往需要用戶找到指定分區(qū)，并在 StarRocks 里手動(dòng)執(zhí)行 REFRESH PARTITION 才行。這對(duì)業(yè)務(wù)側(cè)的用戶帶來(lái)了較大困擾，因?yàn)闃I(yè)務(wù)分析師團(tuán)隊(duì)往往無(wú)法感知具體哪個(gè)分區(qū)發(fā)生了數(shù)據(jù)變更。 在 2.5 版本，我們優(yōu)化了這個(gè)系統(tǒng)行為，對(duì)于 Hive 追加分區(qū)，StarRocks 會(huì)在查詢時(shí)感知最新分區(qū)狀態(tài)；對(duì)于 Hive 分區(qū)中的數(shù)據(jù)更新，我們提供了REFRESH EXTERNAL TABLE 的方式來(lái)刷新最新的元數(shù)據(jù)狀態(tài)。 通過(guò)這種方式，Adhoc 場(chǎng)景里的業(yè)務(wù)團(tuán)隊(duì)無(wú)需關(guān)心具體的分區(qū)數(shù)據(jù)更新，也可以在 StarRocks 訪問(wèn)到具有正確性保證的數(shù)據(jù)結(jié)果。3完備的分析用例支持湖分析支持 Map&Struct（2.5.0發(fā)布）完整支持分析 Parquet/ORC 文件格式中的 Map 和 Struct 數(shù)據(jù)類型：

Global namespace 的 UDF（2.5.x 即將發(fā)布）在之前的 OLAP 場(chǎng)景中，StarRocks 的 UDF 是掛載在某個(gè) database 下進(jìn)行管理，Namespace 是 Database-level。這種模式在湖分析場(chǎng)景給用戶帶來(lái)一定的困擾，因?yàn)橛脩魺o(wú)法直接通過(guò) Function_name 來(lái)引用目標(biāo)函數(shù)，而是通過(guò) .. 來(lái)引用目標(biāo)函數(shù)。 這給從 Presto/Spark SQL 遷移查詢負(fù)載到 StarRocks 帶來(lái)了困擾，因?yàn)榇罅亢?UDF 相關(guān)的業(yè)務(wù) SQL 需要重新改寫(xiě)。為了徹底解決此問(wèn)題，我們計(jì)劃在 2.5 后續(xù)的小版本里為用戶提供了一種全新的 Global namepace UDF，從而無(wú)需任何改寫(xiě)操作就能夠幫助用戶更加平滑的遷移 SQL。

4極致性能體驗(yàn)Blockcache（2.5.0發(fā)布）

為了優(yōu)化重 IO 場(chǎng)景下的查詢場(chǎng)景，一方面降低熱數(shù)據(jù)查詢場(chǎng)景下，相同原始數(shù)據(jù)反復(fù)讀取的 IO 代價(jià)，另一方面緩解 DFS 本身波動(dòng)對(duì)查詢性能帶來(lái)的波動(dòng)，StarRocks 在 2.5.0 即將正式發(fā)布 Block cache 特性。

在 StarRocks 里，Block 是對(duì) DFS/對(duì)象存儲(chǔ)中原始文件按照一定策略切分后的數(shù)據(jù)對(duì)象，也是 StarRocks 對(duì)原始數(shù)據(jù)文件進(jìn)行緩存時(shí)的最小數(shù)據(jù)單元。當(dāng)查詢命中 DFS/對(duì)象存儲(chǔ)中文件后，StarRocks 會(huì)對(duì)命中的 Block 進(jìn)行本地緩存，支持內(nèi)存+本地磁盤(pán)的混合存儲(chǔ)介質(zhì)方式，并分別配置 Cache 對(duì)內(nèi)存和本地磁盤(pán)的占用空間上限?；?LRU 策略對(duì)遠(yuǎn)端對(duì)象存儲(chǔ)上的 Block 進(jìn)行載入和淘汰。

通過(guò)這種方式，大幅度優(yōu)化了 HDFS 本身抖動(dòng)的問(wèn)題，無(wú)需頻繁訪問(wèn) HDFS；同時(shí)對(duì)于熱點(diǎn)數(shù)據(jù)上的交互式探查場(chǎng)景，大大提升了遠(yuǎn)端對(duì)象存儲(chǔ)的數(shù)據(jù)拉取效率，用戶分析體驗(yàn)得到極大提升。更重要的是，整個(gè)緩存機(jī)制沒(méi)有引入任何的外部依賴，通過(guò)配置文件即可開(kāi)啟。

如下圖所示，以 100GB 的 SSB Benchmark 為例，實(shí)驗(yàn)中以使用純內(nèi)存作為緩存介質(zhì)，以阿里云 OSS 作為對(duì)象存儲(chǔ)。其中 lake_with_cache 是緩存命中率 100% 情況下的查詢性能，Native 是指數(shù)據(jù)導(dǎo)入 StarRocks 后的查詢性能，lake_with_cache 是無(wú)緩存直接訪問(wèn) OSS 的查詢性能。從圖中可以觀測(cè)到：在緩存完全命中的前提下，cache 后的數(shù)據(jù)查詢性能基本追平將數(shù)據(jù)導(dǎo)入 StarRocks 的性能。這意味著在部分簡(jiǎn)單場(chǎng)景下，借助 Blockcache 的能力，StarRocks 在已經(jīng)能夠支撐部分延遲要求更加苛刻的 SQL 負(fù)載。

5更加靈活的資源管理模式StarRocksonK8S（2.5.0即將發(fā)布）在 StarRocks 存算一體的背景下，為了加節(jié)點(diǎn)提升集群整體查詢負(fù)載的同時(shí)又不帶來(lái)數(shù)據(jù)重分布代價(jià)，社區(qū)開(kāi)發(fā)者們經(jīng)過(guò)長(zhǎng)達(dá) 3 個(gè)月的研發(fā)為社區(qū)貢獻(xiàn)了基于 K8S 的存算分離能力。具體來(lái)說(shuō)，從 2.4.0 版本起，通過(guò)在 BE 節(jié)點(diǎn)的基礎(chǔ)之上，就已經(jīng)重新抽象了一種無(wú)狀態(tài)的計(jì)算節(jié)點(diǎn)（Compute Node，簡(jiǎn)稱CN）。 在數(shù)據(jù)湖分析場(chǎng)景，CN 可以承擔(dān)從 Scan 到 Shuffle 到聚合全生命周期的計(jì)算流程。CN 除了支持用戶進(jìn)行免數(shù)據(jù)遷移的在線增減節(jié)點(diǎn)以外，還能夠通過(guò)容器化來(lái)進(jìn)行部署。在此基礎(chǔ)上，社區(qū)官方還提供了全新的 StarRocks Operator，能夠在實(shí)際業(yè)務(wù)場(chǎng)景中后端流量&日志量激增時(shí)，實(shí)時(shí)感知分析平臺(tái)的負(fù)載激增，并快速地自動(dòng)創(chuàng)建 Compute Node。同時(shí)，通過(guò) Kubernetes 的 HPA 功能完成 Compute Node 的彈性擴(kuò)縮容（該特性已經(jīng)在 2.4 版本發(fā)布）。內(nèi)核級(jí)別的靈活彈性，一方面，大大優(yōu)化了數(shù)據(jù)湖場(chǎng)景下用戶維護(hù) StarRocks 的 TCO，另一方面也給基于 StarRocks 構(gòu)建 Serverless 形態(tài)的湖分析產(chǎn)品提供了無(wú)限想象空間。

從 2.5.0 版本起，StarRocks 的 FE/BE 也基本完成了容器化部署的兼容。不久，社區(qū)官方 Operator 也即將發(fā)布，屆時(shí)將會(huì)大大提升運(yùn)維效率和生產(chǎn)力。

利用Resource group對(duì)湖上的分析負(fù)載進(jìn)行軟隔離（2.3.0已發(fā)布）

StarRocks 在 2.2 版本發(fā)布了資源隔離能力。在 2.3 版本支持了通過(guò)資源組來(lái)對(duì)數(shù)據(jù)湖上的查詢負(fù)載進(jìn)行隔離。通過(guò)這種軟隔離的資源劃分機(jī)制，能夠讓這些 Adhoc query 運(yùn)行時(shí)在特定的 CPU 核數(shù)/內(nèi)存范圍之下，用戶的大規(guī)模集群在同時(shí)支持多個(gè)部門(mén)的固定報(bào)表分析業(yè)務(wù)和 Adhoc 業(yè)務(wù)時(shí)，能夠具有更好的隔離性，湖上的大查詢相互之間可以優(yōu)先保障穩(wěn)定。

6湖倉(cāng)深度融合支持在數(shù)據(jù)湖上構(gòu)建自動(dòng)刷新的物化視圖（2.5.0發(fā)布）物化視圖是數(shù)據(jù)庫(kù)技術(shù)中的一種經(jīng)典查詢加速手段，主要給用戶帶來(lái)兩大價(jià)值點(diǎn)：查詢加速和數(shù)據(jù)建模。在 2.4 版本中，我們發(fā)布了全新的物化視圖，該物化視圖在語(yǔ)義上是一張用戶可感知并獨(dú)立查詢的表，具備將復(fù)雜查詢結(jié)果進(jìn)行物化并自動(dòng)刷新的能力。 從 2.5 版本開(kāi)始，StarRocks 支持直接在數(shù)據(jù)湖上構(gòu)建物化視圖，用戶只需要在創(chuàng)建物化視圖時(shí)，基于 INSERT INTO SELECT 定義好數(shù)據(jù)加工處理的邏輯以及自動(dòng)刷新的時(shí)間周期（例如 1 天），物化視圖便會(huì)自動(dòng)將湖上數(shù)據(jù)進(jìn)行處理，并把結(jié)果落盤(pán)在 StarRocks 的本地存儲(chǔ)上。同時(shí)考慮到 ODS 層全表掃描的代價(jià)比較重，例行執(zhí)行這類查詢會(huì)給內(nèi)存帶來(lái)大量不必要開(kāi)銷。對(duì)于 Hive 分區(qū)表場(chǎng)景，V2.5.0 的物化視圖還支持在創(chuàng)建時(shí)掃描最近 K 個(gè)分區(qū)數(shù)量，從而搭配分區(qū)裁剪來(lái)控制例行掃描的數(shù)據(jù)量。 參考下圖，我們可以看到前后對(duì)比：對(duì)于一些常見(jiàn)的 ETL 任務(wù)及其調(diào)度場(chǎng)景，我們無(wú)需再依賴外部系統(tǒng)，跨系統(tǒng)間的 ETL 鏈路也得到了縮短。對(duì)于平臺(tái)團(tuán)隊(duì)來(lái)說(shuō)，大大節(jié)約了運(yùn)維成本。 在 V2.5.X 的后續(xù)小版本，我們還即將針對(duì)數(shù)據(jù)湖上的查詢提供自動(dòng)路由能力。通過(guò)后臺(tái)查詢改寫(xiě)技術(shù)（Query rewrite），當(dāng)用戶的 SQL 查詢 Hive 時(shí)，系統(tǒng)會(huì)基于匹配程度將 Query 自動(dòng)路由到物化視圖上，直接返回提前聚合處理好的數(shù)據(jù)結(jié)果。對(duì)于物化視圖和源表數(shù)據(jù)存在不一致的場(chǎng)景，系統(tǒng)也會(huì)提供默認(rèn)兜底策略來(lái)優(yōu)先保證查詢結(jié)果的正確性。真正意義上實(shí)現(xiàn)統(tǒng)一一份元數(shù)據(jù)的前提下，盡可能給數(shù)據(jù)湖上的查詢負(fù)載帶來(lái) MPP 數(shù)據(jù)倉(cāng)庫(kù)的查詢并發(fā)和分析體驗(yàn)。

7公有云生態(tài)打通集成AWS Glue作為湖分析的Metastore，對(duì)云上數(shù)據(jù)資產(chǎn)進(jìn)行統(tǒng)一分析（2.5.0發(fā)布）根據(jù) AWS 官方文檔介紹，AWS Glue 作為完全兼容 Hive metastore 的統(tǒng)一目錄服務(wù)，為用戶 Region 內(nèi)的數(shù)據(jù)資產(chǎn)提供了統(tǒng)一視圖，并能夠在 EMR 中作為云原生的 Metastore 一鍵開(kāi)啟。這給公有云用戶在 EMR 上提供了開(kāi)箱即用的數(shù)據(jù)管理體驗(yàn)。同時(shí)，其內(nèi)置的 Crawlers 功能還可以輕松的幫助 S3 文件批量生成表 Schema，賦予其 Hive table 的語(yǔ)義，從而對(duì)各類查詢引擎的分析負(fù)載將會(huì)更加靈活友好。 StarRocks 為了給公有云用戶帶來(lái)更加云原生和一體化的數(shù)據(jù)分析體驗(yàn)，早在 2.3 版本就支持了阿里云的 Datalake formation 的集成，從 2.5.0 版本開(kāi)始正式支持以 AWS Glue 作為湖分析時(shí)的 Metastore。 借助這一特性，AWS 上的 StarRocks 用戶可以在 AWS Glue 里控制元數(shù)據(jù)的訪問(wèn)權(quán)限；也可以通過(guò) StarRocks 湖分析能力，借助更高效的查詢性能，使用 SQL 按需分析對(duì)象存儲(chǔ)文件，同時(shí)保證了安全和數(shù)據(jù)分析效率。

深度集成AWS IAM，支持Secret key&IAM Role等多種認(rèn)證方式（在2.5.X即將發(fā)布）除了性能維度，數(shù)據(jù)安全從來(lái)都是數(shù)據(jù)湖分析場(chǎng)景里做技術(shù)選型的重中之重。在過(guò)往積累的海內(nèi)外用戶案例里，我們注意到云廠商給對(duì)象存儲(chǔ)等云資源提供了完整的認(rèn)證和訪問(wèn)管理機(jī)制（IAM），而我們的用戶也會(huì)根據(jù)不同云廠商的 IAM 產(chǎn)品邏輯來(lái)定義符合企業(yè)安全需求的數(shù)據(jù)訪問(wèn)規(guī)范。以 Amazon Cloud Service 為例，這些用戶常用的云資源訪問(wèn)管理策略包括但不限于：

通過(guò)統(tǒng)一的 Access key/Secret key 來(lái)進(jìn)行用戶身份進(jìn)行認(rèn)證和鑒權(quán)

通過(guò) IAM Role 搭配角色代理的機(jī)制，來(lái)實(shí)現(xiàn)不同角色身份的動(dòng)態(tài)切換

借助 AWS EC2 的 Instance profile 中自帶的身份信息進(jìn)行認(rèn)證

在未來(lái)的 V2.5.X 小版本里，StarRocks 數(shù)據(jù)湖分析將會(huì)對(duì)上述幾種公有云場(chǎng)景用戶常用的認(rèn)證方式進(jìn)行完備的兼容。未來(lái) StarRocks 在公有云上的數(shù)據(jù)訪問(wèn)管理將會(huì)更加省心省力，數(shù)據(jù)安全不再成為企業(yè)云上 OLAP 技術(shù)選型的顧慮。

#04

Benchmark驗(yàn)證

—1StarRocks vs Presto(Trino)

SSB Flat on Hive

以 2.5 最新版本為基準(zhǔn)，StarRocks 和業(yè)界最主流的湖分析引擎 Trino 367 在 100GB 的 SSBFlat 測(cè)試集（HDFS）上分別進(jìn)行了查詢 Hive 的性能測(cè)試對(duì)比。并行度均為 8，Cache 均未開(kāi)啟。

在大寬表場(chǎng)景下，相比 Trino，StarRocks 在 Hive 上有 2-3 倍的性能提升。

TPCH on Hudi

在 100GB 的 TPCH 場(chǎng)景下，我們還和 Presto 對(duì)比了在 COW 表上的查詢性能。從圖中可以看見(jiàn)，在 COW 表上，相比 Presto，StarRocks 的查詢性能有 3-5 倍不等的穩(wěn)定性能提升。

另外，我們還針對(duì)了 MOR 存在的更新場(chǎng)景，和 Presto 進(jìn)行了一個(gè)對(duì)比實(shí)驗(yàn)。下圖中，Presto 的場(chǎng)景最簡(jiǎn)單，無(wú)數(shù)據(jù)更新；而 StarRocks 查詢 MOR 時(shí)候分別對(duì)比了無(wú)更新和有數(shù)據(jù)更新的場(chǎng)景（查詢模式均為 Snapshot query）?？梢杂^察到，面對(duì)無(wú)更新的 MOR 表，StarRocks（下圖深藍(lán)線） 整體性能能夠穩(wěn)定的提升 3-5 倍。在數(shù)據(jù)更新占比分別為 10%（下圖綠色線）、30%（下圖淺藍(lán)線）、50%（下圖黃色線）的場(chǎng)景中，StarRocks 在承擔(dān)文件讀時(shí)合并開(kāi)銷的前提下，查詢性能依舊大幅超越 Presto（下圖深紅線）。

TPCH on Iceberg

在 100GB 的 TPCH 場(chǎng)景下，我們也和 Presto 在 Iceberg v1 format 上做了性能對(duì)比?？梢杂^測(cè)到，平均性能整體上有 3-5 倍不等的提升。

除了在標(biāo)準(zhǔn)測(cè)試集進(jìn)行的驗(yàn)證，StarRocks 的湖分析特性也在各類企業(yè)用戶的生產(chǎn)環(huán)境中得到了大規(guī)模驗(yàn)證，幫助用戶在分析效能和數(shù)據(jù)加工成本上獲得了提升：

華米科技基于 StarRocks 構(gòu)建了 Hive 分析平臺(tái)，對(duì)接了企業(yè)內(nèi)的 Superset 等 BI 工具。并維護(hù)專用 StarRocks 集群用來(lái)承接 Hive 上的查詢負(fù)載，相比于原 SparkSQL，給業(yè)務(wù)分析團(tuán)隊(duì)極大的提升了取數(shù)分析的效率。后續(xù)關(guān)于 GlobalUDF 等特性也將助力更多的業(yè)務(wù) SQL 平滑遷移到 StarRocks 上面來(lái)。

在汽車(chē)之家的自助分析平臺(tái)場(chǎng)景，內(nèi)部的多引擎融合分析平臺(tái)選擇集成了 StarRocks 來(lái)作為 Hive 的統(tǒng)一查詢層。用真實(shí)線上業(yè)務(wù) SQL 測(cè)試后對(duì)比 Presto 集群，根據(jù)觀測(cè)結(jié)果顯示，80% 的真實(shí)業(yè)務(wù) SQL 負(fù)載有了 3 倍不等的性能提升。后續(xù)伴隨關(guān)于 Map&Struct 數(shù)據(jù)類型的新特性上線，也將進(jìn)一步提升 StarRocks 對(duì)業(yè)務(wù) SQL 查詢負(fù)載支持的完備程度。

騰訊游戲基于 StarRocks 在 Iceberg 數(shù)據(jù)湖上構(gòu)建了存算分離的 Serverless 數(shù)據(jù)分析架構(gòu)，支撐了單表 TB 級(jí)別的湖分析場(chǎng)景，并落地了性能和成本均衡的云原生架構(gòu)方案。

理想汽車(chē)基于 StarRocks 的 Hive 外表替換了 Impala。一方面通過(guò)外表 Join 等特性縮短了數(shù)據(jù)加工的鏈路，同時(shí)也緩解了原 Hadoop 集群的運(yùn)維壓力。

#05

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

—

1Table Sink in Datalake 從 2.5 版本開(kāi)始，我們就會(huì)陸續(xù)強(qiáng)化 StarRocks 針對(duì) Iceberg/Hudi 等主流數(shù)據(jù)湖的 Table sink 能力。借助這一能力，對(duì)于用戶通過(guò) StarRocks 探查分析得到的結(jié)果集，隨時(shí)都可以通過(guò) CREATE TABLE AS SELECT ... 的方式回寫(xiě)到數(shù)據(jù)湖當(dāng)中，使得這些數(shù)據(jù)資產(chǎn)能夠基于數(shù)據(jù)湖本身的 Open table format 在不同的引擎/服務(wù)之間實(shí)現(xiàn)自由共享，告別反復(fù)的遷移復(fù)制。2跨引擎語(yǔ)法兼容

不同查詢引擎之間有各自的語(yǔ)法糖。一旦業(yè)務(wù)團(tuán)隊(duì)的分析行為依賴這些語(yǔ)法糖，那么使用 StarRocks 對(duì) Presto/Trino 等存量系統(tǒng)的替換過(guò)程就變得更加繁瑣。因?yàn)檫@涉及到業(yè)務(wù) SQL 改寫(xiě)，給用戶也帶來(lái)了額外的困擾和成本。

為了幫助用戶更加省心地實(shí)現(xiàn)統(tǒng)一湖倉(cāng)分析，StarRocks 計(jì)劃在系統(tǒng)內(nèi)分階段提供針對(duì)多種查詢引擎的 Parser 插件，并幫助用戶自動(dòng)跨引擎的語(yǔ)法樹(shù)自動(dòng)轉(zhuǎn)換。借助這個(gè)能力，用戶通過(guò) Client 連接 StarRocks 時(shí)，只需要手動(dòng)指定當(dāng)前會(huì)話生效的 Parser 類型，即可將其他引擎的原生 SQL 直接運(yùn)行在 StarRocks 的 MPP 架構(gòu)之上。既避免了 SQL 遷移改寫(xiě)，又可以直接享受到 StarRocks 的極速分析性能。3Azure/Google Cloud Platform集成 StarRocks 這兩年產(chǎn)品力的進(jìn)步有目共睹，國(guó)內(nèi)各大云廠商也陸陸續(xù)續(xù)在 EMR 上為用戶提供了 StarRocks 的托管式服務(wù)，這正是社區(qū)用戶廣泛呼聲的最強(qiáng)論證。作為一個(gè)無(wú)國(guó)界、開(kāi)放包容的開(kāi)源社區(qū)，StarRocks 也有計(jì)劃在全球公有云的復(fù)雜場(chǎng)景中繼續(xù)深度打磨和成長(zhǎng)。目前，StarRocks 已經(jīng)和 Amazon Web Service 完成了主要的生態(tài)組件集成，并陸陸續(xù)續(xù)開(kāi)始承載全球公有云用戶的一些核心分析業(yè)務(wù)。未來(lái)還計(jì)劃全面支持 Google Cloud Platform 和 Azure Cloud。4在物化視圖上拓展增量查詢語(yǔ)義，構(gòu)建增量數(shù)據(jù)Pipeline

物化視圖是連接數(shù)據(jù)湖和數(shù)據(jù)倉(cāng)庫(kù)的一個(gè)天然樞紐。在 Hadoop 時(shí)代，MapReduce 計(jì)算框架和 Hive format 還沒(méi)有能力去識(shí)別和處理增量數(shù)據(jù)，因此整個(gè) ETL Pipeline 還是在分區(qū)級(jí)別Scan的查詢語(yǔ)義上構(gòu)建的，這帶來(lái)了時(shí)效性和計(jì)算效率低下的瓶頸。

在基于 StarRocks 構(gòu)建湖倉(cāng)一體架構(gòu)的時(shí)候，我們就在思考：既然主流的數(shù)據(jù)湖 Table format 均能夠支持訪問(wèn)增量數(shù)據(jù)，而物化視圖又能夠自動(dòng)完成湖倉(cāng)之間的 ETL，為什么我們不直接讓整個(gè) Pipeline 基于增量的查詢語(yǔ)義來(lái)構(gòu)建？對(duì)于增量實(shí)時(shí)入湖的場(chǎng)景，增量 Pipeline 既能夠節(jié)約重復(fù)掃描歷史數(shù)據(jù)的開(kāi)銷。借助增量微批的計(jì)算模型把每次計(jì)算的代價(jià)降低，從而使湖倉(cāng)之間的同步和建模計(jì)算可以更加頻繁，獲得更高的時(shí)效性。

因此，在數(shù)據(jù)湖上拓展增量查詢的語(yǔ)義，未來(lái)也會(huì)是物化視圖支撐湖倉(cāng)一體化融合的一個(gè)重要思路。5批處理能力強(qiáng)化 批處理能力是建模場(chǎng)景的基礎(chǔ)能力，而這也正是 StarRocks 需要持續(xù)強(qiáng)化的地方。之前用戶傾向于將數(shù)據(jù)建模好后導(dǎo)入 StarRocks 承接查詢負(fù)載。在數(shù)據(jù)湖場(chǎng)景里，我們需要支撐用戶能夠?qū)?ODS 層的明細(xì)數(shù)據(jù)按需進(jìn)行靈活加工和處理，并寫(xiě)入 StarRocks 或者直接將查詢結(jié)果處理后回寫(xiě)到湖中，批處理能力是對(duì) MPP 架構(gòu)的一個(gè)重大挑戰(zhàn)，也是未來(lái)我們重點(diǎn)強(qiáng)化的場(chǎng)景之一。6外部數(shù)據(jù)細(xì)粒度權(quán)限管理 目前我們對(duì)外部數(shù)據(jù)的權(quán)限管理還停留在 Catalog 級(jí)別，這種看似簡(jiǎn)單的數(shù)據(jù)訪問(wèn)方式也帶來(lái)了數(shù)據(jù)權(quán)限放大的隱患。在 3.0 版本后，我們將會(huì)給用戶提供全新的 RBAC 權(quán)限管理模型，其中也會(huì)提供幫助用戶實(shí)現(xiàn) Database 和 External table 級(jí)別訪問(wèn)管理的全新能力。

#06

寫(xiě)在最后

—

自 Databricks 的論文面世，Lakehouse 成了大數(shù)據(jù)從業(yè)者津津樂(lè)道的行業(yè)藍(lán)圖。但這套架構(gòu)是否能替代 Warehouse 支持當(dāng)下的所有主流場(chǎng)景用例，顯然現(xiàn)在下結(jié)論也許為時(shí)過(guò)早，每一個(gè)新技術(shù)在上升期過(guò)后也多多少少都會(huì)面臨“跨越鴻溝”的挑戰(zhàn)。成為一款最適合湖分析場(chǎng)景的產(chǎn)品，也遠(yuǎn)遠(yuǎn)不是做好一個(gè) feature 這么簡(jiǎn)單。

順著 Lakehouse 這個(gè)方向望向前方，依舊有很多的全新的挑戰(zhàn)在等待 StarRocks。實(shí)時(shí)數(shù)倉(cāng)與流式引擎的關(guān)系，表格式讀取接口的開(kāi)放與封閉，元數(shù)據(jù)如何實(shí)現(xiàn)更靈活的訪問(wèn)共享，這些都是我們未來(lái)需要思考和解決的問(wèn)題。

從 2.1 版本開(kāi)始，StarRocks 花費(fèi)了大量精力來(lái)思考和探索：在數(shù)據(jù)湖時(shí)代我們能給用戶帶來(lái)的價(jià)值在哪里？企業(yè)工程師和社區(qū)開(kāi)發(fā)者需要理解一個(gè)邏輯：采用新式數(shù)據(jù)湖架構(gòu)，并不意味著我們需要徹底拋棄 MPP 數(shù)倉(cāng)架構(gòu)的諸多特性。如何利用 StarRocks 在優(yōu)化器/計(jì)算引擎/存儲(chǔ)引擎等諸多能力優(yōu)勢(shì)，幫助用戶進(jìn)一步釋放湖上數(shù)據(jù)分析的無(wú)限想象空間，正是 StarRocks DLA 這個(gè)項(xiàng)目的核心價(jià)值所在。

StarRock V2.5 對(duì) DLA 來(lái)說(shuō)是一個(gè)重要轉(zhuǎn)折點(diǎn)，我們?cè)诤治鰣?chǎng)景里的思路也愈加清晰。如何利用 StarRocks 更好地支持湖分析場(chǎng)景，助力用戶完成 OLAP 層統(tǒng)一？敬請(qǐng)關(guān)注我們的社區(qū)動(dòng)態(tài)和 Release Plan。

審核編輯 ：李倩