E-MapReduce：使用物化視圖進行資料建模

自動重新整理​

建立非同步物化視圖時，您可以使用REFRESH子句指定重新整理策略。目前，StarRocks非同步物化視圖支援以下重新整理策略：

• 自動重新整理（REFRESH ASYNC）：每當基表中的資料發生變化時，都會觸發重新整理任務。資料依賴關係由物化視圖自動管理。

• 定時重新整理（REFRESH ASYNC EVERY (INTERVAL <refresh_interval>)）：定期觸發重新整理任務，例如，每分鐘、每天或每月。如果基表中沒有資料更改，將不會觸發重新整理任務。

• 手動重新整理（REFRESH MANUAL）：您只能通過手動執行REFRESH MATERIALIZED VIEW觸發重新整理任務。如果您通過外部調度架構觸發重新整理任務，可以使用此重新整理策略。

文法如下。

CREATE MATERIALIZED VIEW <db_name>.<mv_name>
REFRESH 
    [ ASYNC | 
      ASYNC [START <time>] EVERY(<interval>) | 
      MANUAL
    ]
AS <query>

分區重新整理​

建立非同步物化視圖時，您可以使用PARTITION BY子句將基表的分區與物化視圖的分區關聯起來，從而實現分區粒度的重新整理。

• PARTITION BY <column>：您可以為物化視圖引用與基表相同的分區列，從而使基表和物化視圖採用相同的分區粒度。

• PARTITION BY date_trunc(<column>)：您可以使用date_trunc函數在基表分區列的基礎上上卷，從而為物化視圖制定不同粒度的分區策略。

• PARTITION BY { time_slice | date_slice }(<column>)：與date_trunc相比，time_slice和date_slice提供更靈活的時間粒紋調整，允許更精細地控制時間分區粒度。

文法如下。

CREATE MATERIALIZED VIEW <db_name>.<mv_name>
REFRESH ASYNC
PARTITION BY 
    [
        <base_table_column> | 
        date_trunc(<granularity>, <base_table_column>) |
        time_slice(<base_table_column>, <granularity>) | 
        date_slice(<base_table_column>, <granularity>)
    ]
AS <query>

與視圖協同使用​

• 可以基於視圖建立物化視圖。此時，當視圖引用的基表發生資料更改時，物化視圖可以自動重新整理。

• 可以基於其他物化視圖建立物化視圖，實現多層級聯式重新整理。

• 可以基於物化視圖建立視圖，等同於基於常規表建立。

Schema Change​

• 非同步物化視圖可以通過ALTER MATERIALIZED VIEW SWAP語句進行原子替換。您可以建立一個新物化視圖，並增加新列或更改列類型，然後用新物化視圖替換舊物化視圖。

• 視圖可以通過ALTER VIEW語句直接修改定義。

• StarRocks中的常規表可以使用SWAP或ALTER操作進行修改。

• 基表（可以是物化視圖、視圖或常規表）發生更改時，將會觸發相應物化視圖中的級聯更改。

視圖與物化視圖的差異

修改視圖與基表

您可以使用以下語句來修改您的視圖、物化視圖和基表。

-- 修改基表。
ALTER TABLE <db_name>.<table_name> ADD COLUMN <column_desc>;

-- 原子替換基表。
ALTER TABLE <db_name>.<table1> SWAP WITH <table2>;

-- 修改視圖定義。
ALTER VIEW <db_name>.<view_name> AS <query>;

-- 原子替換物化視圖（替換兩個物化視圖的名字，並不修改其中資料）。
ALTER MATERIALIZED VIEW <db_name>.<mv1> SWAP WITH <mv2>;

-- 重新啟用物化視圖。
ALTER MATERIALIZED VIEW <db_name>.<mv_name> ACTIVE;

Schema Change遵循以下原則：

• 表的重新命名以及原子替換操作將導致依賴其的物化視圖變為Inactive狀態。對於Schema Change操作，僅當物化視圖依賴的基表列發生Schema Change時，才會導致物化視圖變為Inactive狀態。

• 視圖的定義變更將導致依賴其的物化視圖變為Inactive狀態。

• 物化視圖的原子替換操作將導致依賴其的嵌套物化視圖變為Inactive狀態。

• Inactive狀態會級聯向上傳播，直到沒有物化視圖依賴關係為止。

• Inactive狀態的物化視圖無法重新整理或用於自動查詢改寫。

• Inactive狀態的物化視圖仍然可以直接查詢，但在它們被變為Active之前，資料一致性不能得到保證。

由於Inactive狀態的物化視圖其資料一致性無法保證，您可以使用以下方法修複：

• 手動修複：您可以通過執行ALTER MATERIALIZED VIEW <mv_name> ACTIVE手動修複Inactive狀態的物化視圖。此語句將根據物化視圖原始SQL定義嘗試重建。需要注意的是，重建時需保證在底層Schema Change之後，SQL定義仍然有效，否則操作將失敗。

• 重新整理時修複：StarRocks將會在重新整理物化視圖時嘗試自動執行以上的修複命令，重建物化視圖再重新整理。

• 自動修複：StarRocks將會嘗試自動修複Inactive的物化視圖，您可以通過ADMIN SET FRONTEND CONFIG('enable_mv_automatic_active_check'='false')關閉此功能。

業務情境

分區關聯可以支援多種業務情境：

• 事實表更新：您可以將事實表分區到細粒度層級，例如按日或按小時。在事實表更新後，物化視圖中相應的分區將自動重新整理。

• 維度資料表更新：通常，維度資料表中的資料更新將導致所有關連接果的重新整理，重新整理代價較大。您可以選擇忽略某些維度資料表中的資料更新，以避免重新整理整個物化視圖，或者您可以指定一個時間範圍，從而只有在該時間範圍內的分區才能被重新整理。

• 外部表格的自動重新整理：在類似於Apache Hive或Apache Iceberg這樣的外部資料源中，資料往往以分區的粒度進行變更。StarRocks的物化視圖可以訂閱外表分區層級的資料更新，只重新整理物化視圖的相應分區。

• TTL：在為物化視圖設定分區策略時，您可以設定要保留的最近分區的數量，從而僅保留最新的資料。其對應的業務情境對資料時效性有較高要求，例如，分析師僅需要查詢某個時間視窗內的最新資料，而無需保留所有歷史資料。

您可以使用多個參數來控制重新整理行為：

• partition_refresh_number：每次重新整理操作中要重新整理的分區數。

• partition_ttl_number：要保留的最近分區的數量。

• excluded_trigger_tables：為避免觸發自動重新整理而需要忽略的表。

• auto_refresh_partitions_limit：每次自動重新整理操作中要重新整理的分區數。

使用限制

分區物化視圖存在如下限制：

• 僅支援基於分區表建立分區物化視圖。

• 僅支援DATE和DATETIME類型的分區列，不支援STRING類型。

• 僅支援使用date_trunc、time_slice和date_slice做分區上卷。

• 僅支援單個列作為分區列，不支援多分區列。