使用物化视图进行数据建模

自动刷新​

创建异步物化视图时，您可以使用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做分区上卷。

• 仅支持单个列作为分区列，不支持多分区列。