一、StarRocks數(shù)據(jù)湖分析

1、StarRocks 3.0 Overview

StarRock3.0之前定位于實(shí)時(shí)數(shù)倉，主要有以下幾方面的能力：

• 實(shí)時(shí)寫入：從Kafka、Flink等系統(tǒng)實(shí)時(shí)插入、更新、刪除數(shù)據(jù)的能力。
• 批量導(dǎo)入：從 S3、Hadoop、Spark 等各種系統(tǒng)批量導(dǎo)入數(shù)據(jù)的能力。
• 實(shí)時(shí)引擎：具備實(shí)時(shí)存儲引擎和實(shí)時(shí)查詢引擎，在dashboard、BI、Ad-hoc query等各種場景中，都有比較好的性能和統(tǒng)一性。

StarRocks3.0推出了新的數(shù)據(jù)湖分析功能，支持Hive、Iceberg、Hudi，和MySQL等傳統(tǒng)DB外表，加上StarRocks本身的外表，使得StarRocks 能夠作為一個(gè)統(tǒng)一的查詢引擎，去查詢各種數(shù)據(jù)源。基于這些能力，我們希望把 StarRocks 打造成一個(gè)實(shí)時(shí)的Lakehouse產(chǎn)品，更好地整合數(shù)據(jù)湖和數(shù)據(jù)倉庫這兩種產(chǎn)品概念。

2、StarRocks LakeHouse

LakeHouse可以分為傳統(tǒng)數(shù)倉和數(shù)據(jù)湖兩大塊：

• 傳統(tǒng)數(shù)倉：用戶一般會進(jìn)行數(shù)據(jù)清洗、寬表加工以及聚合，它的數(shù)據(jù)質(zhì)量通常比較好，不用太擔(dān)心數(shù)據(jù)格式問題，因此查詢性能比較好。StarRocks對執(zhí)行引擎、數(shù)據(jù)存儲格式、自帶的向量化引擎、實(shí)時(shí)更新引擎、存儲引擎以及各種執(zhí)行算子等做了很多優(yōu)化，實(shí)時(shí)更新的性能通?？梢赃_(dá)到秒級。
• 數(shù)據(jù)湖：它的優(yōu)勢是Table format、File format和生態(tài)等方面比較open，能夠很容易地接入各種查詢引擎、存儲引擎，所以它能夠成為很多企業(yè)的統(tǒng)一存儲；另外它比較適合于作為source of truth的存儲，比如整個(gè)企業(yè)里的數(shù)據(jù)統(tǒng)一放在數(shù)據(jù)湖里面，然后在上層基于這個(gè)數(shù)據(jù)底座去做更多的數(shù)據(jù)加工跟處理。數(shù)據(jù)湖的擴(kuò)展性較好、性價(jià)比比較高，它可以是基于S3等大數(shù)據(jù)生態(tài)技術(shù)演進(jìn)過來的，可以基于HDFS、S3等存儲介質(zhì)。

湖倉目前看來還是有較大gap的、割裂的兩個(gè)場景，StarRocks做了很多技術(shù)和Feature，去整合這兩種場景，從早期的Warehouse，到3.0做了較大的架構(gòu)升級，具備了很好的彈性能力。支持存算分離，可以由原生存儲變成S3。支持多種部署方式，可以選擇線下部署，也可以選擇K8s等部署方式。支持?jǐn)?shù)據(jù)庫查詢能力，可以作為一個(gè)查詢引擎去查詢數(shù)據(jù)湖。最終希望打造云原生彈性擴(kuò)展能力，更好地整合成LakeHouse的產(chǎn)品形態(tài)。

3、StarRocks LakeHouse - Catalog

StarRocks3.0之前需要手動創(chuàng)建外表DDR來查詢外部數(shù)據(jù)源，在表很多的時(shí)候操作非常繁瑣。3.0的Catalog功能可以直接查詢Hive、Iceberg、Hudi、Deltalake、ES、Mysql、Oracle、Postgres和文件等各種數(shù)據(jù)源，覆蓋了大部分的數(shù)據(jù)使用場景。

