【Calcite 系列】深入理解 Calcite 的 AggregateStarTableRule

AggregateStarTableRule是 Calcite 里专门服务于星型模型和物化汇总表的一条规则。它会识别Aggregate直接压在StarTableScan之上的形态并尝试用星表对应 lattice 中已有的 aggregate table 来替换原始扫描与聚合。本文结合源码实现分析这条规则如何向 planner 查询可用汇总表、何时可以精确命中、何时还需要再 roll up以及它为什么只在启用了 materialization 时工作。1. 规则要解决什么问题如果查询是SELECTdeptno,SUM(sal)FROMstar_tableGROUPBYdeptno;而系统里已经存在按deptno预汇总过的物化表那么没必要再从最底层事实表重新聚合一次。这条规则的目标就是把Aggregate StarTableScan替换成Scan(aggregate_table)或者Aggregate(roll-up) Scan(finer_grained_aggregate_table)2. 规则入口匹配模式非常直接Aggregate StarTable.StarTableScan并且 aggregate 必须是 simple aggregate。3. 为什么先检查 materializations 开关源码在apply(...)一开始就从 planner context 取CalciteConnectionConfig.createMaterializations()如果没有启用 materialization规则立即退出。原因很明确这条规则的整个存在前提就是“允许使用物化汇总表替换原计划”。4. 它如何找到可用汇总表核心步骤是从StarTableScan拿到对应表向 planner 查询该表对应的RelOptLattice把当前AggregateCall转成Lattice.Measure调用lattice.getAggregate(planner,aggregate.getGroupSet(),measures)查询有没有对应 aggregate table。返回值里包含找到的表以及可能的TileKey。5. 什么是精确命中什么是 roll-up如果返回的汇总表粒度和查询正好一致那就是精确命中规则几乎可以直接替换成汇总表扫描。如果返回的是一个“更细粒度”的 aggregate table也没关系规则仍可能使用它只是需要在其上再做一次 roll-up。这就是源码里区分tileKey null与tileKey.dimensions ! aggregate.getGroupSet()的意义。6. 为什么这条规则很依赖 measure 映射物化表不是随便一个 group by 表都能替代原查询它还必须包含当前查询真正需要的聚合度量。因此源码会先执行lattice.lattice.toMeasures(aggregate.getAggCallList())把AggregateCall转成 lattice 能理解的 measure 列表。只有这些度量在物化表里可满足时替换才成立。7. 这条规则的真正价值它本质上不是一个“逻辑等价变形”规则而是一个“利用已有预计算结果”的替换规则。它的收益通常远大于普通结构优化少扫底表少做大规模 group by直接复用汇总结果。8. 和 AggregateProjectStarTableRule 的关系AggregateStarTableRule只处理最直接的Aggregate - StarTableScan如果中间有Project就要靠AggregateProjectStarTableRule先消化那层投影再复用这条规则的主逻辑。总结AggregateStarTableRule的核心是把用户查询里的聚合需求映射到星表 lattice 中已经存在的 aggregate table 上。它成立的关键条件有三个planner 允许 materialization当前扫描来自StarTableScanlattice 中确实存在满足当前 group set 和 measures 的汇总表。这条规则代表的是 Calcite 在“逻辑优化”之外直接利用预计算物化结果的能力。