作者：StarRocks Committer 李雪巖，國雙科技技術(shù)架構(gòu)師、StarRocks Active Contributor 龔磊（本文為作者在 StarRocks Summit Asia 2022 上的分享）

本文先介紹物化視圖的一些需求分析，看看現(xiàn)在的物化視圖哪些地方做得好、哪些地方做得不好，然后再針對這些需求進行設(shè)計。然后再講一下具體的實現(xiàn)原理，最后再講一下 StarRocks 2.5 版本的物化視圖還會開發(fā)哪些功能。

01、物化視圖的需求分析

1什么是物化視圖

要了解物化視圖可以先了解視圖的概念。視圖是一個虛擬表（也可以認為是一條語句），基于它創(chuàng)建時指定的查詢語句返回的結(jié)果集。而物化視圖則是將這個虛擬表進行實體化，其本身可以理解為是一個特殊的表。

2物化視圖的應(yīng)用場景

物化視圖最常見的場景是，由基礎(chǔ)的 Base 表通過創(chuàng)建物化視圖的 SQL 生成物化視圖，當(dāng)用戶查詢相似的 SQL 時，查詢優(yōu)化器可以自動 QueryRewrite 復(fù)用物化視圖，從而達到查詢加速的效果。

在 2.4 之前，我們僅支持的是單表同步的物化視圖，但它缺乏一些復(fù)雜場景的支持，例如只能支持一些簡單的 SQL。

對于一個實時的場景，比如用戶有兩張實時表進行 Join 操作，由于單表同步物化視圖不支持多表 Join 操作，這種場景就無法支持了。

對于離線多表加速建模的場景，通常需要事實表和維度表的 Join 的操作。這里面有兩方面的需求，一方面是加速的需求，希望我們在查這些 Base 表時通過 QueryRewrite 加速查詢；另一方面是建模的需求，希望物化視圖能夠屏蔽后面的事實表和維度表，也就是說希望物化視圖可以直接進行查詢。

還有一類場景，這類場景雖然也可以支持，但是支持得不是很好，就是當(dāng)物化視圖的計算結(jié)果比較少的時候，希望分區(qū)分桶比較少，這樣查詢性能才會比較好。之前同步的模型，物化視圖與 Base 表是一對一的關(guān)系，可能就會出現(xiàn)創(chuàng)建物化視圖雖然結(jié)果很少，但是分區(qū)分桶很多，反而出現(xiàn)查詢性能下降的現(xiàn)象。

根據(jù)這些場景和問題，接下來我們看看可以怎么去解決這些問題。

02、物化視圖的設(shè)計

1同步解決方案

我們觀察到 SQL 復(fù)雜度越低，數(shù)據(jù)的同步性越好做，當(dāng) SQL 復(fù)雜度越高，數(shù)據(jù)的同步性越來越難做。之前的同步物化視圖，其實是選擇了同步性最佳的點，但它的弊端就是 SQL 很復(fù)雜的時候很難做。但是用戶的大部分場景 SQL 可能是很復(fù)雜的，并且可以接受一定的異步延遲，所以可以犧牲一定的同步性，滿足復(fù)雜 SQL 加速的場景。于是就有了異步刷新的解決方案。

2異步刷新的解決方案

首先我們看看怎么解決之前的實時場景的問題。在我們使用新版創(chuàng)建物化視圖時，可以通過 PARTITION BY 關(guān)鍵字來指定物化視圖跟某一個 Base 表的一個分區(qū)進行綁定，當(dāng)前的版本分桶是必填的，但是分桶是可以靈活變化的，然后還可以指定刷新的起始時間點和間隔。

我們創(chuàng)建物化視圖語句里面的 Query 語句本身是基本沒有任何限制的，可以寫得很復(fù)雜，只要是可以查詢的基本都可行。對于實時的場景，它其實是只刷新某一個分區(qū)的小部分數(shù)據(jù)量。對于實時表，導(dǎo)入非常頻繁的，用戶可以接受分鐘級刷新的場景下，用戶可以使用周期性刷新，例如每 1 分鐘刷新一次，這樣可以避免刷新頻率過高導(dǎo)致物化視圖刷新觸發(fā)過于頻繁。