只需要執(zhí)行create external Catalog命令，就可以連到Hive Metastore自動獲取元數(shù)據(jù)，然后就可以直接查詢其中的數(shù)據(jù)。除此之外另一種場景是在S3上放了一堆文件，但沒有將其組織成Iceberg的format，也可以創(chuàng)建Catalog直接去查詢。

在 External Catalog 的基礎(chǔ)上，結(jié)合 StarRocks 的內(nèi)表存儲，兩種數(shù)據(jù)源可以 Join 起來同時(shí)查詢。由于內(nèi)表有自己的存儲引擎，具有較好的實(shí)時(shí)性，可以服務(wù)實(shí)時(shí)workload；同時(shí)External Table可以用于存儲歷史數(shù)據(jù)，這樣就可以聯(lián)合使用多種不同的存儲引擎，來覆蓋更多的使用場景。

4、StarRocks LakeHouse - Trino 兼容

Trino、Presto有自己的SQL方言和許多自定義函數(shù)，而StarRocks目前主要兼容的是MySQL語法和協(xié)議。如果用戶已經(jīng)過了POC階段，正在生產(chǎn)系統(tǒng)使用Trino、Presto等查詢引擎，想要遷移到StarRocks就會有很多的工作，雖然不用遷移數(shù)據(jù)，但是需要改造很多業(yè)務(wù)SQL。

為此StarRocks做了兼容Trino的feature，在SQL parser中支持MySQL和Trino 兩種方言，使用統(tǒng)一的執(zhí)行計(jì)劃，目前已經(jīng)覆蓋了99%的語法。用戶只需要將方言切換為StarRocks，就可以實(shí)現(xiàn)無縫遷移，獲得數(shù)倍的性能提升。

5、StarRocks LakeHouse - 極速查詢性能

數(shù)據(jù)湖由File format和Table format兩部分組成，F(xiàn)ile format通常會用比較高效的ORC、parquet，Table format通常會用Iceberg、Hudi。

數(shù)據(jù)湖跟內(nèi)表存儲引擎理念比較接近，沒有太多本質(zhì)差別，但是在具體的細(xì)節(jié)上還是有些差別的，比如說文件格式、文件壓縮效果、IO效果以及整體性能等。HDFS和S3等不同的存儲系統(tǒng)雖然可以提供統(tǒng)一的接口，但它們是有性能差異的，HDFS通常在Latency上會比S3的性能稍微好一些，有些場景下S3會有更好一些。ORC的IO counter可能比parquet要多非常多，也就是parquet可以IO size更大一些。

考慮到這些情況，StarRocks內(nèi)部做了非常多的IO優(yōu)化，去克服不同系統(tǒng)之間的性能差異。

上圖是用eBPF之類的工具觀察到的結(jié)果，可以看出在數(shù)據(jù)湖場景下更加IO密集，傳統(tǒng)數(shù)倉場景下往往是計(jì)算密集。有些用戶的寫數(shù)系統(tǒng)比較復(fù)雜多樣，數(shù)據(jù)格式質(zhì)量不那么好，產(chǎn)生了很多parquet小文件。有些用戶ORC的stripe size設(shè)置得非常小，如果按傳統(tǒng)策略每個(gè)row group里面讀每個(gè)column，它的IO會非常小可能就幾KB，效率非常低，我們也不能把IO粒度擴(kuò)大到文件級別，因?yàn)榭赡苣骋粋€(gè)文件非常大。

StarRocks針對不同IO密集場景做了優(yōu)化。

如果column size非常小就合并IO，一次讀取多個(gè)column。

如果文件非常小，就一次讀取整個(gè)文件，即便文件中有一些數(shù)據(jù)可能并不需要，但在做了這樣一個(gè)合并之后，總IO次數(shù)會少非常多。

