实时物化视图_云原生数据仓库AnalyticDB(AnalyticDB)-阿里云帮助中心

云原生数据仓库 AnalyticDB PostgreSQL 版提供了实时物化视图功能，相较于普通（非实时）物化视图，实时物化视图无需手动调用刷新命令，即可实现数据更新时自动同步刷新物化视图。

云原生数据仓库 AnalyticDB PostgreSQL 版中，实时物化视图采用增量方式进行数据更新。即当基表的数据变化时，实时物化视图会根据基表的更新进行增量的数据更新。基于此特性，可利用实时物化视图进行类似实时ETL的数据处理任务。此外，还可以基于实时物化视图再创建实时物化视图，当基表发生变化时，相关级联的实时物化视图也会自动更新。如此可实现构建数据分析的实时ETL处理链路。

云原生数据仓库 AnalyticDB PostgreSQL 版的实时物化视图当前支持同步模式和异步模式。

在同步模式下，实时物化视图采用的是STATEMENT（语句）级别的自动更新，即当基表的更新语句（INSERT、COPY、UPDATE、DELETE）执行成功的同时，构建于基表的物化视图会实时更新，保证数据的强一致性。如果实时物化视图的更新未完成，写入事务也无法提交。
在异步模式下，对基表先执行写入操作，操作结束后可以正常提交事务，而后实时物化视图的增量更新会在后台由数据库内核自动调度。通常，系统负载正常情况下可以在秒级完成数据更新。

普通物化视图的详细信息，请参见物化视图管理。

同步模式

云原生数据仓库 AnalyticDB PostgreSQL 版的实时物化视图的同步模式采用的是STATEMENT一致性。即当基表的某条语句执行成功时，实时物化视图中的数据将会同步更新。STATEMENT实时物化视图可以实现当对基表的更新语句执行成功时，对应的物化视图的数据已经完成更新，更新逻辑如下。

数据库内核将先对基表执行更新，再对物化视图执行更新。当基表更新失败时，物化视图中的数据不会发生变化。
如果对物化视图更新失败，则基表的更新也将失败，基表数据将不会有任何变化，同时对基表执行的语句将返回失败。

如果使用显式事务（例如BEGIN+COMMIT），当基表的更新语句执行成功后，物化视图中的数据更新同样在这个事务中：

如果云原生数据仓库 AnalyticDB PostgreSQL 版中隔离级别为READ-COMMITTED，当事务未提交时，物化视图中的更新对其他事务将不可见。
如果事务回滚，基表和物化视图都会进行相应的回滚。

版本限制

在以下版本中，实时物化视图将默认使用同步模式。

内核版本为v7.0.6.9（不含）以下的AnalyticDB PostgreSQL 7.0版实例。
内核版本为v6.6.2.5（不含）以下的AnalyticDB PostgreSQL 6.0版实例。

如需切换实时物化视图默认模式，请提交工单。

异步模式

在异步模式下，基表写入操作先完成，并可以正常提交事务，此时实时物化视图中的数据不会立即更新。在事务提交后，由数据库内核在后台自动调度实时物化视图的数据增量更新，并发的写入事务会由数据库自行处理。在实时物化视图更新的过程中可能进行攒批更新等操作，数据库内核对所有并发基表的写入操作，以最终数据一致性的目的更新实时物化视图。因此，即使是异步模式下的并发写入，数据库内核也会保证实时物化视图中的数据与基表的数据最终是一致的。由于系统负载正常时实时物化视图的更新通常可以在秒级完成，因此异步模式能满足大部分实时数仓场景的需求。

版本限制

在以下版本中，新创建的实时物化视图将默认使用异步模式。

内核版本为v7.0.6.9及以上的AnalyticDB PostgreSQL 7.0版实例。
内核版本为v6.6.2.5及以上的AnalyticDB PostgreSQL 6.0版实例。

如需切换实时物化视图默认模式，请提交工单。

使用限制

云原生数据仓库 AnalyticDB PostgreSQL 版对构建实时物化视图所使用的查询语句有所限制，您只能创建包含如下查询语句的实时物化视图。

查询语句可以包含大部分的过滤和投影操作，以及大部分的Postgres内置函数和UDF函数。
查询语句可以包含大部分的聚合函数和窗口函数。
如果查询语句包含JOIN，支持使用INNER JOIN和OUTER JOIN语句。
如果查询语句包含OUTER JOIN，JOIN条件仅支持AND连接，不支持OR连接，不支持等值条件的左右列来自同一张表。
仅支持简单查询、FROM子查询及UNION ALL查询语句，不支持CTE和其它类型子查询等复杂查询语句。