然后我們再看看離線的場景，離線場景 Base 表，通常事時表基本上只有每天才會去刷新某一個分區(qū)，維表會全量刷新一個分區(qū)。這里我們在創(chuàng)建物化視圖時，可以指定 REFRESH ASYNC，當(dāng)每個 Base 表有數(shù)據(jù)變化的時候，它會自動去判定哪些分區(qū)需要刷新并進行智能刷新，對于不需要刷新的分區(qū)就不刷新。離線場景也可以支持以天為周期進行調(diào)度。離線的場景下由于數(shù)據(jù)量比較大，有可能查詢需要調(diào)整一些特殊的 Session Variable 參數(shù)才能夠刷新成功，這些特殊的參數(shù)可以通過 Query 里面的 SELECT hint 來傳入。

但是物化視圖其是一個需要長期打磨的功能。周期性刷新和觸發(fā)式刷新覆蓋不了所有的場景，有可能用戶在不需要刷新的時候，還花費了很多刷新的成本。所以我們提供了一個手動刷新的功能，讓用戶能靈活地控制刷新的時機，也就是通過指定 REFRESH MANUAL。等到物化視圖在后面的版本越來越完善的時候，使用手動刷新的情況會漸漸較少。

另外之前還提到了分區(qū)分桶浪費的問題，關(guān)于解決這個問題的方法，可以通過指定PARTITION BY DATE_TRUNC（“month”， dt），這樣我們就可以把 dt 這一列本來按天的 Base 表上卷到按月分區(qū)的表，從而來減少分區(qū)浪費的問題。同時我們也可以指定 Bucket 的數(shù)量，而不是跟 Base 表保持一致。這樣在物化視圖的結(jié)果很少的情況下，我們可以靈活減少分區(qū)和分桶，從而提高查詢性能，避免分區(qū)分桶的浪費。

以上講的這些都是 StarRocks 2.4 已經(jīng)實現(xiàn)的功能，這些功能是 StarRocks 和社區(qū)共同討論并實現(xiàn)的。在這里要感謝社區(qū)的小伙伴們。

03、物化視圖的實現(xiàn)原理

先來了解一下多表物化視圖的框架，即數(shù)據(jù)模型。在早期的版本中，我們實際上支持的是單表同步物化視圖，也就是我們基于一個原始表去創(chuàng)建物化視圖，實際上物化視圖是以索引的形式去存在的。

在左圖中可以看到表的基礎(chǔ)索引中的 Tablet 和物化視圖索引的 Tablet 是一一對應(yīng)，但是在多表異步的物化視圖的框架中，Tablet 不是一一的對應(yīng)關(guān)系，物化視圖實際上是以表的模型去做實現(xiàn)的。以右圖為例，假設(shè) Base 表有兩個 Partition A 和 B，假設(shè)物化視圖有 Partition C，那么 Partition A、Partition B 的 Tablet 和物化視圖的 Partition C 中的 Tablet 是映射關(guān)系，這種關(guān)系不是一一對應(yīng)的關(guān)系。

再來看一下物化視圖的整體框架。我們在新的版本中主要實現(xiàn)了多表異步物化視圖，那么就需要一個異步物化視圖的調(diào)度框架及相應(yīng)的一些實現(xiàn)邏輯。以上圖舉例，比如在創(chuàng)建物化視圖以及刷新物化視圖的時候，我們都需要有對應(yīng)的 Task，以及 TaskRun 執(zhí)行單元去做相應(yīng)的處理。

核心的實現(xiàn)內(nèi)容實際上包含以下三方面的技術(shù)：Task 調(diào)度框架、分區(qū)刷新維護、Insert Overwrite。Task 調(diào)度框架解決的是物化視圖異步刷新的問題，分區(qū)刷新維護解決的是分區(qū)同步增刪以及刷新的問題，Insert Overwrite 是刷新中的核心技術(shù)。

1Task 調(diào)度框架

首先給大家介紹一下 Task 調(diào)度框架。Task 實際上是一個可重用的對象，是任務(wù)的存儲模板。TaskRun 是其中真正的計算對象，每一個 TaskRun 都是基于 Task 這個模板去做實現(xiàn)的，是計算的最小單元。可以類比成 Java 的 Class，以及 Class 相應(yīng)的一些實現(xiàn) Object。在 Task 調(diào)度框架中，支持手動刷新、觸發(fā)式刷新以及周期性刷新等三種刷新方式。