如果使用了S3存儲，不管你怎么優(yōu)化，當(dāng)訪問它的冷數(shù)據(jù)的時(shí)候，它的IO消耗一定會非常高，最好的優(yōu)化方式是把數(shù)據(jù)cache在本地。相較于Presto、Trino會用一些三方組件去做數(shù)據(jù)cache， StarRocks 希望把系統(tǒng)架構(gòu)做得更簡單一些，所以自己實(shí)現(xiàn)了一套協(xié)同memory和disk的cache系統(tǒng)，數(shù)據(jù)會先cache在memory中，當(dāng)memory 不夠時(shí)數(shù)據(jù)會溢出到disk上。通常來說大部分workload都會有一個(gè)相對比較小的working set，比如有幾百GB的數(shù)據(jù)要分析，當(dāng)多次查詢后，大部分?jǐn)?shù)據(jù)都能夠命中cache，從而得到比較好的查詢性能。

除此之外 StarRocks 也做過一些算法層面的IO優(yōu)化，比如延遲物化技術(shù)，會根據(jù)查詢條件中的where條件先把某一列查出來，再造一個(gè)過濾去讀其它列。還有Top N算子，也可以做延遲物化，后面我們可能也會在join也支持延遲物化技術(shù)。

綜合使用各種IO優(yōu)化技術(shù)，可以很大程度上減少文件IO。在同樣的數(shù)據(jù)集、同樣的資源規(guī)模下，StarRocks查詢Iceberg比Trino快3-5倍。在大部分用戶案例中，從Trino切換到StarRocks都會有一個(gè)非常明顯的性能提升，像TPC-H其實(shí)是一個(gè)相對沒有那么復(fù)雜的數(shù)據(jù)集，如果用戶的實(shí)際業(yè)務(wù)中有一些特別復(fù)雜的SQL，它會有更加明顯的性能提升。

6、StarRocks LakeHouse - 統(tǒng)一開放

StarRocks在架構(gòu)層面和功能技術(shù)層面做了很多整合，比如物化視圖、Catalog、IO優(yōu)化以及Trino兼容等，希望這些技術(shù)能夠整合起來，打造成統(tǒng)一開放的Lakehouse架構(gòu)。

StarRocks可以作為查詢引擎去查詢數(shù)據(jù)湖中的數(shù)據(jù)，替換Spark、Flink等相對比較老的組件。StarRocks 也有自己的存儲引擎，它可以提供 Colocate能力，以及用戶指定的分區(qū)、排序、分桶能力，和實(shí)時(shí)場景下需要的實(shí)時(shí)更新以及索引的能力。

綜合使用這些技術(shù)，使得用戶可以讓一部分workload放在數(shù)據(jù)湖里，繼續(xù)使用Spark、Flink做加工處理，另一部分更偏實(shí)時(shí)的workload放在內(nèi)表里，然后用 StarRocks 作為統(tǒng)一的查詢?nèi)肟?，也可以讓?shí)時(shí)workload通過StarRocks寫入。結(jié)合起來，比較好地實(shí)現(xiàn)了實(shí)時(shí) LakeHouse這樣的架構(gòu)。

二、StarRocks 物化視圖

1、StarRocks Materialized View

物化視圖的語法有幾個(gè)部分：

partition by：對物化視圖分區(qū)，和StarRocks內(nèi)表一樣，可以按照時(shí)間等維度進(jìn)行分區(qū)。分區(qū)后可以對查詢裁剪，避免訪問不需要的數(shù)據(jù)，比如按天分區(qū)后就只需要刷當(dāng)天的數(shù)據(jù)，歷史數(shù)據(jù)不需要去touch。還可以進(jìn)行分區(qū)級的數(shù)據(jù)自動刷新、數(shù)據(jù)變更的自動訂閱，實(shí)現(xiàn)比較好實(shí)時(shí)性。

Refresh：支持全量刷新、增量刷新、定時(shí)刷新、手動刷新等多種方式。滿足不同業(yè)務(wù)場景的需求。

