StarRocks 又發(fā)新版本了，這次動作有點大。

8 月 7 日，StarRocks 3.1 重磅發(fā)布。新版本中，StarRocks 將影響性能表現(xiàn)的技術(shù)要素全部從存算一體架構(gòu)引入到了存算分離架構(gòu)，并針對云原生環(huán)境里的易用性、穩(wěn)定性進行了一系列的優(yōu)化。

最終的結(jié)果是，這一版本的 StarRocks，已經(jīng)讓存算分離架構(gòu)下的數(shù)據(jù)查詢、導(dǎo)入像在一體架構(gòu)下一樣絲滑，兩者性能已基本持平。

如果說 4 個月前 StarRocks3.0 的發(fā)布是 StarRocks 向存算分離的一次華麗轉(zhuǎn)身，那么 3.1 版本的發(fā)布則宣告StarRocks 已徹底投入云原生湖倉大潮，踏上了新的臺階。

鑒于 StarRocks 歷來在性能方面的生猛表現(xiàn)，3.1 版本無疑將對整個行業(yè)產(chǎn)生深遠影響。

主動擁抱存算分離大勢，StarRocks 華麗轉(zhuǎn)身

在 3.0 版本之前，StarRocks 基于存算一體架構(gòu)構(gòu)建的產(chǎn)品能力其實已經(jīng)非常強悍，不僅在技術(shù)上擁有傲視業(yè)界的性能，在商業(yè)上，全場景的 OLAP 解決方案也已得到 260 家市值 70 億元以上的頭部企業(yè)用戶的認可。

但在存算分離架構(gòu)越來越成為行業(yè)趨勢的背景下，StarRocks 并未因既有的成功而遲疑，而是理性看待原有架構(gòu)中存中的彈性不足、計算資源浪費等問題，毅然選擇主動擁抱潮流。

在 3.0 版本中，StarRocks 構(gòu)建了統(tǒng)一的存算分離平臺 StarOS，將存儲與計算解耦，從根本上突破了原有架構(gòu)的局限性。

需要指出的是，盡管存算分離概念并不新鮮，但僅就國內(nèi) OLAP 數(shù)據(jù)庫領(lǐng)域而言，在 StarRocks3.0 以前，業(yè)界尚無成熟好用的基于存算分離架構(gòu)的分析型數(shù)據(jù)庫。

StarRocks3.0 一經(jīng)發(fā)布，就引發(fā)了全行業(yè)的關(guān)注，其支撐的低成本、高彈性的云原生 OLAP 方案也在短時間內(nèi)就吸引了眾多用戶嘗鮮使用，現(xiàn)在更已深度融入到各種分析運維場景之中。

從轉(zhuǎn)身到蛻變，StarRocks 全面擁抱云原生

在從一體架構(gòu)向分離架構(gòu)的遷移中，涉及到極其繁雜的架構(gòu)改造工作.

3.1 版本中，原有架構(gòu)中主鍵表模型、自增列屬性、時間函數(shù)表達式分區(qū)等影響到性能體驗的技術(shù)要素都已全部遷移到新架構(gòu)。

現(xiàn)在的 StarRocks，在打開 Data cache 的情況下，存算分離架構(gòu)與存算一體架構(gòu)在查詢性能、導(dǎo)入性能上都已基本持平。

與此同時，3.1 版本還進一步加強了與其它數(shù)據(jù)組件的連接，新增支持了 Elasticsearch catalog、Paimon catalog，并增強了 Trino 語法兼容性，強化了與Iceberg Catalog 的連通性，這些都使得 StarRocks 在云原生環(huán)境下的數(shù)據(jù)運維變得更加方便。

不忘初心，StarRocks 仍在探測性能極限

StockRocks 的核心優(yōu)勢是極致性能、使用簡便、穩(wěn)定可靠，在新架構(gòu)下，StarRocks 仍然以性能、易用性、高可用為設(shè)計開發(fā)導(dǎo)向，堅定有力地提升著產(chǎn)品體驗和能力邊界。

在新版本中，異步物化視圖的使用更簡單了，同步物化視圖則已支持所有算子，而對分桶功能的優(yōu)化則讓用戶不必再關(guān)心分桶配置……種種深入到微觀運維層面的產(chǎn)品細節(jié)，共同構(gòu)筑出了幅近乎完美的使用圖景。

此外，3.1 版本還新增了生成列功能、基數(shù)保持 JOIN 表裁剪等加速手段，進一步發(fā)掘了新架構(gòu)下的性能潛力。