再來看調(diào)度框架的核心架構(gòu)。調(diào)度框架包含這幾方面的內(nèi)容，一個是調(diào)度器，然后是 Task 和 TaskRun，Pending 隊列、Running 隊列以及 TaskRun history 集合。以手動刷新任務(wù)舉例，首先基于 Task 去創(chuàng)建 TaskRun 對象，存放在 Pending 隊列中。調(diào)度器會取出 Pending 隊列中的 TaskRun 做相應(yīng)的執(zhí)行，并存放到 Running 隊列中，同時會基于 TaskRun 運行的狀態(tài)，進入到 TaskRun history 集合中。在調(diào)度框架中也有一些參數(shù)可以配置，比如現(xiàn)在我們隊列長度默認是 500，并發(fā)數(shù)默認是 20，TaskRun 默認是清除是三天以上的歷史。有了 Task 框架，我們還需要進行分區(qū)的刷新維護。2分區(qū)刷新維護

在創(chuàng)建物化視圖的時候，實際上我們指定了物化視圖跟某一個 Base 表分區(qū)的綁定關(guān)系，刷新框架會在刷新前增刪分區(qū)，以保證物化視圖的分區(qū)大于 Base 表綁定的分區(qū)。以圖中舉例，假設(shè)我們有這樣一個表，它有三個分區(qū) A、B、C，物化視圖也有三個分對應(yīng)的分區(qū) A、B、C，它們是一一對應(yīng)關(guān)系。除了這么種 1:1 的映射關(guān)系，實際上其中還有 1:n、n:1 以及 n:n 的映射關(guān)系。

有了分區(qū)映射關(guān)系，就可以基于分區(qū)的映射關(guān)系去做對應(yīng)的一些刷新。我們是基于分區(qū)的版本去判斷哪些分區(qū)需要做刷新。以圖上舉例，假設(shè) Base 表有 1、2、3 三個分區(qū)，物化視圖也有 1、2、3 三個分區(qū)，Base 表分區(qū) 1 的版本是 2，物化視圖分區(qū) 1 的版本也是 2，這個時候我們是不需要去做刷新的。假設(shè) Base 表的分區(qū) 2 版本是 4，而物化視圖的分區(qū) 2 版本是 3，這個時候我們判斷需要去做進一步刷新。那么怎么樣去做刷新，實際上是依靠于我們底層的 Insert Overwrite 技術(shù)。

3Insert Overwrite

相信有很多同學(xué)用過臨時分區(qū)，實際上 Insert Overwrite 的原理就是內(nèi)置的這一過程。通常有三個步驟，首先創(chuàng)建一個臨時分區(qū)，然后把數(shù)據(jù)寫到臨時分區(qū)，最終將臨時分區(qū)和目標分區(qū)做原子級別的替換。

那么以上是多表異步物化設(shè)圖的三種核心技術(shù)的實現(xiàn)原理。除此我們還需要考慮物化視圖失效的問題。

當(dāng)用戶修改 Base 表的結(jié)構(gòu)時，比如刪除了 Base 表的一個列時，這個時候物化視圖可能會失效。在當(dāng)前的版本中，物化視圖仍然可以查詢，但是它不能夠被刷新。

以上就是物化視圖核心技術(shù)實現(xiàn)原理。

上述這些都是 2.4 版本已經(jīng)實現(xiàn)的功能。StarRocks 2.4 版本是一個預(yù)覽版本，需要通過設(shè)置 FE 參數(shù) enable_experimental_mv 開啟使用。

04、StarRocks 2.5 版本展望

2.4 版本還有三個比較重要的功能沒有實現(xiàn)。一是不支持從外表去創(chuàng)建物化視圖，2.4 的版本只支持在一個數(shù)據(jù) DB 上去創(chuàng)建物化視圖，并不支持跨 DB 創(chuàng)建物化視圖；二是不支持創(chuàng)建基于物化視圖的物化視圖；三是還不支持最重要的 QueryRewrite 功能。

2.5 版本會支持物化視圖的查詢改寫，支持從外表創(chuàng)建物化視圖，支持從物化視圖創(chuàng)建物化視圖，支持物化視圖 TTL，優(yōu)化刷新效率、增加部分刷新的語法和配置來應(yīng)對復(fù)雜的刷新問題和各種復(fù)雜場景，大家可以盡請期待。

審核編輯：郭婷