一文速通 OceanBase 物化视图能力！

OceanBase 2026-02-06

编者按

在实时数仓、HTAP（混合事务/分析处理）与库内计算（In-database Computing）成为主流的今天，数据架构的核心矛盾已悄然转变：企业不再仅仅追求“更快的查询”，而是面临着如何降低算力成本、简化数据链路、并保障核心系统稳定性的艰巨挑战。

传统的、依赖于复杂 ETL 管道的 T+1 数仓架构，日益无法满足企业的实时决策需求。正是在这一背景下，物化视图（Materialized View）这项经典技术，正被重新审视并赋予全新的战略价值。

物化视图的本质，是将高频、复杂的查询结果预先计算并物理存储在数据库内部。这看似简单的“空间换时间”，在现代架构中解决的远不止单个查询的性能问题。它通过将计算左移至数据源头，极大地简化了外部数据处理链路，减少了数据冗余和不一致的风险。更重要的是，它将消耗巨大的分析负载从核心交易流程中剥离，从而保障了在线业务的稳定性。因此，设计精良的物化视图能力，已不再是分析型数据库的“附加功能”，而是衡量一个现代数据库能否高效支撑 HTAP 和实时分析场景的核心指标。

基于此，OceanBase 对物化视图进行了深度重构，使其不仅仅是一个性能加速器，更是一个与分布式架构、多模引擎（行存、列存）深度融合的数据处理中枢，其实时物化视图能力能够在保证数据新鲜度的同时，提供高性能的查询服务。

本文将对 OceanBase 物化视图的核心能力、技术原理及应用场景进行全面介绍。

本文作者 | 朱涛，OceanBase 高级技术专家，负责 OceanBase 查询优化器的研发工作

OceanBase 物化视图的核心能力

OceanBase 的物化视图并非单一的功能，而是一套包含多种类型、灵活刷新策略和多样化查询加速机制的完整解决方案。其核心能力可归纳为以下几个方面：

多样化的物化视图类型

为了适应不同业务场景对数据新鲜度的需求，OceanBase 提供了两种主要的物化视图类型：

非实时物化视图：此类型视图中的数据并非总是与基表保持实时同步。它根据预设的计划（如定时）或手动触发进行刷新，在刷新间隔期内，查询将访问物化视图中已物理存储的数据。这种方式适用于对数据新鲜度要求不高，但对查询性能和资源消耗更为敏感的场景，如 T+1 的报表生成。

实时物化视图：该类型视图能够提供实时或准实时的数据查询结果。它通过内部的物化视图日志（MLOG）机制，捕获基表的增量数据变更。在查询时，系统会在线计算物化视图的存量数据和日志中的增量数据，从而返回最新的结果集。这使得用户即便在物化视图尚未完成物理刷新时，也能查询到最新的数据状态，特别适合实时监控、实时大屏等对数据时效性要求高的场景。

灵活的刷新机制

数据的刷新是维持物化视图生命力的关键。OceanBase 提供了全面且灵活的刷新策略与方式，以平衡数据时效性、系统资源开销和管理复杂度。

全方位的查询加速技术

创建物化视图的最终目的是加速查询。OceanBase 为此提供了一系列配套功能，最大化其性能优势：

查询改写 (Query Rewrite)：这是物化视图最核心的价值之一。当启用查询改写功能后，优化器能够自动将用户针对基表的查询请求，智能地重定向到已经预计算好的物化视图上，整个过程对应用透明，极大地降低了业务改造的复杂度。

与列存深度融合：自 4.3.3 版本起，OceanBase 支持创建基于列存格式的物化视图。当物化视图的查询逻辑涉及复杂的分析和聚合操作时，将其存储为列存格式可以获得比传统行存更优的查询性能，尤其是在“大宽表”分析场景下。

索引、主键与分区支持：物化视图在 OceanBase 中被视为一种特殊的表对象，因此可以像普通表一样，在其上创建索引、定义主键和设计分区策略。这些手段可以进一步优化对物化视图自身的查询性能，例如通过索引加速特定字段的过滤，或通过分区裁剪减少扫描的数据量。

OceanBase 物化视图的实现深度依赖其分布式架构和核心组件：

LSM-Tree 存储引擎：作为 OceanBase 的基石，LSM-Tree 引擎的特性使得列存表可以支持事务和流式写入，为实时数仓和物化视图的实现提供了基础。

物化视图日志 (MLOG)：这是实现增量刷新和实时物化视图的核心。当基表发生 DML 操作时，变更的增量信息会被同步记录到 MLOG 中。刷新时，系统只需读取 MLOG 即可获取变更数据，避免了对整个基表的扫描。