resource group：把物化視圖跟其它workload更好地整合在同一個(gè)系統(tǒng)、同一個(gè)集群里。因?yàn)橛脩舻牟樵兪且环N偏前端的workload，而物化視圖的維護(hù)是偏后端、資源非常密集的workload，所以如何把這兩種整合到一起，穩(wěn)定地跑到同一個(gè)集群里面，是一個(gè)很大的技術(shù)難點(diǎn)。所以我們這里選擇用 resource group 技術(shù)來實(shí)現(xiàn)資源隔離。

查詢語句：支持aggregation、join等查詢語句。

對不同的查詢語句類型可以使用不同的刷新方式，如果是簡單的聚合查詢可以增量刷新，如果有join或者更復(fù)雜的語句就要全量刷新。未來StarRocks會逐步擴(kuò)展物化視圖的增量刷新能力，支持更多的復(fù)雜使用場景，比如增量的 join 窗口，類似Flink 的增量計(jì)算等等。

生產(chǎn)環(huán)境中有很多適合用物化視圖的場景，例如：

增量聚合：很多業(yè)務(wù)報(bào)表會對immutable的event、log數(shù)據(jù)做sum、distinct、bitmap、Hyperlog等聚合，這類數(shù)據(jù)一般數(shù)據(jù)量非常大、寫入TPS高，所以不適合全量刷新。之前常用Flink來做增量計(jì)算，像sum、bitmap去重以及Hyperlog等，現(xiàn)在也可以用StarRocks的增量物化視圖來支持。

數(shù)倉建模：物化視圖的語法非常適合替代傳統(tǒng)ETL用來建模。業(yè)務(wù)有時(shí)可能不太關(guān)心增量刷新還是全量刷新，也不太關(guān)心數(shù)據(jù)之間的依賴關(guān)系如何表達(dá)、如何調(diào)度，就可以使用DBT這種工具直接用物化視圖去建模，它還可以屏蔽底層的刷新方式。

透明加速：用戶可以透明地創(chuàng)建出一個(gè)物化視圖，然后利用優(yōu)化器的查詢改寫能力，改為查詢物化視圖來實(shí)現(xiàn)很好的加速效果。

數(shù)據(jù)湖加速：數(shù)據(jù)湖查詢往往是IO密集型的，一般可以使用cache來優(yōu)化，但如果數(shù)據(jù)量非常大就無法cache在本地。這時(shí)可以借助物化視圖來預(yù)計(jì)算，計(jì)算結(jié)果的數(shù)據(jù)量通常會小幾個(gè)數(shù)量級，再把計(jì)算結(jié)果cache到本地，就可以很好地加速數(shù)據(jù)湖的查詢。

2、MV - 數(shù)倉建模

傳統(tǒng)數(shù)倉建?？梢苑諳DS、DWD、DWS、ADS幾層，每層可能都會用到Hive、Sqoop以及Flink等ETL工具，現(xiàn)在也可以用StarRocks物化視圖技術(shù)來構(gòu)建。從ODS到DWD往往是聚合和清洗，這一層可以用物化視圖的SQL謂詞和增量聚合技術(shù)來構(gòu)建。再往上可能會做寬表join以及面向具體業(yè)務(wù)的報(bào)表，往往需要比較復(fù)雜的join，或者窗口函數(shù)的計(jì)算，也可以用物化視圖來表達(dá)。

它帶來價(jià)值是能夠簡化架構(gòu)的復(fù)雜度，不需要在外部維護(hù)很多的數(shù)據(jù)組件去做加工，如果維護(hù)了這些數(shù)據(jù)組件，不僅要使用物理資源去部署運(yùn)行，還需要部署一些調(diào)度、監(jiān)控的組件去支持，這樣的架構(gòu)是比較復(fù)雜的。如果遷移到物化視圖上面來，就只需執(zhí)行幾條SQL，不需要額外維護(hù)組件，物化視圖還維護(hù)了調(diào)度關(guān)系。

