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

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

#01

站在Warehouse的當下，思考Lakehouse的未來

—

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

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

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

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

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

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

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

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

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

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

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

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

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

在這里，我們以一條 Query on Hive 的生命周期來舉例，說明不同階段我們遇到的問題：

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

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

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

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

2數(shù)據(jù)管理的挑戰(zhàn) 借助 StarRocks 已有的全面向量化執(zhí)行引擎、全新的 CBO 優(yōu)化器等，這些能力能夠極大地提升我們在單表以及多表層面的性能表現(xiàn)。在這個基礎(chǔ)之上，針對數(shù)據(jù)湖分析的場景，我們也增加了新的優(yōu)化規(guī)則。

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

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

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

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

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

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

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

#03

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

—

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

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

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

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

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

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

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

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

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

支持 Parquet/ORC 文件外表

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7公有云生態(tài)打通集成AWS Glue作為湖分析的Metastore，對云上數(shù)據(jù)資產(chǎ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 一鍵開啟。這給公有云用戶在 EMR 上提供了開箱即用的數(shù)據(jù)管理體驗。同時，其內(nèi)置的 Crawlers 功能還可以輕松的幫助 S3 文件批量生成表 Schema，賦予其 Hive table 的語義，從而對各類查詢引擎的分析負載將會更加靈活友好。 StarRocks 為了給公有云用戶帶來更加云原生和一體化的數(shù)據(jù)分析體驗，早在 2.3 版本就支持了阿里云的 Datalake formation 的集成，從 2.5.0 版本開始正式支持以 AWS Glue 作為湖分析時的 Metastore。 借助這一特性，AWS 上的 StarRocks 用戶可以在 AWS Glue 里控制元數(shù)據(jù)的訪問權(quán)限；也可以通過 StarRocks 湖分析能力，借助更高效的查詢性能，使用 SQL 按需分析對象存儲文件，同時保證了安全和數(shù)據(jù)分析效率。

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

通過統(tǒng)一的 Access key/Secret key 來進行用戶身份進行認證和鑒權(quán)

通過 IAM Role 搭配角色代理的機制，來實現(xiàn)不同角色身份的動態(tài)切換

借助 AWS EC2 的 Instance profile 中自帶的身份信息進行認證

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

#04

Benchmark驗證

—1StarRocks vs Presto(Trino)

SSB Flat on Hive

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

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

TPCH on Hudi

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

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

TPCH on Iceberg

在 100GB 的 TPCH 場景下，我們也和 Presto 在 Iceberg v1 format 上做了性能對比。可以觀測到，平均性能整體上有 3-5 倍不等的提升。

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

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

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

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

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

#05

未來規(guī)劃

—

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

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

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

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

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

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

#06

寫在最后

—

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

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

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

StarRock V2.5 對 DLA 來說是一個重要轉(zhuǎn)折點，我們在湖分析場景里的思路也愈加清晰。如何利用 StarRocks 更好地支持湖分析場景，助力用戶完成 OLAP 層統(tǒng)一？敬請關(guān)注我們的社區(qū)動態(tài)和 Release Plan。

審核編輯 ：李倩