OceanBase 物化视图的典型场景及案例

典型场景

实时数据分析

对于需要实时洞察业务动态的场景，如实时监控大屏、实时推荐、实时风控等，OceanBase 的实时物化视图能够提供强有力的支持。通过结合 Flink CDC 等实时数据同步工具，可以构建端到端的实时数仓，而实时物化视图则作为查询加速层，确保在数据持续流入的同时，分析查询依然能够获得极低的延迟。

复杂查询性能优化

在许多 OLTP（在线事务处理）和 HTAP（混合事务/分析处理）系统中，存在一些消耗大量资源的“慢查询”，这些查询往往涉及多张大表的连接和复杂的聚合计算。通过为这些特定查询创建物化视图，可以将其计算成本从每次查询时发生，转移到后台的刷新任务中，从而有效降低在线业务高峰期的系统负载，保障核心业务的稳定性。

相关案例

电商大促价格计算：多表 Join 加工宽表，支撑近实时分析

业务问题：多源商品关系数据需要预加工为分析宽表

在电商大促期间，运营人员需要将商品基础信息、商品销售属性、促销活动商品等多维数据整合为统一宽表，用于运营分析与决策查询。上游数据同步进入 OceanBase 后，如果每次分析查询时再做多表 join，会带来较高计算开销和不稳定延迟。

因此，优化目标是在库内完成多表数据加工，沉淀可复用的加工明细宽表，供下游 AP 查询分析，如运营分析、数据服务等，直接消费。

典型模型为四表 join，即：活动商品池表 + 商品基础信息表 + 商品销售属性表 + 商家店铺表，通过 inner join 生成加工结果宽表。

技术挑战：Join 成本高 + 变更模式不均匀

该场景的难点不只是表规模，而是变更分布极不均匀，对实时 join 和全量重算都不友好。

测试数据特征如下：

竞品基础信息表：全量约 40 万（预期可到 180 万）；高峰单次增量 10–15 万（新品/状态变更）；
商品销售属性表：全量约 44 万，高峰单次增量 2–3 千；
活动商品池表：日常全量仅约 1 千，但存在单次 400–500 万级集中变更；
加工结果宽表（物化视图）：约 50–100 万级。

这种模式下：

查询时 join → 成本高且波动大；
批量变更触发全量重算 → 代价不可控；
下游分析查询与加工计算争抢资源。

方案：使用 OceanBase 物化视图做增量 Join 加工

解决方案是在 OceanBase 内定义物化视图（MV），将多表 join 的加工逻辑固化为数据库内持续维护的结果集。

实现方式：

基于四张源表定义 join 型 MV，生成加工宽表；
下游查询直接访问 MV，不再执行多表 join；
采用增量刷新模式：REFRESH FAST ON DEMAND；
基于基表变更日志，仅对受影响数据做增量重算。

这样将“查询时 join”转换为“写入后增量维护”。

效果：增量刷新可控，宽表近实时可用

基于测试环境数据：

增量刷新周期：每 5 分钟一次；
非高峰期刷新耗时：1 分钟以内；
全量刷新耗时：约 20 分钟（用于追位或重建）。

MV 宽表规模稳定在 50–100 万行，在大批量集中变更场景下，增量刷新仍可维持可控窗口，避免频繁全量重算。

该方案的核心收益集中在三个方面：

将多表 join 的高成本计算前移为库内增量维护；
适配“大批量突发变更 + 多表关联”的数据模式；
为大促价格计算分析提供稳定的近实时宽表数据层。

对分析侧来说，查询路径从“多表实时 join”简化为“单宽表查询”，执行代价与延迟稳定性明显改善。

SaaS ERP 报表与分析 — 基于物化视图（MV）的数仓 ETL 简化与性能提升

业务问题：ERP 报表与分析需求

在企业资源计划（ERP）系统中，报表与分析对数据口径的稳定性和准确性要求较高。传统的 ETL（提取、转换、加载）流程可能涉及到多个系统或步骤，导致数据的加工过程冗长，效率低下。

在此场景下，需要解决以下问题：

TP 实时入库与基于 MV 的近实时 ETL 加工在同一个 OceanBase 集群中并行运行；
物理隔离：确保这两者的负载不相互干扰，并保证加工结果的稳定性与可持续性；
稳定加工链路：报表与分析查询必须直接消费加工后的数据，避免重复计算和保证查询响应稳定。

