Databend 增量物化视图：基于 Change Tracking 的增量刷新与一致性读取

刷新可以延迟，结果不能过期

物化视图（Materialized View，MV）通过预先计算并持久化高频查询结果，以额外的存储空间换取更低的查询延迟和扫描成本。然而，在生产环境中，真正困难的并不是“保存一份查询结果”，而是在源表持续变化时，同时控制刷新成本、保证结果正确、避免阻塞写入，并让聚合状态、物理布局和数据生命周期能够独立维护。

Databend 新物化视图以独立的只读 FUSE 表保存预计算结果，利用 Change Tracking 识别自上次刷新以来的变化，并通过 Checkpoint 记录已经消费的源表位置。它将“异步维护”和“一致性读取”分开处理：刷新任务可以暂时落后，但读取路径会根据变化类型选择直接读取、合并未物化增量或安全回源。因此，刷新延迟首先影响查询性能，而不会让查询静默返回错误的旧结果。

本文将依次介绍主流物化视图的维护模型、Databend 的核心设计、刷新与一致性读取机制、聚合状态和存储维护方式，以及当前推荐的使用场景。

物化视图的实现模型与设计权衡

物化视图通常需要在两个维度上做出选择：一是何时维护，即随写入同步更新，还是在后台异步刷新；二是如何维护，即只处理发生变化的数据，还是重新执行完整查询。不同产品会组合这些策略。下表比较的是几种常见实现模型，而不是限定某个产品只能采用其中一种方式。

Databend 如何回答四个关键问题

Databend 选择异步维护物化结果，并根据源表的真实变化决定采用增量刷新还是全量重建。为了不把刷新延迟转化为错误结果，查询端再根据物化进度选择 Fresh、Hybrid 或 Live Fallback 路径。

UPDATE

DELETE

Databend 新物化视图的核心模型

Databend 新物化视图不是附着在源表 Block 上的索引，而是一张特殊的只读 FUSE 表，其引擎为

engine = MATERIALIZED_VIEW

从 Aggregating Index 到独立存储

Aggregating Index 属于 Databend 早期的物化视图模型，它类似一个 block 级别的 Projection 索引伴随原表流动，设计意图上与新物化视图都能够减少重复计算，但两者的存储归属、刷新进度和维护方式并不相同。

元数据与事务边界

为了同时描述物化结果、定义查询和源表依赖关系，物化视图在 Meta 中保存三类信息。

TableMeta(mv_id)

MVDefinition(mv_id)

TableMeta

SourceTableMV(source_id, mv_id)

物化视图的创建、替换和删除，会将表元数据、MV 定义以及源表依赖关系放入同一个 Meta 事务。创建物化视图时，系统也会原子启用源表的 Change Tracking，从而避免出现“MV 已经发布，但源表变化尚不可追踪”的中间状态。

从刷新到读取：如何保证结果正确

Databend 将刷新进度、物化数据和读取路径连接成一套完整机制。刷新端通过 Change Tracking 和 Checkpoint 消费源表变化；读取端则比较 MV Checkpoint Snapshot 与源表当前 Snapshot，判断已有结果是否足以直接使用。

Change Tracking 与 Checkpoint：识别并记录变化

Databend 复用 Stream 的 change-table 语义，读取两次消费端点之间发生的变化，而不是为物化视图另建一套 CDC。变化记录包含以下内部列：

change$action

INSERT

DELETE

change$is_update

change$row_id

刷新成功时，物化视图数据和以下 Checkpoint 会在同一个事务中提交：

materialized_view_source_table_seq
materialized_view_source_snapshot_location

原子提交保证系统不会出现“数据已经写入但 Checkpoint 没有推进”，或者“Checkpoint 已经推进但数据尚未写入”的状态。即使某批增量完全被物化视图的

WHERE

刷新策略：根据真实变化选择增量或全量

刷新开始后，系统会锁定物化视图本身，重新加载定义，并固定本轮使用的源 Snapshot。刷新期间产生的后续写入仍然可以提交到更新的 Snapshot，不会被纳入当前批次。最终采用哪种刷新方式，由两个消费端点之间的真实变化决定。

