一、需求概述
当前 StarRocks 物化视图仅支持按分区粒度整体刷新，只要分区内存在任意一行数据发生变更，就需要对整个分区数据覆盖重算；
我们业务场景下该机制性能损耗极大、数据时效性难以满足诉求，期望社区能够推出行级增量计算能力：数据变更多少，就仅计算变更部分，无需整分区重载重算。
二、当前机制痛点与业务场景说明
1. 业务场景
核心存储订单业务表，需要留存近360天订单数据；
全周期内历史订单均会产生少量更新（订单状态修改、售后变更、金额微调等），并非仅当日新分区写入数据。
2. 现有分区刷新方案带来的严重问题
-
刷新效率极低、资源大量浪费
只要任意历史分区存在1行数据改动，就会触发对应分区整体重刷；我们业务场景单次数据变更常会牵连200+分区全部覆盖计算，CPU、内存、IO资源无效消耗严重； -
数据时效性无法提升
大批量分区反复全量重载，刷新周期被拉长，没办法实现分钟级、秒级实时数据产出； - 无法适配长周期可更新业务场景
近一年历史数据频繁小幅更新的场景下，分区粒度刷新完全不具备可行性。
三、业界同类产品成熟落地参考
目前主流实时数仓/湖仓产品均已落地行级增量计算方案，可作为技术参考：
- 云器（Lakehouse）：基于 Iceberg 存储格式实现行级增量更新、增量计算；
- Flink：依托 Paimon 湖存储原生支持行级增量读写、增量聚合计算；
从技术底层来看，StarRocks 本身具备成熟完善的**主键索引（Primary Key）**能力，在行数据定位、变更数据检索上具备先天优势，理论上可以实现更优性能的行级增量计算能力。
四、期望特性能力
- 打破分区刷新粒度限制，支持行粒度增量刷新物化视图；
- 仅捕获变更数据（新增、更新）参与上层聚合计算，不变数据直接复用原有计算结果；
- 适配近一年长周期数据频繁小幅更新的业务场景，大幅缩减刷新耗时、降低集群资源开销，提升实时数据时效性；
- 兼容主键表底层存储架构，依托主键索引快速定位变更行。
五、补充诉求
期待社区能够规划该特性迭代路线，若有技术调研、方案讨论我们可以持续跟进，同步一线业务落地痛点与测试反馈。
需要我再精简一版偏口语化的社区闲聊版本，或者加上业务数据耗时对比、优化预期收益吗？