技术挑战与方案：物化视图（MV）简化 ETL 分层

为了解决上述挑战，采用了 OceanBase 的物化视图（MV）功能，将数仓 ETL 的不同层次（明细层、主题加工层、报表层）直接固化为物化视图，并通过级联刷新机制保证数据一致性。

上述方案中：

ETL 分层处理：通过 MV 完成从明细层到主题加工层，再到报表层的数据流动。每一层的加工都在数据库内完成，最终结果直接存储在物化视图中。

物理隔离：将 TP 数据写入与 MV 数据容器表的 leader 放置到不同节点上，实现计算和存储的物理隔离。ETL 加工操作仅在 MV 所在节点进行，而数据的增量更新（MLOG）从 TP 节点读取，从而有效减少了负载冲突和资源争抢。

嵌套 MV 和级联刷新：通过自底向上的刷新机制，确保每个层次的数据都能保持一致性，特别适合需要稳定数据口径的分层加工模式。

方案优势：简化架构、加速报表分析

该方案的实施带来了明显的架构和性能优势：

架构简化：通过在 OceanBase 内部使用 MV 承接 ETL 分层加工，避免了外部计算和数据拼接链路的复杂性，减少了中间处理环节，降低了故障点和运维成本。

报表分析加速：高频查询的报表数据从“每次实时重算”变为“读取已经预计算好的 MV 数据”，使得报表查询变得更加高效和稳定，响应时间大幅缩短。

可控的实时性：通过物化视图的增量刷新，报表查询的实时性变得更加可控，避免了因复杂计算而导致的查询延迟。

性能与效果：稳定的 ETL 和报表查询性能

实施该方案后，OceanBase 系统的 ETL 加工和报表查询性能得到了显著提升，特别是在高频报表查询场景下，具体效果如下：

报表查询响应加速：查询不再依赖实时计算，而是直接读取加工后的 MV 数据，显著提高了查询的稳定性和响应速度。

ETL 加工稳定性：由于采用了物化视图的嵌套与级联刷新，ETL 加工链路中的每个环节都能保持一致性，减少了数据刷新过程中可能出现的错误或不一致。

高频操作的负载隔离：物理隔离机制使得 TP 入库负载与 MV 刷新负载互不干扰，保证了系统的整体性能稳定。

这套方案带来了多方面的技术价值：

提高 ETL 加工效率：通过物化视图将 ETL 流程内的多层次数据预计算并存储，减少了外部计算链路的依赖，提升了数据处理效率。

提升报表查询稳定性：报表查询通过直接访问 MV 中的加工数据，而不再依赖实时计算，减少了系统负担，提高了报表分析的稳定性和效率。

架构简化与运维降低：简化了 ETL 流程和查询路径，减少了复杂度，同时降低了运维成本，避免了多点故障的风险。

总的来说，OceanBase 的物化视图功能通过提供高效的数据加工和稳定的报表查询，帮助用友 ERP 系统实现了数据处理的优化，提升了业务分析的效率与可持续性。

物化视图的使用限制

值得注意的是，尽管物化视图功能强大，但在使用时也需要权衡其带来的成本与限制：

存储开销：物化视图是数据的物理副本，会额外占用存储空间。

维护成本：刷新物化视图会消耗 CPU 和 I/O 资源，需要合理规划刷新策略，避免对在线业务造成影响。

数据一致性：对于非实时物化视图，其数据与基表之间存在一定的延迟，应用需要能够容忍这种数据“过时”。

使用限制：物化视图本身不支持直接的 DML 操作，且基表的 DDL 操作可能会影响物化视图的有效性。

物化视图能力演进计划

为了让用户使用更顺手、更安心，OceanBase 会持续迭代物化视图能力，接下来的版本主要聚焦在以下核心能力：

运维透明化（可观测性）

拒绝“黑盒”运行。上线刷新任务 `Explain` 及全链路可视化监控，提供任务级吞吐、延迟指标及明确的异常诊断报告，确保问题看得清、排得准。

复杂链路支撑（Nested MV）

针对多层级数仓场景，持续优化嵌套物化视图的级联刷新能力，支持构建更深度的 ETL 加工链路。

场景与类型扩展

广泛兼容：逐步支持外表（External Table）的物化能力。
丰富类型：原生支持 JSON、LOB、Geometry 等复杂数据类型的增量计算。

了解更多

在线咨询

优质资料下载

往期推荐

▼点击「阅读原文」，查看技术干货

oceanbase

文章转载自OceanBase，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

一文速通 OceanBase 物化视图能力！

评论