Iceberg 为大规模数据分析提供了统一开放的表格式，让不同计算引擎能够共享同一份数据并协同工作。
但随着数据规模持续增长，查询加速面临新的挑战。虽然 StarRocks 可以借助物化视图（Materialized View，MV）显著提升 Iceberg 查询性能，但物化视图的刷新成本也会随数据量增长不断攀升。当表规模达到 TB 甚至 PB 级别时，刷新过程往往会成为新的性能瓶颈。
为了解决这一问题，StarRocks 4.1 推出了 Iceberg 增量物化视图（Incremental Materialized View）。与传统全量刷新方式不同，增量物化视图只需处理新增或变更的数据，无需重复扫描和计算全部历史数据，即可持续发挥查询加速效果。
当刷新成为瓶颈
传统物化视图主要采用全量刷新或基于分区的刷新机制，两者都将“分区”视为数据变更和刷新的基本单位。但在大规模 Iceberg 场景下，这种方式会逐渐暴露出一些问题：
-
全量刷新成本高。 每次刷新都需要重新扫描和计算全部历史数据，而不仅仅是新增数据。
-
分区刷新存在资源浪费。 即使只有少量数据发生变化，也可能触发整个分区的重新计算。
-
刷新频率难以维持。 当数据规模增长到 TB 甚至 PB 级别后，刷新耗时持续增加，刷新周期也不得不随之拉长。
-
数据新鲜度下降。 虽然查询仍然很快，但物化视图与源表之间的延迟会不断累积，查询结果无法及时反映最新数据。
归根结底，传统刷新机制的成本与数据规模紧密相关。数据越多，刷新耗时越长；刷新耗时越长，物化视图就越难保持最新状态。当刷新速度跟不上数据增长时，物化视图带来的查询加速收益也会随之下降。
从基于分区刷新到基于变更刷新
增量物化视图的核心思路很简单：刷新成本应该与数据变更量相关，而不是与历史数据规模相关。
传统刷新机制以分区作为计算单位。无论分区内实际发生了多少数据变更，系统都需要重新计算整个分区，包括其中未发生变化的数据，因此刷新成本会随着表规模增长而增加。
增量刷新则采用了完全不同的思路。它不再以分区作为计算单位，而是基于 Iceberg 的版本范围识别数据变更，并仅对新增或变更的数据进行计算。
换句话说，刷新成本不再取决于表中存储了多少历史数据，而是取决于本次实际发生了多少数据变更。
增量刷新如何实现
在 StarRocks 4.1 中，增量物化视图并非通过外部调度实现，而是作为查询引擎原生的执行能力内置在系统中。整个刷新过程主要包含三个步骤：
-
变更识别。 系统会记录基表上一次刷新的版本信息，并通过对比 Iceberg Snapshot 范围识别本次新增的数据。
-
增量计划生成。 优化器根据变更范围生成最小化的增量执行计划，仅重新计算受影响的数据和算子，包括相关的 Join 路径。
-
事务集成。 物化视图刷新与基表更新在同一事务边界内完成，保证原子可见性和一致性。
当增量计算不适用时，AUTO 模式会自动回退到基于分区的刷新方式，无需人工干预，也不会影响正常查询。
这种架构让物化视图刷新从传统的周期性批处理任务，转变为面向数据变更的持续增量执行。
需要注意的是，目前增量刷新仅支持 Iceberg Append-only 表。如果基表执行了 UPDATE、MERGE、OVERWRITE 等操作，配置为
refresh_mode = INCREMENTAL的物化视图将无法继续刷新。对于这类场景，建议使用传统的分区刷新模式。
Iceberg 场景性能测试
我们在 100 GB Iceberg SSB 数据集上，对增量物化视图与传统分区刷新进行了对比测试，覆盖单表聚合、多表 Join 和 Join + 聚合三类典型分析场景。
每个场景均连续执行三轮刷新。首轮完成物化视图基线构建，后续刷新用于观察增量刷新进入稳定运行阶段后的性能表现。
刷新性能对比
三类场景的测试结果呈现出一致的趋势：首次构建阶段，由于都需要完成完整的数据计算，增量刷新与分区刷新耗时接近；而在后续刷新阶段，增量刷新仅处理变更数据， 刷新时间可缩短一个数量级甚至更多。
其中，多表 Join 场景的收益最为明显，因为系统仅需重新计算受影响的 Join 路径。
即使底层表持续增长，刷新延迟依然能够保持稳定，物化视图的查询加速能力也能够持续发挥作用，而不会随着数据规模增长逐渐减弱。
从定期重算到增量刷新
过去，物化视图往往让团队在查询性能和数据新鲜度之间做取舍：要么承担频繁刷新的高昂成本，要么接受存在延迟的查询结果。
增量物化视图通过将刷新范围限定在新增和变更数据上，让刷新成本与数据变化量保持一致，而不再与历史数据规模直接相关。
这使得物化视图能够随着新数据持续同步更新，在保证数据新鲜度的同时持续发挥查询加速作用，而无需反复对 Iceberg 大表进行全量重算。
对于 Lakehouse 而言，这意味着既保留了 Iceberg 的开放性和跨引擎互操作性，又获得了更接近传统数仓的体验：可预测的性能、低延迟查询，以及始终保持最新的数据。
快速开始
在 StarRocks 4.1 中，可以通过在创建物化视图时设置 refresh_mode 属性，为 Iceberg 物化视图开启增量刷新：
CREATE MATERIALIZED VIEW test_mv1
PARTITION BY dt
REFRESH DEFERRED MANUAL
PROPERTIES (
"refresh_mode" = "INCREMENTAL"
)
AS SELECT ...
FROM iceberg_catalog.iceberg_test_db.t1
JOIN iceberg_catalog.iceberg_test_db.t2 ON t1.dt = t2.dt
...
GROUP BY t1.dt, t1.col1, t2.col1, ...;