INSERT OVERWRITE

INSERT

INSERT INTO

UPDATE

DELETE

_mv_source_row_id

MERGE

UPDATE

DELETE

INSERT OVERWRITE

MIN

MAX

对于聚合物化视图，纯追加刷新写入的是聚合状态，而不是最终结果。同一个 Group Key 即使暂时分布在多个 Block 中，后续读取仍可通过

sum_merge

count_merge

min_merge

三种读路径：Fresh、Hybrid 与 Live Fallback

读取物化视图时，Binder 会比较 MV Checkpoint Snapshot 与源表当前 Snapshot，并选择以下三种路径之一。

Read fix 是一种查询计划补偿，并不是后台自动刷新。由此可以得到一个重要保证：刷新延迟首先表现为性能差异，而不是结果正确性差异。

聚合状态与独立存储如何持续维护

增量物化不仅要解决“如何写入新增结果”，还要保证不同批次的聚合状态能够正确合并，并控制长期刷新产生的状态行和文件碎片。

Logical Schema 与 Physical Schema

用户查询时看到的逻辑列，不一定等同于物理写入的列。例如，

avg(amount)

avg(amount)

average_amount

sum_state(amount)

count_state(amount)

sum_merge(sum_state) / count_merge(count_state)

当前初步支持的主流聚合包括

sum

min

max

avg

count

approx_count_distinct

avg

sum_state + count_state

_mv_source_row_id

Reaggregate、Compact 与 Recluster

经过多次 append-only 刷新后，同一个 Group Key 可能产生多份状态行。此时结果仍然正确，但 State Merge 的输入数量和文件碎片会持续增加。Databend 会在 compact 或 recluster 写出新 Block 之前，对该 Block 内相同 Group Key 的 Aggregate State 执行 reaggregate。

OPTIMIZE TABLE mv COMPACT

ALTER MATERIALIZED VIEW mv RECLUSTER [FINAL]

对于包含

GROUP BY

_mv_source_row_id

查询改写与完整使用流程

用户既可以直接查询物化视图，也可以继续查询源表。优化器会匹配输出表达式、过滤条件、Group Key、聚合函数、聚合粒度和查询所需列；匹配成功后，源表查询会被改写为物化视图的读取计划。改写后的计划仍会根据数据状态选择 Fresh、Hybrid 或 Live Fallback 路径。

以下示例创建一个按客户汇总已支付订单的物化视图：

CREATE MATERIALIZED VIEW paid_orders_by_customer
    (customer_id, total_amount, order_count, average_amount)
    CLUSTER BY (customer_id)
AS
SELECT
    customer_id,
    sum(amount),
    count(*),
    avg(amount)
FROM orders
WHERE paid
GROUP BY customer_id;

物化视图创建时只发布定义，并不会立即填充数据。第一次刷新之前，直接查询物化视图会走 Live Fallback，因此结果仍然正确，但暂时无法获得物化存储带来的加速。完成首次刷新后，后续纯追加变化可以增量消费；随着增量批次增加，还可以按需整理物理存储。

-- 第一次刷新，建立初始结果
REFRESH MATERIALIZED VIEW paid_orders_by_customer;

-- 后续只有新增订单时，刷新仅消费增量
REFRESH MATERIALIZED VIEW paid_orders_by_customer;

-- 随增量批次增加，按需整理存储
OPTIMIZE TABLE paid_orders_by_customer COMPACT;
ALTER MATERIALIZED VIEW paid_orders_by_customer RECLUSTER FINAL;

使用场景与选型建议

Databend 新物化视图的收益取决于源表的变化模式、定义查询的复杂度，以及刷新和查询对性能与正确性的要求。它更适合变化可以安全增量消费的单表分析场景，而不是现阶段所有持续计算任务的通用替代方案。

推荐使用的场景

