dbt v2 用 Rust 重写后把万节点项目的解析从 70 秒压到 17 秒；dbt State 先查仓内元数据再决定构建、跳过还是克隆；Lake Compute 把变换直接跑在 Iceberg 上；Datastream 把 MongoDB 写入 BigQuery 的扩展 JSON 默认换成 canonical 模式
本期聚焦四条 9 月 16 日的进展：dbt 在 Summit 上把 Rust 重写的 v2 推到 GA，本地逻辑计划编译器能在写入前算出下游影响面；dbt State 以仓内元数据加模型 SQL 决定构建、跳过、克隆或延迟，官方口径平均省下 15% 到 30% 以上的仓内算力；Lake Compute 用 DuckDB 让 dbt 变换直接作用于 Iceberg 表；Google Cloud Datastream 把 MongoDB 到 BigQuery 新流的默认格式切到 canonical 扩展 JSON。
这四件事分布在构建引擎、编排决策、执行位置与数据格式四处，指向的是同一个方向：把原本只能在运行时靠执行才能知道的判断，前移到一个可以被静态检查、被机器比较、被单独命名的地方。dbt v2 把 SQL 的编译从「发给仓、等仓回话」改成在本地用逻辑计划先算一遍，改一个模型会打断几个下游，在提交前就有数。dbt State 把「要不要重建」从一个由调度器凭时间窗口拍板的决定，改成拿仓内元数据和模型 SQL 比对出来的结论。Lake Compute 则反过来，把执行位置从仓里挪到 Iceberg 表边上，让一个项目里的不同模型可以各自挑引擎。Datastream 改的是最底下一层：MongoDB 的扩展 JSON 有 canonical、relaxed、strict 三种写法，过去默认交给仓去猜类型，现在默认选保留全部类型信息的那一档。前移带来好处，也带走了兜底——本地编译器的判断和仓的真实行为不完全一致，所以要留 baseline 与 strict 两档；类型信息保住了，代价是 canonical 模式比 legacy 的 strict 模式略慢。
dbt v2 GA：Rust 重写落地，本地编译器先算一遍再让仓执行
事件概述
dbt Labs 在拉斯维加斯举行的 dbt Summit 2026（9 月 15 至 18 日）上宣布 dbt v2 正式可用。这是 dbt 的一次完整 Rust 重写，此前以 Fusion 引擎的名义推进，v2 即该引擎转正后的名字。官方给出的解析性能对比是：一个一万个节点的基准项目，dbt 1.12.0 需要 70 秒，v2 需要 17 秒；另一个真实项目中，原本二十分钟的解析降到一分钟以内。
分发方式拆成两条：dbt 是超集，免费使用，dbt State 一类能力作为付费项；dbt-oss 只含 Apache-2.0 许可的部分。原有的 dbt Core v1 继续以 Apache 2.0 维护。适配器方面，BigQuery、Databricks、DuckDB、Redshift、Snowflake 五项随 v2 一起 GA，ClickHouse 与 Spark 处于 beta，Athena、Fabric、Postgres 在开发中。
技术解析
- 本地 SQL 编译器：v2 不再依赖仓返回的信息来理解模型，而是自己在本地基于逻辑计划做静态分析。默认运行在 baseline 模式，另提供可选的 strict 模式。一个直接结果是影响面可以先算：官方文档给出的例子是，修改一处定义会「打断 4 个下游模型」，这类结论无需先跑一遍才能拿到。
- Information Schema 改为 Parquet：dbt 的项目元信息产物从 JSON 换成 Parquet，官方称体积缩小十倍以上，配套
dbt show --info查看。围绕这份元信息重做的 dbt docs 内嵌了 WASM 版 DuckDB，文档站可以在浏览器里直接查项目元数据。 - 产物体积的可控开关：针对元信息写入，v2 提供
--no-write-json、环境变量DBT_ENGINE_WRITE_JSON=0与--write-index三种控制方式，给大体量项目留出裁剪空间。 - 连接与观测：v2 通过 ADBC 走 Arrow 列式协议对接数据源；日志接入 OpenTelemetry。
- 安装与升级：支持 brew、winget 与 curl 三种安装方式，自带
dbt system update完成自升级。 - 新增 checks：v2 引入
checks这一层，与既有的 tests 并列，用于表达不产生数据、只做断言的检查。
行业影响
Rust 重写把 dbt 从「Python 写的项目生成器」变成了「带编译器的构建工具」，竞争维度随之改变。过去衡量一个变换框架，看的是它支持多少种仓、模板写起来顺不顺手；现在多了一条——它能不能在不连仓的情况下，把项目结构和影响面算清楚。这条线一旦成立，编辑器里的实时诊断、CI 里的增量判定、agent 改动代码前的 blast radius 预估，都能搭在上面，这些是 Python 时代做不动的。
对使用者来说，许可证的拆分是更需要注意的地方。dbt 与 dbt-oss 并存意味着「开源版」的边界要重新确认，把 dbt State 这类能力放在付费档，也说明 dbt Labs 选择的商业化落点是省下来的仓内算力，而不是平台席位。同一批公告里还出现了 Fivetran 参与的 Context Layer（私有 beta，含开源的 Agents Schema 规范）、dbt Charts（公开 beta，YAML 定义看板）、dbt Wizard（平台内公开预览，CLI 公开 beta，桌面版私有 beta）以及 Semantic Layer 转 GA，整体路线是在变换之外补齐语义层与 agent 接入面。
相关链接
两个发行版的差异见官方对比页 comparing dbt and dbt-oss，Information Schema 的结构说明在 docs.getdbt.com/docs/build/dbt-information-schema。
dbt State GA 与 Lake Compute：构建决策前移，执行位置下沉
事件概述
与 v2 一并转 GA 的还有 dbt State。它的职责是在每次运行前判断每个模型该走哪条路：构建、跳过、克隆，还是延迟到上游就绪后再说。判断依据有两类——仓内已有的元数据，以及模型自身的 SQL。官方口径是按此决策平均可省下 15% 到 30% 以上的仓内算力。官方给出的两个客户数字是：RxBenefits 的仓成本下降 59%，六十天内复用了七十万次以上的模型、省下两周的查询时间；Virgin Media O2 的作业运行时长与 BigQuery 算力各降约 25%。
同一批公告里的另一项是 Lake Compute，目前处于私有 beta。它是一个基于 DuckDB 的单节点 SQL 引擎，让 dbt 变换直接作用于对象存储上的 Apache Iceberg 表，不必先把数据装载进仓。
技术解析
- 四种处置动作：dbt State 对模型的输出不是「跑或不跑」二选一，而是 build、skip、clone、defer 四选一。clone 走的是零拷贝克隆，defer 用于上游尚未就绪时把引用指到已有的生产对象上，本地开发环境就不必为了跑通一个模型而重建整条链路。
- 新鲜度写成模型级配置：新增的
lag_tolerance是逐模型配置的容差，用来把「这个模型允许多旧」这件事从口头约定变成代码里的一个字段。 - 覆盖面：dbt State 支持 dbt v1.7 到 v2，仓侧覆盖 Snowflake、BigQuery、Databricks 与 Redshift。它属于
dbt发行版中的付费能力。 - Lake Compute 的跨引擎引用：Lake Compute 按模型打标签启用，
ref可以跨引擎工作——同一个项目里，一部分模型跑在 Snowflake 上，另一部分跑在 Lake Compute 上，只要它们访问的是同一批 Iceberg 表，引用关系照常成立。 - 单节点的取舍：DuckDB 是单节点引擎，Lake Compute 不承担需要大规模 shuffle 的重活，它的定位是把「数据已经在 Iceberg 上、变换本身不重」的那一批作业留在湖上。
行业影响
dbt State 触动的是编排层的默认假设。长期以来，「这个模型今天要不要重建」由调度器按时间窗口或文件时间戳决定，粒度粗，且与实际内容无关。改成拿仓内元数据和模型 SQL 比对之后，决策单位和模型对齐了，省下来的算力直接对应账单。这类能力的商业价值很直白，也解释了为什么它会被放进付费档而不是开源版。
Lake Compute 的意义在另一头。它让「仓」不再是执行变换的唯一位置，湖上的 Iceberg 表可以直接承载 dbt 项目的一部分。加上按模型选择引擎的能力，一个项目第一次可以拆成「重的进仓、轻的留在湖上」两半。这里真正难的不是跑通，而是成本核算——省下的仓内算力要和对象存储的请求费用、单节点引擎的时间成本一起算，目前官方没有给出可直接对照的定价口径。
相关链接
ClickHouse 首个伙伴共建的 dbt v2 适配器：随 dbt 二进制分发，走 ADBC 连接
事件概述
ClickHouse 于 9 月 16 日宣布，其 dbt v2 适配器进入公开 beta，并成为第一个由合作伙伴构建、进入 dbt platform 私有 beta 的 v2 适配器。v1 的 dbt-clickhouse 适配器保持 GA 并继续维护，官方称有两千多个团队在使用。v2 适配器目前的完成度是：通过 v1 集成测试套件的 81% 以上，通过其中适用于 Cloud 的测试的 92%；官方明确标注尚不建议用于生产。
技术解析
- 不再需要单独安装包：v2 适配器用 Rust 编写，随 dbt 二进制一起分发，用户不再需要单独安装
dbt-clickhousePython 包，直接用pip install --pre dbt获取。 - 连接协议换成 ADBC：v1 走 Python 驱动，v2 通过 ADBC（Arrow Database Connectivity）连接 ClickHouse，与 v2 整体的列式数据通路一致。
- 测试口径值得单独看：81% 与 92% 是两个不同分母——前者针对 v1 的完整集成套件，后者只统计在 Cloud 环境中适用的那部分。官方把两个数字并列给出，读者需要自己分清基准。
- 平台侧的私有 beta：作为首个伙伴共建适配器进入 dbt platform，私有 beta 覆盖 Studio、环境管理、调度作业与 Catalog 四项。这意味着 ClickHouse 用户可以在 dbt 的平台里完成开发、调度与元数据查看，而不仅是在本地或自有 CI 里跑 CLI。
- v1 与 v2 并行：官方承诺 v1 适配器继续维护，两边会在一段时间内共存，给迁移留出窗口。
行业影响
「适配器随二进制分发」这件事的分量，比一次版本升级大。dbt v1 时代，每家数据源要自己维护一个 Python 适配器包，版本兼容、依赖冲突、升级节奏都由社区各自承担。v2 把适配器收进主分发之后，适配器的数量与质量直接变成 dbt Labs 的交付范围，伙伴的角色从「自己发一个包」变成「向主线上游贡献一个实现」。ClickHouse 作为第一个走通这条路的伙伴，其 81% 的通过率也说明了这条路目前的成熟度——离生产可用还有距离，但路径已经跑通。
对 ClickHouse 一方，换来的不只是省掉一个 Python 包。进入 dbt platform 意味着它的用户群可以直接触达 dbt 的商业用户，这是纯开源适配器拿不到的位置。代价是对 dbt Labs 发版节奏的依赖变高，适配器能力不再由自己独立决定何时上线。
相关链接
Datastream 把 MongoDB 到 BigQuery 的默认格式换成 canonical 扩展 JSON
事件概述
Google Cloud 于 9 月 16 日的发布说明中更新了 Datastream：新建的 MongoDB 到 BigQuery 数据流，写入的 MongoDB 扩展 JSON（Extended JSON）默认采用 canonical 模式。此前默认使用的是 strict 模式。这是一次默认值的变更，已有流的配置不受影响。
技术解析
- 三种模式的区别：MongoDB 扩展 JSON 有 canonical、relaxed 与 strict 三种格式。relaxed 为了可读性牺牲类型信息，会把
{"$numberLong":"50"}写成50、{"$date":{"$numberLong":"..."}}写成 ISO-8601 字符串、{"$numberDouble":"10.5"}写成10.5。canonical 则保留类型标签，例如{"$numberLong":"3567587327"}、{"$numberInt":"42"}、{"$date":{"$numberLong":"1735122600000"}}、{"$binary":{"base64":"...","subType":"00"}}。strict 沿用旧的$date约定写法。 - canonical 能表达 strict 表达不了的值：关键差别在特殊浮点数——Infinity、-Infinity 与 NaN 在 strict 模式下不支持，canonical 支持。区分 32 位与 64 位整数也依赖 canonical 的类型标签。
- 有代价：官方文档写明，canonical 模式的处理速度略慢于 strict 模式，换来的是对全部数据类型的支持。
- 为什么默认值的权重很大：下游 BigQuery 侧的类型映射直接由收到的 JSON 形态决定。relaxed 丢掉类型信息之后，一个 64 位整数和一个普通整数在 JSON 里长得一样，目标端只能靠推断；canonical 让类型随数据一起到达，映射规则是确定的而不是猜的。
行业影响
把默认值从 strict 换成 canonical，是一次典型的「宁可慢一点，也不要猜」的取舍。CDC 链路上的类型问题有个特点：它在同步阶段不报错，而是在下游做聚合、做 join、做时间比较的时候才暴露，排查成本远高于同步本身。Google 选择让新流默认承担少量性能开销，把这些问题的发生位置从下游前移到同步配置，属于把成本挪到更早、更容易发现的地方。
对已有的 MongoDB 到 BigQuery 用户，需要确认自己流的格式模式。默认值变更只作用于新建的流，意味着同一个账号下新旧流会以两种格式写入同一批目标表，若下游有依赖 JSON 文本形态的逻辑，混用会引入不一致。
相关链接
BigQuery 侧的 MongoDB 类型映射表见 docs.cloud.google.com/datastream/docs/bq-map-data-types。
编者评
本期四条里有三条出自同一场会，dbt Summit 2026 单日放出的量超过了过去半年 dbt 的平均节奏，值得单独记一笔：Rust 重写转正、构建决策前移、执行位置下沉，这三件事其实是一条线——dbt 正在把自己从「生成 SQL 然后交给仓」的工具，变成「知道项目全貌、能自己判断该做什么」的构建系统。前两个动作减少了对仓的依赖，第三个动作减少了对仓的位置依赖，方向是一致的。
ClickHouse 那条是这条主线的旁证。适配器收进主分发之后，生态伙伴与 dbt Labs 的关系从并行开发变成上游贡献，这条路的成熟度可以用 81% 这个数字来盯。
本期需要说明两点。一是中文源：阿里云、火山引擎、墨天轮等中文渠道在 9 月 16 至 17 日没有出现产品级的数据基建更新，火山引擎文档侧的更新集中在可观测性与模型版本（Doubao-Seed-2.1-pro 0915），与数据基建无关；阿里云博客无新增。中文源的空窗已连续多期出现，建议后续把中文源的扫描频率降为每周两次，把预算挪到厂商文档站。二是被弃用的线索：Databricks 于 9 月 16 日公布的新加坡三亿五千万美元投资属市场新闻，不计入；RisingWave v3.0.4 与 ClickHouse 的三个补丁版（v26.8.6.5-lts、v26.7.10.6-stable、v26.6.8.7-stable）均为补丁级，无实质内容；The New Stack 上关于 Perplexity 用 agent 构建 CobbleDB 的报道（9 月 16 日）正文无法通过抓取核验，暂不采信，待可核验后再补。