另外還能充分利用StarRocks執(zhí)行引擎的性能優(yōu)勢，如果使用Hive等外部系統(tǒng)，數(shù)據(jù)可能先要過一遍Hive，中間的計(jì)算開銷以及IO開銷就會非常的消耗資源，然后再往下游系統(tǒng)寫數(shù)據(jù)，它的IO又會多了幾倍，一旦有很多的IO開銷以及組件，整體性能就很難優(yōu)化，非常消耗資源，ETL任務(wù)的實(shí)時(shí)性也很難保障。

遷移到StarRocks就可以很好地解決這些問題，主要用到下面幾個(gè)關(guān)鍵技術(shù)：

• 支持多數(shù)據(jù)源：可以基于內(nèi)表、數(shù)據(jù)湖外表和JDBC外表等創(chuàng)建物化視圖，比如可以對MySQL、Postgres創(chuàng)建物化視圖，把數(shù)據(jù)同步到內(nèi)部來，這樣就可以不用直接查外部數(shù)據(jù)了。
• 維護(hù)分區(qū)關(guān)系：對內(nèi)表和外表的分區(qū)關(guān)系進(jìn)行維護(hù)，使得全量刷新可以依靠分區(qū)去做更細(xì)粒度的數(shù)據(jù)刷新和物化視圖維護(hù)。
• 任務(wù)調(diào)度：物化視圖join表的時(shí)候可以顯示聲明依賴關(guān)系，被join的表更新完成后才刷新視圖。如果有多張表作為事實(shí)表，還可以使用接口手動控制調(diào)度、定制業(yè)務(wù)集。
• 資源隔離：在使用物化視圖替代傳統(tǒng)數(shù)倉建模的時(shí)候，只需要添加一個(gè)新的resource-group，不需要部署新的集群，讓多個(gè)workload跑在同一個(gè)系統(tǒng)集群中。

上圖中T1是事實(shí)表，T2是維度表，列舉了一些分區(qū)刷新的經(jīng)典場景：

事實(shí)表細(xì)粒度刷新：維度表的變化頻率是相對比較低的，如果事實(shí)表做了比較細(xì)粒度的分區(qū)，比如天級、小時(shí)級或分鐘級的分區(qū)，在事實(shí)表刷新之后，基于分區(qū)就可以發(fā)現(xiàn)物化視圖對應(yīng)的某一個(gè)分區(qū)也需要更新，那就只需要刷新一個(gè)分區(qū)，代價(jià)是相對比較低的。

維度表精準(zhǔn)刷新：最經(jīng)典的場景是刷新整個(gè)物化視圖，代價(jià)相對較大。有些業(yè)務(wù)像酒店餐飲是可以不回刷數(shù)據(jù)的，那么可以精細(xì)化的排除某些維度，不觸發(fā)回刷。也有一些業(yè)務(wù)，希望回刷比如一個(gè)月的數(shù)據(jù)，那么可以精準(zhǔn)的控制回刷幾個(gè)分區(qū)。

自動刷新：StarRocks支持訂閱外表分區(qū)的數(shù)據(jù)變更，當(dāng)發(fā)現(xiàn)Hive等外表分區(qū)變更后，可以自動刷新物化視圖對應(yīng)的分區(qū)。

3、MV - 彈性資源隔離

StarRocks實(shí)現(xiàn)了統(tǒng)一的架構(gòu)，能夠同時(shí)運(yùn)行Ad-hoc query、Dashboard、Realtime、Batch等多個(gè)workload。Realtime物化視圖時(shí)效性要求通常比較高，比如實(shí)時(shí)看板一般是分鐘級，所以資源消耗比較大。Batch物化視圖允許慢一點(diǎn)一般是天級，通常是在半夜定時(shí)去跑，所以不需要占用非常多的資源。那么如何資源隔離，使不同的workload不會互相影響，就成為了一個(gè)難題。目前StarRocks用了資源組軟性隔離和Warehouse硬性隔離兩個(gè)技術(shù)來實(shí)現(xiàn)資源隔離。

