Recipe：Refreshing Select Partitions

官方来源：examples/recipes/refreshing-select-partitions
核对日期：2026-05-22

这个示例解决什么问题

如何不是每次全量重建预聚合，而是只刷新真正发生变化的时间分区。

官方示例的核心做法

示例在 Orders 的 pre-aggregation 中定义：

granularity: day
partitionGranularity: month
refreshKey.sql 使用 MAX(updated_at)
并结合 FILTER_PARAMS.Orders.createdAt.filter('created_at')

这意味着：

每个月是一个分区；
检查某个分区是否需要刷新时，只看该分区对应时间范围内的 updated_at 最大值。

这说明了什么

1. “数据按 created_at 分区，但按 updated_at 判断新鲜度”是很常见模式

因为很多业务事实表：

属于某一天或某个月；
但会被后续修正、补录或状态更新。

2. 只刷新必要分区，能显著降低运维成本

尤其当数据量大、历史分区多时，这种模式非常重要。

3. Refresh key 的设计本身就是建模能力

不是单纯写个 every: 1 hour 就结束了。

适合迁移的业务场景

订单状态后补更新；
对账结果回写；
广告投放数据回流修正；
财务数据按月归档但会小范围修订。

实战建议

明确“分区字段”和“更新检测字段”是否相同；
用 partition granularity 控制刷新粒度；
避免为大历史表做无意义全量重算；
对刷新策略单独做监控。

和教程哪章搭配最好

一句话总结

这个 recipe 的核心价值是：通过分区化 refresh key，把预聚合刷新从粗暴全量重建，升级为按需、按分区、可运营的更新机制。