• 日志、埋点、事件与事实表。 这类数据通常以

  INSERT
  

  为主，历史记录较少更新或删除，因此可以持续使用低成本的 append-only 增量刷新。随着新数据进入，物化视图只需要处理尚未消费的变化，而不必重复计算整张源表。

• 高频 Group By、指标看板和客户或区域汇总。 对固定维度反复执行聚合的查询，可以利用 Aggregate State 增量合并结果；当查询形态匹配时，优化器还可以透明地将源表查询改写为物化视图读取，从而减少明细数据扫描和重复计算。

• 写入吞吐优先，但不能接受旧结果。 刷新任务异步执行，不需要把物化计算放入源表写入事务；当刷新暂时落后且新增变化可以安全合并时，read fix 会在查询阶段补齐增量。这样既能避免刷新阻塞写入，也不会为了低延迟而返回已过期的结果。

• 源表与查询需要不同物理布局。 当源表的写入方式和下游查询模式不同，物化视图可以使用独立的 Cluster Key、compact 和 recluster 策略。例如，源表可以围绕写入时间组织，而物化结果可以按照客户或业务维度重新布局。

使用前需关注事项

• 定义查询目前聚焦单表 FUSE 场景。 物化视图当前只能基于

  default
  

  Catalog 中的一张持久化 FUSE 表创建，支持简单的

  SELECT ... FROM ... [WHERE ...] [GROUP BY ...]
  

  。多表查询、

  JOIN
  

  、子查询、集合运算、窗口函数和非确定性函数暂不在支持范围内。因此，如果工作负载依赖复杂宽表建模或多表持续聚合，仍需要使用其他转换与编排方式。

• 聚合物化视图对更新和删除存在重建成本。 非聚合物化视图可以借助

  _mv_source_row_id
  

  将

  UPDATE
  

  和

  DELETE
  

  准确投射到物化结果；但对于聚合物化视图，为了优先保证正确性，一旦源表出现

  UPDATE
  

  或

  DELETE
  

  ，当前实现会执行全量重建，尚未支持分区级增量重算。频繁更新或删除的大型聚合表需要特别评估刷新成本。

• 刷新调度仍需显式配置。 当前可以通过 Task 定时执行

  REFRESH MATERIALIZED VIEW
  

  ，自动生成刷新任务属于后续 Databend Cloud 的演进方向。read fix 也不是刷新机制本身：只有 append-only 增量能够走 Hybrid 路径，无法安全补偿时，查询会回到源表执行原始逻辑。

• 增量能力依赖 Change Tracking 的历史连续性。 如果增量刷新或读取补偿所需的历史 Snapshot 已经被清理，系统将无法基于这些历史变化继续增量处理，此时读路径会选择回源。数据保留策略、刷新频率和 Change Tracking 的可用范围需要结合写入速度与查询要求统一规划。

• 物化视图是只读对象。 普通的

  INSERT
  

  、

  UPDATE
  

  和

  DELETE
  

  会被拒绝，用户不能直接修改物化结果；物理存储的整理也受到专用维护操作的限制。这一约束可以保护物化结果与 Checkpoint 之间的一致性，但也意味着它不能被当作普通业务表写入。

增量维护的价值最终取决于正确性

Databend 新物化视图的核心并不只是“把查询结果缓存起来”，而是建立了一条完整的增量计算链路：Change Tracking 识别变化，Checkpoint 记录消费位置，Physical Schema 保存可合并状态，刷新过程以原子事务推进数据与端点，read fix 则在异步维护期间保证一致性读取。

这套机制尤其适合持续写入、以追加为主，并且需要稳定分析结果的单表场景。面对多表依赖、频繁更新或删除，以及需要自动调度的工作负载，数据工程师应评估全量重建成本和后续 Dynamic Table 能力，而不应将当前物化视图视为通用的持续计算引擎。全面理解这些能力，才能判断物化视图究竟是在减少计算，还是把刷新和维护成本转移到了另一个环节。

增量物化视图特性在 Databend 企业版

v1.2.934

后引入和更新。