資源組軟性隔離：用戶可以使用默認(rèn)資源組，或者根據(jù)業(yè)務(wù)需要?jiǎng)?chuàng)建資源組，非常細(xì)膩的控制每個(gè)視圖的CPU、Memory、Disk等資源的最大配額占比。當(dāng)只有1個(gè)workload 時(shí)允許跑到100%，當(dāng)有多個(gè)workload時(shí)，就根據(jù)配額的比例分配資源，因?yàn)槭擒浶裕约悠饋砜梢猿^100%。

Warehouse硬性隔離：在云原生架構(gòu)實(shí)現(xiàn)了無狀態(tài)計(jì)算節(jié)點(diǎn)的架構(gòu)。物化視圖可以放在獨(dú)立的節(jié)點(diǎn)運(yùn)行，將資源徹底隔離開來。Warehouse 本身是彈性的，可以隨時(shí)創(chuàng)建、釋放。

4、MV - 透明查詢加速

在BI 報(bào)表場景的SQL很多是系統(tǒng)自動生成的，而且通常很復(fù)雜，用戶很難通過修改SQL的方式來進(jìn)行調(diào)優(yōu)，所以需要一種類似于傳統(tǒng)數(shù)據(jù)庫索引的透明加速能力。

物化視圖針對SPJG（select、project、join、group by）場景，支持查詢改寫加速。比如有兩表的join再聚合的query，我們可以創(chuàng)建一個(gè)邏輯一樣的物化視圖，在query時(shí)直接scan這個(gè)物化視圖，這是exactly match的。如果還有聚合計(jì)算，或者聚合key、表達(dá)式有區(qū)別，那么可以在這個(gè)物化視圖的基礎(chǔ)上做二次的聚合、join計(jì)算。

案例1：聚合上卷改寫

上圖右邊是物化視圖，有時(shí)間和city兩個(gè)維度?？梢圆捎妙愃颇承┫到y(tǒng)的Cube來加速查詢，在創(chuàng)建Cube的時(shí)候就把所有維度都預(yù)計(jì)算出來，后面的查詢幾乎不需要做任何計(jì)算。但是如果維度很多，會導(dǎo)致維度組合數(shù)量爆炸。物化視圖可以把常見的維度預(yù)聚合，比如把時(shí)間和城市預(yù)聚合，比如一天有幾億數(shù)據(jù)，按天聚合后數(shù)據(jù)量會少幾個(gè)量級，帶來的效果非常顯著。

上圖左邊是三個(gè)實(shí)際的查詢，查詢語句不需要跟物化視圖一樣，否則就比較雞肋了。大部分查詢的維度組合是比較靈活的，維度也不一定和物化視圖一致，所以需要上卷以及更多的探索。示例1的查詢按照時(shí)間維度聚合count，count是可以上卷的，只需要把物化視圖按照city聚合count一次，所以優(yōu)化器會自動改寫為基于物化視圖的上卷。示例2按照city聚合也是一樣可以上卷。上卷之后可以獲得更多的維度組合，有比較好查詢加速效果，同時(shí)也會兼顧靈活性，還有一些特殊的case是做count distinct，需要結(jié)合Bitmap技術(shù)，在底層創(chuàng)建物化視圖的時(shí)候同時(shí)創(chuàng)建bitmap，然后在上面就可以做更多的維度的組合了。

案例2：寬表join改寫

join是非常常見的數(shù)據(jù)加工方式，寬表join的物化視圖可能把事實(shí)表和多個(gè)維度表join起來。查詢的時(shí)候比較靈活，可能join結(jié)果并不需要所有維度，只需要join其中一部分。因?yàn)閖oin類型有很多，inner join跟outer join不一樣，一對一join跟一對n join也不一樣，會有一些參數(shù)和其他的語法去適配不同的場景，可能把inner join改成其他join方式，也可能完全改寫到物化視圖上去，剔除掉其中不需要訪問的那些數(shù)據(jù)。

5、MV案例 - 實(shí)時(shí)精準(zhǔn)去重