毫無疑問，在存算一體架構(gòu)分析型數(shù)據(jù)庫領(lǐng)域“跑得最快”的 StarRocks，遷移到存算分離架構(gòu)后，依然是那個讓人熟悉的領(lǐng)跑者。

新增核心功能介紹

主鍵模型表也有了，存算分離架構(gòu)下查詢導(dǎo)入都更絲滑

業(yè)界領(lǐng)先的極致性能體驗一直是StarRocks 引以為傲的核心優(yōu)勢之一，在向存算分離架構(gòu)遷移之初，StarRocks 就在極力還原分離架構(gòu)中的性能優(yōu)勢。

3.1 版本，StarRocks 已經(jīng)基本將影響性能表現(xiàn)的技術(shù)要素全部引入到了分離架構(gòu)，相對于3.0版本，主鍵模型表(包括支持部分列更新，但暫不支持持久化索引)、自增列屬性 AUTO_INCREMENT、時間函數(shù)表達式分區(qū)及導(dǎo)入時自動創(chuàng)建分區(qū)都已得到完美支持。

此外，專門針對分離架構(gòu)打造的數(shù)據(jù)緩存功能在新版本也實現(xiàn)了進一步的優(yōu)化，通過對熱數(shù)據(jù)緩存范圍的個性化調(diào)節(jié)，即能靈活適配實際使用場景中冷熱數(shù)據(jù)的界定，有效減少冷數(shù)據(jù)對緩存的占用，從而提升熱數(shù)據(jù)查詢性能。

在打開 Data cache 的情況下，存算分離架構(gòu)與存算一體架構(gòu)在查詢性能、導(dǎo)入性能上都已基本持平。也就是說，StarRocks3.1的存算分離架構(gòu)，在大幅降低用戶存儲成本的同時，查詢、導(dǎo)入都已經(jīng)像一體架構(gòu)一樣絲滑。

在 Icerberg 內(nèi)也能建表了，數(shù)據(jù)湖分析運維越來越輕松

StarRocks 一直在強調(diào)對大數(shù)據(jù)生態(tài)的融合，從一線運維人員的視角出發(fā)，細微關(guān)注 StarRocks 與其它優(yōu)秀的、主流的數(shù)據(jù)組件的連接需求，不斷提升易用性，讓運維變得越來越輕松。

3.1 版本著重增強了與Iceberg Catalog 的連通性，相對于3.0版本，3.1版本不僅支持對 Parquet 格式的 Icerberg v2 MOR 表的查詢訪問，還新增了對 Iceberg 元數(shù)據(jù)的內(nèi)存+磁盤的兩級緩存，有效提升了查詢性能，在元數(shù)據(jù)文件較大的情況下性能升級效果尤其顯著。

在寫入能力上，則是新增支持了在 Icerberg 內(nèi)創(chuàng)建數(shù)據(jù)庫、表，并通過 INSERT INTO/OVERWRITE 寫入 Parquet 格式數(shù)據(jù)。通過開放數(shù)據(jù)格式，用戶即可以將 StarRocks 的處理結(jié)果無縫接入到生態(tài)內(nèi)的其他組件。

除Iceberg Catalog外，3.1 版本還新增支持了 Elasticsearch catalog[5]、Paimon catalog[6]，并進一步增強了 Trino語法兼容性。

執(zhí)行策略可以單獨配置了，物化視圖應(yīng)用場景大大拓展

物化視圖因其強大的加速效果，是 StarRocks 的核心功能之一，在歷個版本中，StarRocks 都對物化視圖進行了大量的優(yōu)化、升級，不斷提升著易用性、靈活性，使其變得更好用、更管用。

在3.1版本中，不管是同步物化視圖，還是異步物化視步，同樣都作了大量的優(yōu)化，使用體驗和適用場景都有質(zhì)的提升。

異步物化視圖

自 2.4 版本推出異步物化視圖以來，這一功能已深度融入用戶的查詢加速、數(shù)倉建模等場景，而StarRocks 也致力于讓異步物化視圖擁有與內(nèi)表相同的加速和管理能力，在 3.1 版本中：

支持通過ORDER BY 指定排序鍵，支持設(shè)置colocate_group，進一步利用 StarRocks 原生存儲的優(yōu)化來加速物化視圖的查詢性能。

支持配置存儲介質(zhì)和降冷時間(storage_medium 、cooldown_time )，方便數(shù)據(jù)的生命周期管理。

支持不指定分桶，默認采用隨機分桶，提升創(chuàng)建物化視圖的易用性。

并且為了使異步物化視圖更加靈活，在 3.1 版本中：

