如果一份报表每小时更新一次，即使原始数据没有变化，背后的几百张表也可能被重新计算一遍。就像每次改菜单上的一道菜，都把整本菜单重新排版印刷。结果没变，时间和钱却照样花了。
dbt State想解决的正是这种浪费。dbt是一种分析工程工具：数据团队用它把SQL变换组织成相互依赖、可以测试的模型，再把仓库里的原始数据加工成报表或机器学习系统能用的表。dbt State会比较当前项目与此前保存的状态，缩小本次需要运行的范围。
本文数字和客户效果均来自dbt官方博客这一处信源，尚无独立验证；其中费用、算力和复用率是三种不同口径，不能互相替代。
先问一句：真的需要重算吗？
传统运行方式更像一台没有记忆的机器。执行一次dbt run或dbt build，它可能再次构建大量没有变化的模型。dbt称，其平台每天观察到约159,000个dbt任务，其中多数按小时运行；这个数字只代表dbt自有平台的观察，不能外推到整个生态。
dbt State给运行过程加上“记忆”。它把系统分成两部分：数据平面负责在数据仓库里执行SQL、生成模型；控制平面负责判断什么值得执行。控制平面保存表的清单，以及上一次数据状态和代码状态的哈希值——哈希值可以理解为状态的数字指纹，并不包含实际业务数据。
每次运行时，它会检查模型是否变化。若发生变化，再看别处是否已有可以复用的版本；只有不能复用时才重新构建。若相同逻辑和数据已存在于staging或production等环境，材料称dbt State可以将其克隆过来，而不必再次计算。
这里还要区分两个容易混淆的概念。增量模型是在一张表内部只处理新增或变化的数据；状态选择则站在整张依赖图上，决定哪些模型需要运行。前者减少表内工作，后者减少整条流水线里被启动的任务。
省下多少，不能只看一个“30%”
据dbt官方博客，dbt State源自此前预览发布的state-aware orchestration（SAO，按状态感知的任务编排）。SAO起初用于production，客户随后希望把相同能力用于staging、持续集成（CI，即代码变更后的自动检查）和development。dbt称，使用SAO的客户可节省30%以上的数据仓库账单。
扩展后的dbt State不再只覆盖生产环境。dbt还称，团队平均减少30%的warehouse compute，也就是数据仓库计算资源；某个客户的model reuse rate最高达到25%，即已有模型被直接复用的比例最高达到这一数值。Fanatics Betting and Gaming是较早启用它的团队之一，博客披露其获得了两位数的计算节省，但现有材料在这里被截断，没有给出完整口径。
这些数字不能合并成“普遍省下30%算力”。账单还可能受价格因素影响，而“最高25%”也不是客户平均水平。博客没有披露样本量、统计周期、仓库厂商、基线或测量方法。
为什么这件事值得关注？
它处理的不只是云账单。一个拥有10,000个模型的项目，若靠人工维护20套选择规则，规则本身也会成为负担。开发者为了验证一个改动，可能要等待100到200个模型运行10到20分钟。状态判断若能可靠缩小范围，就能同时改善成本、反馈速度和规则维护。
它也把“增量边界”说得更清楚：并非只有表内新增数据才值得跳过重复处理，整张模型依赖图也可以先判断影响范围。与此同时，博客提到系统仍会遵守用户设置的freshness SLA——数据新鲜度服务等级约定。这说明是否重建不一定只由代码或数据变化决定，业务对更新时间的要求也可能参与判断。
局限与未知
- 所有效果数据均为dbt自述，缺少样本规模、测量方法和独立验证。
- “每次只构建变化部分”是简化说法；现有材料不足以确认所有适用条件，且freshness SLA可能触发额外构建。
- Fanatics案例的供稿被截断，无法判断其节省发生在哪些任务、持续多久，以及如何计算。