國內(nèi)某共享出行公司有幾十個(gè)實(shí)時(shí)看板，需要做精確的count distinct，運(yùn)營人員要求數(shù)據(jù)新鮮度達(dá)到分鐘級、并發(fā)達(dá)到100。之前維護(hù)了很多Flink job做增量計(jì)算，結(jié)果發(fā)現(xiàn)直接去現(xiàn)算幾乎是不可能的，每次計(jì)算可能需要幾秒鐘，因?yàn)樗膁istinct有千萬級。之前的系統(tǒng)使用了HypoLogLog技術(shù)模糊去重后再count distinct，數(shù)據(jù)新鮮度比較好，但結(jié)果是不精確的。

使用StarRocks替換Flink系統(tǒng)后，資源成本和維護(hù)成本都減少了很多。優(yōu)化方案是使用StarRocks做兩層物化視圖：

第一層在明細(xì)數(shù)據(jù)上按照城市、時(shí)間做增量聚合，可以用bitmap技術(shù)和物化視圖增量更新技術(shù)，先聚合成城市粒度、分鐘級的數(shù)據(jù)。

第二層用物化視圖做面向ODS的分鐘級刷新視圖，因?yàn)橛袔资畟€(gè)看板，所以視圖非常多，分鐘級刷新是能夠比較好地權(quán)衡數(shù)據(jù)新鮮度和資源使用。

這些看板的SQL不方便修改，所以還用了物化視圖的透明加速能力，自動改寫替換掉它這個(gè)報(bào)表中的一些SQL。因?yàn)榈谝粚右呀?jīng)做了增量聚合，所以第二層計(jì)算量比較小，不需要做非常重的聚合計(jì)算，只需要把物化視圖的結(jié)果做一些簡單的過濾就可以返回了。

StarRocks權(quán)衡了數(shù)據(jù)新鮮度和性能，現(xiàn)在100并發(fā)時(shí)latency 大概由3秒縮減到了30毫秒，并且實(shí)現(xiàn)了精確的1分鐘新鮮度的count distinct。

三、MV for LakeHouse

物化視圖相關(guān)的技術(shù)，包括構(gòu)建外表物化視圖、分區(qū)關(guān)系維護(hù)、自動刷新、改寫SQL等等，都可以和數(shù)據(jù)湖整合起來，使得在外表的場景能夠用物化視圖加速。其中外表的查詢改寫和內(nèi)表還是有一些差異的，比如Hive可能聲明一些外鍵約束、唯一鍵約束，在查詢改寫過程中是需要這些信息的，我們可以用其它一些方式把這些信息透傳過來，然后就能在優(yōu)化期器中用于查詢改寫。這幾個(gè)技術(shù)結(jié)合起來實(shí)現(xiàn)了比較好的查詢加速效果。

數(shù)據(jù)湖的架構(gòu)往往是比較復(fù)雜的，接下來看幾個(gè)案例。

案例1: 分層建模

分層建模分為以下四層：

ODS層可以是數(shù)據(jù)湖外表，存儲歷史數(shù)據(jù)。

DWD層使用外表物化視圖把數(shù)據(jù)清洗后放到StarRocks內(nèi)部存儲，以及用PK表可以實(shí)時(shí)地把TP等數(shù)據(jù)同步進(jìn)來，可以用來存儲實(shí)時(shí)數(shù)據(jù)。

DWS層用了物化視圖和邏輯視圖兩種技術(shù)，物化視圖把結(jié)果給物化下來用于加速查詢，邏輯視圖仍然可以訪問實(shí)時(shí)數(shù)據(jù)用于簡化業(yè)務(wù)邏輯，把這兩種技術(shù)結(jié)合起來就可以面向不同的業(yè)務(wù)場景、實(shí)現(xiàn)不同的效果。

ADS層用邏輯視圖把很多的業(yè)務(wù)數(shù)據(jù)給union起來，以及做一些更面向業(yè)務(wù)的表達(dá)。

這樣分層后相對更加靈活，實(shí)現(xiàn)了近實(shí)時(shí)的實(shí)時(shí)性。存儲也比較開放，歷史數(shù)據(jù)仍然可以存在數(shù)據(jù)湖中。中間的數(shù)據(jù)刷新部分也不用維護(hù)，而且仍然可以用其他的查詢引擎。

