告别全量扫描：一个技能包让 AI 掌握增量计算

每次刷新都是一次全量重算你的数据管道里有多少张表是这样工作的每隔一小时把源表全量扫一遍重新算一次聚合覆盖写入目标表。数据量 1TB每次刷新就扫 1TB。数据增量只有 0.1%计算成本却是 100%。这不是个别现象而是批处理 ETL 的常态。更麻烦的是当你想把刷新频率从每小时压缩到每分钟全量重算的代价会让整个链路直接撑不住。两条路都不好走面对这个问题通常有两条路路径一引入流计算引擎。Flink 确实能做到秒级实时但代价是重构整条链路——EventTime、Watermark、Window、状态后端每一个概念都需要重新学习现有的 SQL 资产几乎无法复用。路径二继续忍受批处理的延迟。业务数据昨天的报表永远慢半拍。但其实还有第三条路增量计算——只处理变化的数据用批处理的 SQL 语义实现接近流计算的刷新频率。问题在于增量计算的正确实现并不简单。AI 编程助手知道增量计算的公式但在实际生成代码时往往会在关键细节上出错。这些都正是Incremental Skills要解决的问题我们发现增量计算的核心原理是通用的然而这些知识长期分散在学术论文、系统文档和工程师经验中缺乏系统性的整理。与此同时AI 编程助手正在改变软件开发范式但对增量计算的理解往往停留在理论层面在实际生成代码时容易遗漏关键细节。我们希望借助这套完整的增量计算技能包系统性地呈现增量计算的知识体系让开发者都可以在不迁移数仓的前提下以尽可能少的改动体验到增量计算的收益。核心模型Snapshot 与 Delta增量计算的基础是两个原语Snapshot(V)版本 V 时刻的全量快照Delta(V1, V2)两个版本之间的行级变化每行携带 __weight 列1 表示插入-1 表示删除UPDATE 旧行 -1 新行 1__weight 是增量计算的核心。以聚合为例-- 全量聚合扫全表 SELECT group_key, SUM(value) FROM snapshot GROUP BY group_key -- 增量聚合依赖上次的聚合结果处理增量数据 SELECT group_key, SUM(sum_res) FROM ( -- 旧状态每个group key只保留1行 SELECT group_key, sum_res FROM state UNION ALL -- 新插入的增量数据 SELECT group_key, value * __weight FROM insert_delta ) GROUP BY group_key;删除的行 __weight -1乘以 value 后贡献负值自动从累计结果中扣除。这一行代码的差异决定了增量计算是否正确。场景一电商大促实时销售看板业务需求大促期间运营需要每分钟看到各品类的实时销售额和订单量用于动态调整活动策略。原始 SQLSELECT c.category_name, COUNT(o.order_id) AS order_count, SUM(o.amount) AS total_amount FROM orders o JOIN categories c ON o.category_id c.id WHERE o.status paid GROUP BY c.category_name这条 SQL 包含 JOIN GROUP BY增量维护需要分两层处理Layer 1JOIN 层对 orders 和 categories 的 Delta 分别应用 JOIN 的增量规则。例如当orders产生新数据的时候只需要将这部分新数据与categories进行JOIN即可得到当前层的增量结果而无需读取orders的历史数据。Layer 2聚合层对JOIN产生的 Delta 应用 Aggregation 的增量规则。COUNT 和 SUM 都是可撤回的——删除的行通过 __weight -1 自动从累计值中扣除无需重扫历史数据。每次刷新只处理新增/变更的订单行计算量与订单增量成正比。大促高峰期每分钟新增 10 万笔订单只需结合历史聚合结果处理这 10 万行而非全量的数亿行历史订单。场景二商品最低价格订阅业务需求价格监控系统需要实时维护每个商品的历史最低价当最低价发生变化时触发用户订阅通知。原始 SQLSELECT product_id, MIN(price) AS min_price FROM price_history GROUP BY product_idMIN 是不可撤回聚合—— 例如当一条价格记录被删除时如果它恰好是当前最低价你无法通过简单的加减法得到新的最低价必须重新扫描该商品的所有历史价格。增量技能包对此的处理策略是受影响分组重算。每次刷新时先从 Delta 中找出哪些 product_id 发生了变化然后只对这些商品重新执行 MIN(price) 查询。如果一次刷新涉及 500 个商品的价格变动只需重算这 500 个商品而非全量的百万级商品。这与可撤回聚合的处理方式截然不同也是 AI 在没有领域知识支撑时最容易混淆的地方。AI 技能包正确实现的关键现有的AI Agent在增量计算上的失误往往不是不知道而是知道但遗漏了细节。技能包系统性地覆盖了这些细节在此示例一些AI常犯的错误Delta 去重同一行在一个批次内可能出现多次多次更新产生一系列先删后插的数据记录。直接应用未去重的 Delta 会导致 PK 冲突或幽灵行。正确做法GROUP BY 所有列 HAVING SUM(__weight) ! 0。数据清理当Aggregate一个分组的所有行都被删除后状态表中该分组的 accumulated_count 会归零。如果不清理这个空分组会作为幽灵行出现在查询结果中。多层版本传播大部分计算都需要依赖自身的历史状态和输入源的增量数据Layer N1 的 from_version 必须来自自己的 Profile而不是 Layer N 的 Profile。混淆这一点会导致数据重复处理或丢失。空集 NULL 保护SUM() 在无匹配行时返回 NULL后续 NULL 5 NULL。必须用 COALESCE(SUM(...), 0) 保护。诸如此类的陷阱每一个都能让看似正确的增量 SQL 在生产环境中悄悄产生错误数据。安装与使用Incremental Skills 遵循 Agent Skills 规范https://agentskills.io/home支持 Claude Code、Cursor、Kiro、Copilot CLI、Gemini CLI、Codex 等主流 AI 编程助手。安装方式执行npx skills add clickzetta/incremental-skills安装后直接在AI Agent中使用/incremental-computation 将批处理任务 order_summary 转换为增量计算 /incremental-computation REFRESH TABLE order_summaryAI Agent 会加载技能包确认如何获取 Snapshot、Delta、Schema 和版本信息然后按照算法参考生成正确的增量 SQL。相关的内容一并开源整理在了GitHub中 Incremental-Skills包含完整示例感兴趣的朋友欢迎移步查阅。https://github.com/clickzetta/incremental-skills结语Incremental Skills 由云器科技开源Apache 2.0。云器在自研的 ClickZetta Lakehouse 中深度实践增量计算多年并发布了《增量计算技术白皮书》。技能包将这些实践经验系统化以引擎无关的形式开放给社区。如果你的数据管道正在被全量重算拖累或者你想让 AI Agent真正理解增量计算而不只是知道公式不妨试试这个技能包。如果你的场景需要应用于严肃的生产环境并且对数据安全性和时效性有明确要求建议直接使用 ClickZetta Lakehouse——增量计算在其中是引擎原生支持的能力而非依赖 AI 生成的 SQL 拼接。配合 cz-cli 可以在命令行直接管理动态表的增量刷新开箱即用。项目安装地址npx skills add clickzetta/incremental-skills获取cz-cli安装文档请访问https://www.yunqi.tech/documents/setup_cz_cli云器科技官网 - 改变数据的使用方式更多内容欢迎关注「云器科技」官网云器科技-多云及一体化数据平台提供