支持為物化視圖的刷新配置會話變量 (Session Variable)，用戶可以方便地為物化視圖配置單獨的執(zhí)行策略，如查詢超時時間、并行度、內(nèi)存限制、是否開啟算子落盤等。讓物化視圖的刷新不受集群整體變量的限制。

支持基于視圖(View)創(chuàng)建物化視圖，分層建模選擇更加靈活。

支持通過 SWAP 原子替換物化視圖，從而實現(xiàn)物化視圖的 Schema Change 而不影響嵌套的血緣關(guān)系。

支持手動激活失效的物化視圖，從而在基表重建后仍舊復(fù)用歷史物化視圖。

在查詢改寫上，StarRocks 致力于讓更多場景能夠被智能改寫，更多發(fā)揮物化視圖的加速效果。在 3.1 版本中：

新增支持 Join 派生改寫、Count Distinct、time_slice 函數(shù)等場景的改寫，并優(yōu)化了 Union 改寫能力。

新增支持 Stale Rewrite，即在一定時間內(nèi)允許改寫至還未刷新的物化視圖上。從而在允許一定數(shù)據(jù)延遲的實時場景下，通過物化視圖提高查詢并發(fā)。

新增支持 View Delta Join，提升如指標平臺、面向主題的寬表場景下的改寫能力，降低物化視圖的維護成本。

在刷新能力上，在 3.1 版本中：

支持全新同步物化視圖刷新接口，同步獲取刷新結(jié)果。

基于 Hive Catalog 創(chuàng)建的外表異步物化視圖可以感知分區(qū)變動，按分區(qū)增量刷新，加速刷新的同時降低成本。

同步物化視圖

擁有同步更新、增量計算能力，并且性能卓越的同步物化視圖一直廣受 StarRocks 用戶喜愛，美中不足的是，歷史版本中，其支持的算子還不完整，導(dǎo)致應(yīng)用場景也受到了一定限制。

在 3.1 版本中，這一局限已不再存在。新版本不僅支持了所有的聚合函數(shù)，也支持了CASE-WHEN、CAST、數(shù)學運算等表達式。

此外，3.1 版本還支持在單個物化視圖內(nèi)設(shè)置多個聚合列，并且可以使用 HINT 來對同步物化視圖進行直接查詢。

可以說，這一版本的StarRocks，已經(jīng)大幅拓寬了同步物化視圖能力邊界。

SQL

CREATE MATERIALIZED VIEW v1 AS

SELECT b, sum(a + 1) as sum_a1, min(cast (a as bigint)) as min_a

FROM base_table

GROUP BY b;

加速手段更多了，查詢性能繼續(xù)奔跑

眾所周知，StarRocks 對查詢性能的追求近乎狂熱，3.1版本中，這一點又得到了充分體現(xiàn)。

3.1 版本新增了生成列(Generated Column)功能，StarRocks 會根據(jù)生成列表達式自動計算表達式的值并在導(dǎo)入時即存儲，在查詢時會自動判斷并進行改寫，在無需增加查詢復(fù)雜性的情況下，再一步提升查詢性能。

這一設(shè)計尤其適用對 JSON、Array、Map、Struct 等半結(jié)構(gòu)數(shù)據(jù)的查詢加速和對復(fù)雜表達式的計算加速。

并且，如果生成列的類型是簡單類型，還能利用上 zonemap 等索引，會更進一步加速查詢性能。

如下所示，newcol1、newcol2 是兩個分別是對 data_array、data_json 列做了一些函數(shù)操作的生成列。

SQL

CREATE TABLE t (

id INT NOT NULL,

data_array ARRAY < int > NOT NULL,

data_json JSON NOT NULL,

newcol1 DOUBLE ASarray_avg(data_array),

newcol2 STRING ASget_json_string(json_string(data_json), '$.a')

);

插入數(shù)據(jù)時正常插入即可(不用關(guān)心生成列)，newcol1、newcol2 會自動計算并存儲。

SQL

INSERT INTO t VALUES (1, [1,2], parse_json('{"a" : 1, "b" : 2}')),

(2, [3,5], parse_json('{"a" : 8, "b" : 3}'))

查詢時也正常查詢即可，StarRocks 會自動改寫 Query，變成對 newcol1、newcol2 的使用。

SQL

SELECT max(get_json_string(json_string(data_json),”$.a”)) AS a,

min(array_avg(data_array)) AS b

FROM t;

同時，StarRocks 優(yōu)化了主鍵模型的部分列更新功能，執(zhí)行 UPDATE [8]語句時會開啟列模式(column mode)，在更新少部分列但是有大量行的場景下，可提升十倍性能。

在原來的「行模式」下，部分列更新時，StarRocks 會需要重寫整行數(shù)據(jù)。