案例2:實(shí)時(shí)數(shù)據(jù)湖

嚴(yán)格來說，實(shí)時(shí)數(shù)據(jù)湖并不是一個(gè)產(chǎn)品或者一個(gè)Feature，而是一種解決方案。目前 StarRocks 會結(jié)合 Iceberg 以及一些其他Feature，去實(shí)現(xiàn)LakeHouse 場景的實(shí)時(shí)聚合、實(shí)時(shí)更新，實(shí)現(xiàn)整體的解決方案。

實(shí)時(shí)聚合：主要面向immutable的數(shù)據(jù)，這類數(shù)據(jù)可以直接去寫Lake，使用Iceberg這種數(shù)據(jù)湖的寫入吞吐量會比較高。

實(shí)時(shí)更新：主要面向mutable的數(shù)據(jù)，數(shù)據(jù)湖目前還沒有較好的實(shí)時(shí)更新能力，StarRocks primary key則可以很好的支持，所以首先會把數(shù)據(jù)寫到pk表，定時(shí)下沉到Lake中，同時(shí)在此之上，可以用物化視圖做實(shí)時(shí)的增量聚合。

結(jié)合實(shí)時(shí)聚合和實(shí)時(shí)更新兩種場景，把全量數(shù)據(jù)存在Iceberg中，把聚合、更新數(shù)據(jù)放在StarRocks中，然后在上層構(gòu)建物化視圖去做面向業(yè)務(wù)的加工寬表、聚合結(jié)果，可以帶來以下幾方面的業(yè)務(wù)價(jià)值：

• 一是SSOT，不管是面向歸檔，還是面向其它查詢引擎，都能直接查詢數(shù)據(jù)湖，不會被封閉在一個(gè)系統(tǒng)里。
• 二是變成實(shí)時(shí)后，可以分?jǐn)傎Y源，不會在凌晨出現(xiàn)一個(gè)業(yè)務(wù)高峰，而白天又很空閑，導(dǎo)致資源浪費(fèi)。
• 三是可以發(fā)揮不同存儲引擎的優(yōu)勢，StarRocks支持實(shí)時(shí)聚合、實(shí)時(shí)更新，數(shù)據(jù)湖可以存儲歷史數(shù)據(jù)，具有超高的寫入吞吐量的優(yōu)勢。

四、總結(jié)展望

StarRocks 后續(xù)有幾個(gè)發(fā)展方向：

第一個(gè)是利用云原生架構(gòu)更好地管理資源，在接入數(shù)據(jù)湖并構(gòu)建很多ETL workload之后，如何把各種資源統(tǒng)一管控起來，將會是一個(gè)很大的挑戰(zhàn)。

第二個(gè)是支持更多的ETL的場景，物化視圖目前還不能解決全部ETL場景，無法徹底替換Flink，所以未來會開發(fā)更多的ETL的feature，更好地把ETL場景統(tǒng)一起來。

第三個(gè)是進(jìn)一步加強(qiáng)實(shí)時(shí)鏈路，會針對數(shù)據(jù)攝取和數(shù)據(jù)實(shí)時(shí)計(jì)算等場景開發(fā)更多的feature，讓導(dǎo)入各種實(shí)時(shí)系統(tǒng)的數(shù)據(jù)變得更加容易，會支持更多的增量計(jì)算場景，而不僅僅是實(shí)時(shí)聚合。

五、問答

問：物化視圖底層存儲也是用三副本嗎？

答：對。物化視圖也是按照表來存儲的，不同于普通表的是會自動維護(hù)。Base表跟物化視圖表的存儲都取決存儲引擎，可以設(shè)置3副本，可以設(shè)置2副本，也可設(shè)置1副本，也可以用云原生架構(gòu)做存算分離，是非常靈活的，關(guān)鍵在于如何維護(hù)這個(gè)base表跟計(jì)算結(jié)果的映射關(guān)系。