物化视图可观测能力

背景概览

云原生数据仓库 AnalyticDB MySQL 版支持物化视图，根据查询特性不同，可使用增量刷新或全量刷新。物化视图将表结构与加工逻辑封装在一起，并内置定时调度能力。用户只需定义业务逻辑与时效性要求，无需自行管理复杂的数据管道与血缘关系。

在生产环境中，当大规模使用物化视图构建数据管道时，常面临以下问题：

• 血缘归因困难：在嵌套物化视图级联刷新场景中，下游结果表出现延迟时，难以快速定位上游异常节点。

• 故障感知滞后：物化视图任务因合理原因失败（如上游表结构变更），但外部系统无法及时获知，导致错误结果被下游业务使用，造成资产损失。

• 治理缺乏依据：大量物化视图持续消耗CPU和存储资源，还会产生额外的计算费用，但缺乏从业务视角量化其价值的手段，难以清理无效视图。

• 延迟波动不可控：某次刷新因上游数据量激增导致耗时增加，进而引发后续任务排队积压，需快速识别异常批次。

主动告警：及时感知刷新失败与延迟

AnalyticDB MySQL内核可检测物化视图任务的异常事件（如任务失败或延迟），并自动向阿里云云监控发送告警事件。告警可通过短信、钉钉、飞书等渠道实时推送。

血缘关系：通过 DAG 图定位异常节点

对于嵌套刷新的物化视图链路，控制台提供DAG视图，支持递归查看某张物化视图的所有父表（包括基础表与上游物化视图）。

在左侧导航栏选择数据管理 > 数据目录，单击物化表对应的数据库，单击物化视图页签。单击对应的视图名，在血缘关系页签查看。

任务堆积观测与分析

物化视图刷新任务可能出现延迟，常见原因包括写入高峰期导致 IO 资源争抢、计算资源不足等。快速判断当前任务是否异常是运维关键。

1. 通过控制台查看物化表的历史刷新任务

   在物化表视图详情页的刷新策略页签，可以查看刷新历史。

   刷新任务状态说明

   • PENDING：等待调度周期开始，尚未分配资源。

   • RUNNING：已进入调度周期，正在等待或已分配计算资源执行。

   • FINISHED：刷新成功完成。

   • FAILED：刷新失败。系统将自动重试最多 10 次；若仍失败，则跳过本次任务。增量视图下次刷新时会补扫遗漏数据，保证最终一致性。

   • TIMEOUT：任务长时间未完成，系统将其标记为超时并重新触发。建议提交工单排查。

   刷新策略现在有两种，更多区别详情请参见如何选择刷新策略。

   • COMPLETE：全量刷新。

   • FAST：增量刷新。

2. 通过SQL查询自动刷新记录

   -- 查询指定物化视图的自动刷新任务
   -- mv_schema: 物化视图所在的数据库名
   -- mv_name:   物化视图的名称
   SELECT * FROM information_schema.mv_auto_refresh_jobs WHERE mv_schema = 'db_name' AND mv_name = 'mv_name';

   判断方法：

   1. 找出最新刷新任务（通常为 PENDING 或 RUNNING 状态）。

   2. 计算历史任务平均耗时（结束时间 - 启动时间）。

   3. 对比当前任务耗时（若为 RUNNING，则为当前时间 - 启动时间）。

   4. 若当前耗时显著高于历史均值，则可能存在异常，需进一步诊断。

   更多详情请参见查询物化视图的刷新记录。

量化价值：辅助进行成本治理

当系统中存在大量物化视图时，需识别低价值或无人访问的视图，以优化资源使用。

1. 在物化表视图详情页的查询热度页签，可以查看热度指标。

   • 显式访问（explicit_hit）：用户 SQL 显式查询该物化视图（包括嵌套刷新中父视图对子视图的引用）。

   • 隐式访问（implicit_hit）：该物化视图被查询改写机制自动选用。

   说明

   • 若物化视图连续 30 天未被访问，系统将发出提醒。

   • 查询热度标签页展示最近 7 天的访问统计，默认每小时更新一次。

2. 通过SQL查询热度数据。

   -- 查询指定物化视图的命中统计信息
   -- mv_name: 物化视图的名称
   -- explicit_hit:  显式查询命中次数（用户直接查询该物化视图）
   -- implicit_hit: 隐式查询命中次数（优化器自动改写查询，使用该物化视图加速）
   SELECT explicit_hit, implicit_hit
   FROM mv_info
   WHERE mv_name = 'mv_db';

   该数据可用于评估物化视图的实际业务价值，支持精准的数据治理决策。