当您在基表上创建了实时物化视图，对基表执行的DDL将受到限制，限制如下。

对基表执行TRUNCATE命令时，实时物化视图不会同步变化，需要手动刷新物化视图或重建物化视图。
只有指定了CASCADE选项，才能对基表执行DROP TABLE命令。
对基表执行ALTER TABLE命令无法删除或修改物化视图引用的字段。

使用场景

建议您在具有如下特征的场景使用实时物化视图。

基于实时物化视图的增量更新及嵌套级联能力，可以方便地构建实时ETL处理链路，且无需额外的调度系统处理依赖关系。既可在上游原始基表上创建实时物化视图，还可以基于实时物化视图再创建下游级联的实时物化视图，以产出实时ETL的处理结果，例如比较典型的实时宽表，实时聚合等，用于加速查询分析。
基于实时物化视图可以大幅加速查询结果的速度。尤其针对查询结果相对于对基表仅包含少量的行或列，或者获取查询结果需要经过大量的计算处理的场景，包括：
- 具有很高过滤性的过滤条件。
- 高度集中的聚合函数等场景。
- 半结构化数据分析。
- 需要很长时间才能计算完成的聚合操作。
视图的基表中包含很大的全量数据，增量数据的更新量远小于全量数据。

实时物化视图适用于所有适合使用普通物化视图的场景。与普通物化视图相比，实时物化视图具有高度的数据一致性，当基表发生改变时，实时物化视图将以较低的性能消耗（增量）发生改变，而普通物化视图如果每次基表发生改变，都需要手动执行全量刷新操作才能保证数据的一致性，大部分时候性能消耗较大。所以当基表具有一定程度的更改，甚至需要流式导入更新时，相较于普通物化视图，实时物化视图具有很大优势。

实时物化视图代价

实时物化视图类似实时维护的索引，在对查询性能进行大幅度优化的同时，对高性能写入有一定影响。影响实时物化视图写入性能的几个关键因素：

构建实时物化视图查询语句的复杂度和级联的层数。单表和简单JOIN的单层实时物化视图可以在不同配置的实例上支持每秒数万到数十万行的写入。复杂JOIN及多层嵌套场景的写入会占用更多的实例计算资源，同时写入性能相应成比例降低。
包含JOIN的实时物化视图可能存在写入放大的情况。例如，当某张10亿数据量的事实表JOIN一张1万数据量的维度表的实时物化视图中，10亿级的事实大表通常可以获得很高的写入性能，而1万数据量的较小维度表的数据变化由于增量计算时对结果集的影响存在放大，写入性能会成比例（写入放大的比例）降低。
云原生数据仓库 AnalyticDB PostgreSQL 版实例的规模和资源。实时物化视图进行增量计算和写入过程中会使用实例资源，实例的规模和资源对实时物化视图写入效率会产生影响。当实时写入的性能不满足业务需求时，可以考虑增加计算资源以获取更好的写入性能。

创建/删除实时物化视图

使用CREATE INCREMENTAL MATERIALIZED VIEW命令创建一个名为mv实时物化视图，示例如下。
```
CREATE INCREMENTAL MATERIALIZED VIEW mv AS SELECT * FROM base WHERE id > 40;
```
使用DROP MATERIALIZED VIEW命令删除物化视图mv，示例如下。
```
DROP MATERIALIZED VIEW mv;
```

使用示例

创建基表。

CREATE TABLE test (a int, b int) DISTRIBUTED BY (a);

创建实时物化视图。

CREATE INCREMENTAL MATERIALIZED VIEW mv AS SELECT * FROM TEST WHERE b > 40 DISTRIBUTED BY (a);

向基表插入数据。

INSERT INTO test VALUES (1, 30), (2, 40), (3, 50), (4, 60);

查看基表。

SELECT * FROM test;

查询结果如下。

 a | b
---+----
 1 | 30
 2 | 40
 3 | 50
 4 | 60
(4 rows)

查看物化视图。
```
SELECT * FROM mv;
```
物化视图已经修改成功，查询结果如下：
```
 a | b
---+----
 3 | 50
 4 | 60
(2 rows)
```