考察点
考察对 Doris 预聚合体系的理解：同步 Rollup 和异步物化视图（2.1 之后的能力）是两套机制，混为一谈会直接露怯。面试官想看你能说清 Rollup 的前缀索引命中规则、异步 MV 的刷新策略和透明改写，追问常考「查询怎么路由到 Rollup」和「基表更新后视图怎么保持一致」。
参考答案
Rollup：跟着基表走的预聚合
Rollup 是 Doris 里历史最久的预聚合手段。建表后在基表上 ALTER TABLE ADD ROLLUP，指定一个维度子集和聚合方式，Doris 会为这个 rollup 单独存一份物理数据。写入时同一条数据同时写进基表和所有 rollup，强一致、同步可见，这是它和异步视图最大的区别——业务方永远不用担心「基表和聚合表对不上」。
Rollup 数据按自己定义的列序排序，存储量通常远小于基表（维度少了、行被聚合掉了）。查询时优化器自动选择能覆盖查询所需列、且扫描行数最少的 rollup，SQL 不用改。比如基表是（dt, city, channel, sku, pv, uv），rollup 建成（dt, city, pv_sum, uv_sum），按城市粒度的查询自动走 rollup，扫描量可能只有基表的几十分之一。
前缀索引：Rollup 列序的硬约束
Doris 的排序索引是前缀索引：排序键取表定义的前 36 字节左右（变长列截断），查询条件必须从排序键第一列开始连续命中才能用上索引裁剪。这条规则对 rollup 同样生效，所以 rollup 的列顺序不是随便排的——高频过滤字段必须放最前面。同一个维度集合，（city, channel）和（channel, city）两个序对查询的加速效果完全不同。实践中会为不同的查询模式建多个 rollup，列序各不一样，等于手动维护多份「排序索引」。这也是为什么 rollup 不能无限加：每个 rollup 都放大写入和存储，一般一张表控制在个位数。
异步物化视图：2.1 之后的主力
异步 MV 是另一条路线，能力边界宽得多：定义语句是任意 SELECT，可以跨表 join、可以嵌套子查询，结果物化成内部表。刷新策略可选——全量刷新、按分区增量刷新（分区物化，基表某个分区变了只刷对应分区）、手动触发或定时调度。基表更新后视图异步追平，允许短暂的不一致，换来的是写入无负担：基表写入链路完全不感知视图存在。
杀手锏是透明改写：用户还是查基表或原 SQL，优化器判断某个 MV 能回答这个查询（且数据新鲜度满足要求），自动改写路由到 MV。这让预计算对业务完全透明——DBA 发现某类慢查询高频出现，建个 MV 就解决了，不用改任何业务 SQL。这一点和 ClickHouse 物化视图「查询必须指向目标表」形成对比，面试时可以主动提。
两套机制怎么选
判断标准其实很清晰。聚合逻辑就是「同一张表按维度子集上卷」、且要求强一致实时可见——用 Rollup，简单可靠。需要跨表 join 预计算、聚合逻辑复杂、能接受分钟级延迟、或者希望查询侧零改动——用异步 MV。实际生产里两者常并存：Rollup 负责表内高频上卷，异步 MV 负责宽表化（事实表 join 维度表物化成大宽表）和跨主题汇总。
还要注意 Aggregate 模型表和 Rollup 的关系：Aggregate Key 模型本身可以看作「key 列全量的特殊 rollup」，现在更推荐明细模型 + Rollup/MV 的组合，建模更灵活，Aggregate 模型在新项目里用得少了。
工程实践细节
几个容易踩的点：Rollup 数量多会明显拖慢导入（每个 rollup 一份写入），也放大 compaction 压力；异步 MV 的分区物化要求基表是分区表且视图定义里带分区字段，设计时要提前对齐；透明改写受「数据新鲜度」约束，可以配置允许使用过期多久的 MV，在实时性和命中率之间取平衡。排查「为什么没走 MV/Rollup」时，用 EXPLAIN 看命中的 rollup 或改写日志，是日常运维的基本功。
可能的追问
- 查询是怎么选中某个 Rollup 的？—— 优化器按「能否覆盖查询列 + 前缀索引命中情况 + 预估扫描行数」选最优，EXPLAIN 能看到命中的 rollup 名；没命中通常是查询条件跳过了排序前缀。
- 基表高频更新时 Rollup 有什么风险？—— 写入放大加剧，每个 rollup 都要同步更新；Unique 模型基表加多 rollup 时 MoW 的索引维护成本也成倍增长，这种场景应考虑异步 MV。
- 异步 MV 和直接建一张定时跑的汇总表有什么区别？—— 本质一样是预计算，但 MV 有声明式刷新管理、分区级增量、透明改写和血缘追踪，不需要业务改 SQL，也不用自己维护调度逻辑。