Doris 物化视图：原理、使用及常见问题处理
1.Doris 物化视图介绍
在大数据分析领域，数据量的快速增长和复杂查询的频繁出现，对查询性能提出了严峻挑战。Doris 的物化视图（Materialized View）应运而生，成为提升查询效率的有力工具。简单来说，物化视图是将预先计算（根据定义好的 SELECT 语句）的数据集，存储在 Doris 中的一个特殊的表。与普通视图不同，普通视图仅包含计算逻辑，本身不存储数据，而物化视图既包含计算逻辑也包含数据实体。
物化视图根据 SQL 定义计算并存储数据，并根据特定策略进行周期性或实时性更新。它可以直接被查询，也能将查询透明改写，从而极大地提升查询性能。在决策支持系统，如 BI 报表、Ad-Hoc 查询等场景中，分析型查询通常包含聚合操作，可能还涉及多表连接，计算此类查询结果较为消耗资源，响应时间可能长达分钟级，而业务场景往往要求秒级响应，此时构建物化视图对常见查询进行加速就显得尤为重要。在数据分层场景中，可以通过嵌套物化视图来构建 DWD 和 DWM 层，利用物化视图的调度刷新能力。针对多种外部数据源，将这些数据源所使用的表构建为物化视图，能够节省从外部表导入到内部表的成本，并且加速查询过程。
2.Doris 物化视图原理
2.1 同步物化视图原理
同步物化视图旨在与基表的数据保持强一致性。其工作机制是将预先按照定义好的 SELECT 语句计算的数据集，存储在 Doris 中。Doris 会自动维护同步物化视图的数据，无论是新数据导入基表，还是对基表数据进行删除操作，都能保证在 Base 表和物化视图表的数据同步更新、保持一致后，相关操作命令才会结束，无需任何额外的人工维护成本。在查询时，Doris 的查询优化器会自动匹配到最优的物化视图，并直接从物化视图中读取数据，从而避免了对基表的重复复杂计算，提升查询效率。
同步物化视图目前存在一定限制，它只支持针对单个表的 SELECT 语句，支持 WHERE、GROUP BY、ORDER BY 等子句，但不支持 JOIN、HAVING、LIMIT 子句和 LATERAL VIEW。当面对 Unique Key 数据模型时，同步物化视图只能改变列的顺序，无法进行聚合操作。
2.2 异步物化视图原理
异步物化视图同样是根据定义的查询逻辑预先计算并存储结果。与同步物化视图不同的是，其更新机制相对灵活，并非与基表数据更新实时同步。异步物化视图可以通过多种方式触发刷新，包括用户通过 SQL 语句手动触发、按照定时任务进行刷新，以及在基表数据发生变更后自动触发相关物化视图刷新。
物化视图的刷新是以分区为单位进行。若物化视图未指定分区，每次刷新将针对默认分区，即刷新全部数据。在创建物化视图时，可以自定义分区，也可依赖基表的分区自动创建分区。如果不指定分区信息，物化视图将默认创建一个分区，所有数据都存放在这个分区中。物化视图还可以通过多个基表 join 关联创建，并可选择追随其中一个基表进行分区（建议选择事实表）。例如，当物化视图与具有多个分区的基表关联时，可根据需要选择基表的某一级分区列作为物化视图的分区列。
此外，对于只关注基表中最近一段时间 “热” 数据的场景，物化视图也提供了相应支持。通过特定的创建语句设置，可使物化视图仅关注指定时间段内的数据，随着时间推移，在刷新物化视图时，其分区数据也会相应调整。
3.Doris 物化视图使用
3.1 同步物化视图使用
3.1.1 创建同步物化视图
在 Doris 中创建同步物化视图，使用 CREATE MATERIALIZED VIEW 语句。例如，假设有一张销售记录表 sales_records，包含字段 store_id（门店 ID）、sale_amount（销售金额）等，若要创建一个以门店为分组，统计各门店销售总额的同步物化视图 store_amt，可使用以下语句：
CREATE MATERIALIZED VIEW store \ _amt ON sales \ _records & #x20;
AGGREGATE KEY(store \ _id) COMMENT "Store sales amount materialized view" PROPERTIES ("replication\_num" = "3") AS
SELECTstore \ _id,SUM(sale \ _amount) AS total \ _sale \ _amount
FROMsales \ _records
GROUP BYstore \ _id;
在上述语句中，ON 关键字指定基表为 sales_records，AGGREGATE KEY 指定了聚合的键为 store_id，AS 子句后的 SELECT 语句定义了物化视图的数据来源和计算逻辑。同时通过 PROPERTIES 设置了副本数为 3。
3.1.2 查询同步物化视图
当同步物化视图创建完成后，用户在查询不同门店的销售量时，无需对查询语句进行特别修改，依旧指定查询 sales_records 表。例如执行查询：
SELECTstore \ _id,SUM(sale \ _amount) AS total \ _sale \ _amount
FROMsales \ _records
GROUP BYstore \ _id;
Doris 会自动匹配到 store_amt 物化视图，并直接从该物化视图中读取聚合好的数据，从而提升查询效率。用户可以通过 EXPLAIN 命令来检验当前查询是否匹配到了合适的物化视图。例如：
EXPLAIN
SELECTstore \ _id,SUM(sale \ _amount) AS total \ _sale \ _amount
FROMsales \ _records
GROUP BYstore \ _id;
在返回的执行计划中，如果看到类似 volapscannode 的 test_db.sales_records (store_amt) 字样，表明该查询命中了 store_amt 这个物化视图。
3.1.3 删除同步物化视图
若不再需要某个同步物化视图，可使用 DROP MATERIALIZED VIEW 语句删除。例如删除刚才创建的 store_amt 物化视图，语句如下：
DROP MATERIALIZED VIEW store\_amt ON sales\_records;
3.2 异步物化视图使用
3.2.1 创建异步物化视图
异步物化视图的创建同样使用 CREATE MATERIALIZED VIEW 语句，但在分区设置和刷新策略等方面更为灵活。假设存在两张表 t1 和 t2，其中 t1 为事实表，包含字段 event_time（事件时间）、user_id（用户 ID）、event_type（事件类型）等，t2 为维度表，包含字段 user_id、user_region（用户地区）等。要创建一个基于 t1 和 t2 关联，按天分区（追随 t1 的 event_time 字段分区），统计每天每个地区不同事件类型的用户数量的异步物化视图，可以使用以下语句：
CREATE MATERIALIZED VIEW user \ _event \ _mv PARTITION BY DATE \ _TRUNC('DAY', t1.event \ _time) AS
SELECTDATE \ _TRUNC('DAY', t1.event \ _time) AS event \ _date,t2.user \ _region,t1.event \ _type,COUNT(DISTINCT t1.user \ _id) AS user \ _count
FROMt1JOIN t2 ON t1.user \ _id = t2.user \ _id
GROUP BYDATE \ _TRUNC('DAY', t1.event \ _time),t2.user \ _region,t1.event \ _type PROPERTIES ("refresh\_interval" = "86400","replication\_num" = "3","auto\_refresh" = "true");
上述语句中，PARTITION BY 指定了按 t1 的 event_time 字段按天分区。AS 子句后的 SELECT 语句定义了关联和聚合逻辑。通过 PROPERTIES 设置了刷新间隔为一天（86400 秒），副本数为 3，并且开启了自动刷新功能。
3.2.2 刷新异步物化视图
异步物化视图有多种触发刷新机制：
用户通过 SQL 语句触发：
自动计算刷新分区：使用 REFRESH MATERIALIZED VIEW [mv_name] AUTO; 语句，不关心具体刷新哪些分区，要求刷新完成后，物化视图的数据和基表保持同步。例如 REFRESH MATERIALIZED VIEW user_event_mv AUTO;
全量刷新：使用 REFRESH MATERIALIZED VIEW [mv_name] COMPLETE; 语句，不管物化视图现存哪些数据，刷新物化视图的所有分区。例如 REFRESH MATERIALIZED VIEW user_event_mv COMPLETE;
指定分区刷新：使用 REFRESH MATERIALIZED VIEW [mv_name] PARTITIONS ([partition_name1],[partition_name2]); 语句，只刷新指定的分区。例如 REFRESH MATERIALIZED VIEW user_event_mv PARTITIONS ('2024-01-01','2024-01-02');
定时触发：在创建物化视图时通过设置 “refresh_interval” 属性来指定定时刷新间隔，如上述创建 user_event_mv 时设置了每天刷新。
基表数据变更触发：在创建物化视图时设置 “auto_refresh” = “true”，当基表数据发生变更后，自动触发相关物化视图刷新，刷新的分区范围与定时触发一致。
3.2.3 查询异步物化视图
查询异步物化视图与同步物化视图类似，用户正常编写针对基表的查询语句即可。例如查询某天某个地区某种事件类型的用户数量：
SELECTevent \ _date,user \ _region,event \ _type,COUNT(DISTINCT user \ _id) AS user \ _count
FROMt1JOIN t2 ON t1.user \ _id = t2.user \ _id
WHEREevent \ _date = '2024-01-01'AND user \ _region = 'East'AND event \ _type = 'click'
GROUP BYevent \ _date,user \ _region,event \ _type;
Doris 会自动匹配并使用 user_event_mv 物化视图进行查询加速。同样可通过 EXPLAIN 命令来验证是否命中物化视图。
3.2.4 删除异步物化视图
删除异步物化视图的语句与同步物化视图相同。例如删除 user_event_mv 物化视图：
DROP MATERIALIZED VIEW user\_event\_mv;
4.常见问题及处理方案
4.1 物化视图未命中问题
在查询时，有时会出现期望的物化视图未被命中的情况。这可能是由于以下原因导致：
查询与物化视图定义不匹配：查询的聚合逻辑、过滤条件、分组方式等与物化视图的定义差异较大，导致 Doris 无法识别匹配。需要仔细检查查询语句和物化视图定义，确保二者在关键逻辑上一致。例如，查询中使用的聚合函数、分组字段等应与物化视图中的对应部分相同。
候选物化视图过多：当存在多个候选物化视图时，Doris 的查询优化器可能选择了并非最优的物化视图。可以通过调整物化视图的设计，减少不必要的物化视图数量，或者通过设置合适的查询优化参数，引导查询优化器选择更优的物化视图。例如，在某些情况下，可以通过设置查询提示（如 USE [mv_name]）来强制使用指定的物化视图，但这通常是在明确知道哪个物化视图最优的情况下使用。
统计信息不准确：Doris 依赖准确的统计信息来判断使用哪个物化视图更合适。如果统计信息过时或不准确，可能导致物化视图选择错误。可以通过执行 ANALYZE TABLE 语句来更新表和物化视图的统计信息，例如 ANALYZE TABLE sales_records; ANALYZE TABLE store_amt;
4.2 物化视图数据不一致问题
在数据更新操作后，可能出现物化视图数据与基表数据不一致的情况：
刷新延迟：对于异步物化视图，如果刷新间隔设置过长，或者刷新过程中出现异常，可能导致物化视图数据滞后于基表数据。可以适当缩短刷新间隔，确保数据的时效性。同时，要检查刷新任务的执行日志，查看是否有报错信息。例如，如果发现刷新任务长时间未完成或频繁失败，可能是由于网络问题、资源不足等原因导致，需要针对性地进行排查和解决。
并发操作冲突：在高并发的数据导入或更新场景下，可能出现并发操作冲突，影响物化视图的更新。可以通过合理设置事务隔离级别，以及对数据操作进行适当的排队或限流，来避免并发冲突。例如，将事务隔离级别设置为可串行化（Serializable），虽然会降低并发性能，但能有效保证数据一致性。在实际应用中，需要根据业务场景的并发需求和数据一致性要求进行权衡。
4.3 物化视图资源占用问题
物化视图的创建和维护会占用一定的存储和计算资源：
存储资源占用：随着物化视图数量的增加以及数据量的增长，物化视图占用的存储资源可能成为问题。可以定期清理不再使用的物化视图，减少不必要的存储开销。同时，在设计物化视图时，要合理规划分区和数据存储方式，避免过度存储冗余数据。例如，如果某些物化视图只需要保留最近一段时间的数据，可以设置合适的分区过期策略，定期删除过期分区。
计算资源占用：在创建物化视图或进行刷新操作时，会消耗一定的计算资源，可能影响其他查询或任务的性能。可以通过调整 Doris 的资源调度策略，为物化视图相关操作分配合理的资源份额。例如，在资源紧张的情况下，可以将物化视图的创建和刷新任务安排在系统负载较低的时间段进行，或者通过设置资源队列，限制物化视图操作对资源的占用比例。
Doris 的物化视图是提升查询性能的强大工具，但在使用过程中需要深入理解其原理，合理进行设计和配置，并针对可能出现的问题采取有效的处理方案，才能充分发挥其优势，满足大数据分析场景下对查询效率的高要求。