在新的「列模式」下，只需要重寫更新的列數(shù)據(jù)即可。

還有，StarRocks 支持了基數(shù)保持 JOIN 表(Cardinality-preserving Joins)的裁剪，優(yōu)化了點查查詢性能、統(tǒng)計信息收集、并行 merge 算法、優(yōu)化內(nèi)部鎖使用的邏輯等等，進一步提升各類細分場景下的查詢性能。

其中「基數(shù)保持 JOIN 表的裁剪」功能在較多表的星型模型(比如 SSB)和雪花模型(TPC-H)中會有用武之地，當 JOIN 的表存在主鍵或者外鍵約束，且可以滿足基數(shù)保持 JOIN 表裁剪的條件，一些經(jīng)過裁剪后的 JOIN 的性能能加速 10X 倍以上。

在風控領(lǐng)域進行多種組合的特征選擇時，往往采用直接查詢由較多表 JOIN 后的 View，此時的裁剪就會起到不錯的效果。

??SELECT view 時，view 中不需要用到的 Table-C 被自動裁剪掉了。使用中需要額外設(shè)置一些約束。

Spill To Disk 加強

除了卓越的查詢性能，在大規(guī)模的數(shù)據(jù)集上查詢時的穩(wěn)定性也是很重要的一個方面。對此，3.1 版本中，StarRocks 正式支持了部分阻塞算子的 Spill(中間數(shù)據(jù)落盤)能力，當查詢中包括聚合、排序或者連接算子時，開啟 Spill 功能將允許相關(guān)的算子將計算的中間結(jié)果緩存到磁盤上，從而降低內(nèi)存占用，盡量避免查詢因內(nèi)存不足而失敗。

在物化視圖構(gòu)建、數(shù)據(jù) ETL 處理等內(nèi)存密集型的場景中，開啟 Spill 會極大地提升查詢的穩(wěn)定性。

在 3 個 BE、每個 BE 16core/20G 內(nèi)存的測試環(huán)境中，開啟 Spill 功能后，StarRocks 能完整地跑完 TPCH-10TB 測試集。

分桶鍵可以不用設(shè)了，建表與導(dǎo)入更方便

在不斷優(yōu)化查詢性能的同時，StarRocks 持續(xù)在建表和導(dǎo)入方面提升產(chǎn)品易用性、提供更多實用功能。

在建表時，用戶可以配置隨機分桶(Random Bucketing)[9]方式(默認)，不再需要設(shè)置分桶鍵，StarRocks 會將導(dǎo)入數(shù)據(jù)隨機分發(fā)到各個分桶中，同時配合使用 2.5.7 版本起支持的自動設(shè)置分桶數(shù)量功能(默認)，用戶可以不再需要關(guān)心分桶配置。

SQL

CREATE TABLE site_access(

event_day DATE,

site_id INT DEFAULT '10',

...

) DUPLICATE KEY(event_day, site_id)

PARTITION BY date_trunc('day', event_day)

DISTRIBUTED BY HASH(event_day,site_id) BUCKETS 10; -- 可以不再需要指定

在導(dǎo)入數(shù)據(jù)時，如果數(shù)據(jù)是存儲在 AWS S3/HDFS 上的 Parquet/ORC 格式文件，用戶可以很簡單地直接采用 INSERT+ FILES()表函數(shù)來導(dǎo)入數(shù)據(jù)，F(xiàn)ILES 表函數(shù)會自動進行 table schema 推斷，做到數(shù)據(jù)拿來即可 SELECT，用戶甚至還可以使用 CTAS + FILES 一鍵式導(dǎo)入數(shù)據(jù)，在前期測試數(shù)據(jù)導(dǎo)入階段尤其適用。

SQL

CREATE TABLE insert_wiki_edit AS

SELECT * FROM FILES(

'path' = 's3://inserttest/parquet/insert_wiki_edit_append.parquet',

'format' = 'parquet');

同時，關(guān)于建表時的分區(qū)設(shè)置，一般直接設(shè)置日期時間字段作為分區(qū)列即可，如果用戶想要根據(jù)自己的數(shù)據(jù)更靈活地配置，也可以使用 StarRocks 新支持的表達式分區(qū)和LIST 分區(qū)方式，其中配置表達式分區(qū)后，StarRocks 會根據(jù)數(shù)據(jù)和分區(qū)表達式的定義規(guī)則自動創(chuàng)建分區(qū)。

并且，繼 3.0 版本中湖分析支持查詢 Map、Struct 類型數(shù)據(jù)后，3.1 版本中導(dǎo)入數(shù)據(jù)時也支持導(dǎo)入 Parquet/ORC 格式數(shù)據(jù)中的 Map、Struct 字段類型，為導(dǎo)入提供了更多選項。

