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

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

01、物化視圖的需求分析

1什么是物化視圖

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

2物化視圖的應用場景

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

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

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

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

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

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

02、物化視圖的設計

1同步解決方案

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

2異步刷新的解決方案

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

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

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

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

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

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

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

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

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

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

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

1Task 調度框架

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

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

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

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

3Insert Overwrite

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

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

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

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

上述這些都是 2.4 版本已經(jīng)實現(xiàn)的功能。StarRocks 2.4 版本是一個預覽版本，需要通過設置 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)化刷新效率、增加部分刷新的語法和配置來應對復雜的刷新問題和各種復雜場景，大家可以盡請期待。

審核編輯：郭婷