StarRocks 在簡化建表、簡化導(dǎo)入方面將持續(xù)地進行端到端的優(yōu)化，不斷提升產(chǎn)品易用性和功能的完善性。

Struct 數(shù)據(jù)也能用了，半結(jié)構(gòu)化分析能力非常強

3.1 版本中，StarRocks 正式原生支持了 Map 和 Struct 數(shù)據(jù)類型。除了基于湖上的半結(jié)構(gòu)化數(shù)據(jù)分析，也支持建表、導(dǎo)入、創(chuàng)建物化視圖。同時也補充了 Map 和 Struct 的更多函數(shù)，包括標量、聚合以及更多的 Map 高階函數(shù)。

Array 數(shù)據(jù)類型支持了 Fast Decimal，并且 Array 函數(shù)支持了嵌套結(jié)構(gòu)類型 Map、Struct 和 Array。讓用戶的查詢分析體驗更加靈活。

并且結(jié)合生成列的能力，可以進一步加速對復(fù)雜數(shù)據(jù)類型的計算與查詢。例如對 JSON 內(nèi)的對象的查詢、大 ARRAY 的聚合計算等場景，均可以通過生成列在導(dǎo)入時預(yù)先完成計算，并在后續(xù)查詢中通過自動改寫完成查詢加速。

可以認為，不論是從導(dǎo)入到查詢的功能上、還是用生成列來優(yōu)化性能上，StarRocks 基本完整地支持了 Array、JSON、Map、Struct 這類半結(jié)構(gòu)化數(shù)據(jù)的能力。

最后，如你希望更加了解 StarRocks 3.1 版本，歡迎觀看視頻解說。

StarRocks Feature Groups：

StarRocks 社區(qū)為了讓用戶在使用新 features 時能更加得心應(yīng)手，設(shè)立了包含”物化視圖“、”湖倉分析“和”存算分離“等的用戶群，歡迎小伙伴們?nèi)肴簩μ囟?feature 進行深入交流！

在這個版本中，117 位貢獻者 一共提交了 2785 個 Commits，感謝他們：

stdpain, Astralidea, mofeiatwork, yandongxiao, kevincai, Seaven, hellolilyliuyi, EsoragotoSpirit, Youngwb, andyziye, packy92, sduzh, meegoo, zaorangyang, caneGuy, silverbullet233, chaoyli, LiShuMing, trueeyu, srlch, liuyehcf, ABingHuang, luohaha, amber-create, miomiocat, sevev, letian-jiang, stephen-shelby, zombee0, nshangyiming, satanson, fzhedu, Smith-Cruise, gengjun-git, decster, TszKitLo40, starrocks-xupeng, evelynzhaojie, ZiheLiu, zhenxiao, wyb, rickif, HangyuanLiu, liuzhongjun89, dirtysalt, abc982627271, wanpengfei-git, SilvaXiang, hongli-my, kangkaisen, liuyufei9527, ggKe, xuzifu666, ucasfl, GavinMar, jkim650, JackeyLee007, tracymacding, huzhichengdd, Moonm3n, silly-carbon, imay, szza, you06, leoyy0316, Johnsonginati, smartlxh, xiangguangyxg, vendanner, QingdongZeng3, zhangruchubaba, wxl24life, banmoy, matchyc, predator4ann, huangfeng1993, dengliu, choury, bowenliang123, sebpop, RamaMalladiAWS, dustinlineweber, jiacheng-celonis, chen9t, blanklin030, wangsimo0, howrocks, qmengss, alberttwong, before-Sunrise, chenjian2664, wangruin, kobebryantlin0, wangxiaobaidu11, creatstar, kateshaowanjou, huandzh, mlimwxxnn, goldenbean, Jay-ju, ss892714028, mchades, cbcbq, shileifu, xiaoyong-z, sfwang218, uncleGen, r-sniper, blackstar-baba, ldsink, gddezero, fieldsfarmer, even986025158, idomic, yangrong688, padmejin, zuyu

（免責聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準確性及可靠性，但不保證有關(guān)資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責。本網(wǎng)站對有關(guān)資料所引致的錯誤、不確或遺漏，概不負任何法律責任。
任何單位或個人認為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權(quán)或存在不實內(nèi)容時，應(yīng)及時向本網(wǎng)站提出書面權(quán)利通知或不實情況說明，并提供身份證明、權(quán)屬證明及詳細侵權(quán)或不實情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關(guān)文章源頭核實，溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。 ）