企业官网建设流程全解析

dbt Fusion 引擎（dbt v2）演进全记录：从 2.0.0-preview 变更日志看新一代 dbt 引擎的架构与技术走向

【免费下载链接】dbtdbt enables data analysts and engineers to transform their data using the same practices that software engineers use to build applications.项目地址: https://gitcode.com/GitHub_Trending/db/dbt

导读

本篇文章以 CHANGELOG-fusion.md 为绝对主线，系统梳理 dbt Fusion 引擎（dbt v2 核心）从2.0.0-beta.13到2.0.0-preview.221的完整演进脉络，覆盖破坏性变更、适配器矩阵扩展、dbt State 运行缓存、信息模式（information schema）、docs v2 静态站点、LSP/VS Code 扩展、本地计算（sidecar）等关键能力。读完本文，你将能快速判断每个版本升级时需要注意的配置改动，理解lake_compute、--generate-info-schema、dbt check、dbt system upgrade-distribution等新概念在仓库源码中的落点，并掌握"这份 changelog 应当如何阅读、如何用于排障与升级决策"的完整方法论。

本文事实均来自 CHANGELOG-fusion.md 及当前仓库源码（如 crates/dbt-dist/src/upgrade.rs、crates/dbt-index-core、crates/dbt-adbc 等）中可验证的内容；涉及推测处会明确标注"从源码结构看"。

dbt Fusion Engine 引擎示意图（仓库 assets 目录提供的横向宽幅图，对应本文讨论的 dbt v2 新一代引擎主题）

一、文档定位：这份 changelog 是什么、怎么读

1.1 自动生成机制与阅读约定

文件开头明确了三条阅读规则：

• 内容完整：文件记录了项目（fusion lsp 及整个引擎）的所有变更；
• 按版本归组：每条变更列在其首次出现的（预）发布版本之下，后续版本天然包含先前版本的变更；
• Breaking Changes 需要关注：标注在版本下的"破坏性变更"在升级到该版本时可能需要最终用户或外部维护者采取行动。

同时文档明确说明："Do not edit this file directly"——本文件由 changie 中的 changelog 条目规范。也就是说，这是一份"机器可追溯、人工不可篡改"的发布事实记录，适合作为版本审计与升级风险评估的一手依据。

1.2 版本节奏与仓库源码的对应关系

从时间线看，发布节奏非常密集：

• 2.0.0-beta.13（2025-05-30）起步，beta系列持续到 8 月；
• 2.0.0-preview.1起进入 preview 周期，到2.0.0-preview.221（2026-09-09）仍在持续迭代；
• 每次发布包含 Breaking Changes / Features / Fixes / Under the Hood / Dependencies / Security / Contributors 等分节，方便按角色（终端用户、包维护者、平台集成方、内部 CI）各取所需。

值得注意的命名演化：早期条目中引擎被称为 "fusion"（例如dbt-fusion 2.0.0-preview.4这样的标题），而自 preview.219 起逐步以 "dbt v2" 命名取代 "Fusion" 品牌（对应dbt system upgrade-distribution内部Distribution枚举从Fusion更名为Dbt/Oss/Core）。从源码看，crates/dbt-dist/src/upgrade.rs 中exec_upgrade_distribution正是这一"跨发行版升级"能力的实现入口，且明确区分dbt-core（legacy）、dbt-oss、dbt（Fusion）三种发行版，并为无法判定的安装给出dbt internal get-distribution-info的排查指引。

二、Breaking Changes：升级前必读清单

以下破坏性变更直接决定"升级后项目能否继续运行"，务必逐条核对。

2.1 lake compute 适配器外部改名：lake_compute→lakecompute（preview.221）

这是最新版本中最需要动手的变更：

适配器的外部名现在是lakecompute（无下划线），与其 DbConfig tag 保持一致：需要把profiles.yml、dbt_project.yml、catalogs.yml中的+adapter:/type:从lake_compute更新为lakecompute；lake_compute及更早的替代拼写（alt）都被拒绝。

与之配套的内部演化路径在 changelog 中清晰可见：

• preview.215：外部命名统一为lake_compute（此前叫alt），不再接受alt；
• preview.220：内部标识从alt重命名为lake_compute，并拒绝alt与lakecompute（这一轮恰好是"只认下划线"）；
• preview.221：进一步收敛为lakecompute（只认无下划线）。

也就是说，lake_compute这个拼写本身也只是过渡形态。若你的项目在 preview.215～220 之间配置过 lake compute，升级到 221 时需再改一次。这是典型的"命名收敛分两步走"案例，升级时建议全局检索lake_compute、lakecompute、alt三种写法。

2.2 静态分析（static_analysis）默认值的三阶段演变

从 changelog 看，静态分析经历了明显的默认策略变化：

• preview.120：static_analysis: strict成为on的别名并设为默认，on、unsafe被标记废弃（带警告）；同时引入baseline（语法级检查 + CTE 提取）；
• preview.124～125：将 baseline 模式下"带自省的节点"的 SQL 语法解析失败降级为警告；
• preview.156：baseline 成为默认，除非显式覆盖；
• preview.175：static_analysis on与unsafe值开始报错而非警告。

对终端用户而言，最稳妥的做法是在dbt_project.yml中显式声明static_analysis:取值（strict/baseline/off），不要依赖默认值的跨版本漂移。同时注意 preview.204 的补充：lint/format 的 symbolic 渲染会基于污染值（tainted value）做分支探索，与strict静态分析相互配合。

2.3 其他需要留意的 Breaking Changes

另外 preview.221 中还包含一条 dbt-core 侧的行为变化：v1 遗留的catalogs.ymlspec 将被警告（preview.220 开始），提示向 v2 catalogs 迁移。

三、适配器矩阵：ClickHouse、Exasol、Spark 与跨库能力

Fusion 引擎的适配器工作贯穿整个 changelog，是"dbt enables data analysts to transform data"这一项目定位的直接体现。

3.1 ClickHouse：从 0 到 1 的完整适配

ClickHouse 是 preview 周期中最完整的"从零接入"案例，演进路径包括：

• preview.178：dbt-adapter核心接线（factory、columns、relations、type key、listing 策略），ClickHouseMetadataAdapter、clickhouse_get_relation、profile 交互式配置向导、17 个 record/replay 黄金测试、secure=true（Cloud HTTPS）；
• preview.177～175.1：DbConfig::ClickHouse变体进入 profile 解析（crates/dbt-schemas），dbt init交互式 setup；
• preview.209：Dictionary materialization、更多 settings、index definition；
• preview.208～217：表物化缺失配置补齐、clickhouse_s3source()渲染s3()表函数、契约端到端强制（约束渲染、逐列 codec/ttl、真实列类型）、增量策略（delete+insert / insert_overwrite / microbatch）与 Python 适配器完全一致的解析与校验、on_schema_change（fail / append_new_columns / sync_all_columns）配 codec-aware ALTER；
• preview.221：连接级 settings（profilecustom_settings+ v1 兼容的同步操作默认值）、默认数据库接入 profile schema、SQL 中字面量?不再被当作绑定参数、HTTP User-Agent 中标识为dbt/<version>（可在system.query_log.http_user_agent看到）；单元测试支持；含 ClickHouse 反斜杠转义的多语句 SQL 由 statement splitter 正确切分；table物化兼容 MV（mv_on_schema_change默认 fail、repopulate_from_mvs_on_full_refresh重放 MV 查询），materialized_view支持on_schema_change、原地刷新计划更新（MODIFY REFRESH）带安全过渡错误、多 MV 更新/重命名流与refreshable: false，投影（projection）接受 index 形式并做前置校验。

驱动侧依赖 crates/dbt-adbc（adbc_clickhouse驱动，preview.221 升到 0.1.1），并支持clickhouse.setting.<name>任意连接设置。

3.2 Exasol（Phase 1）与 Spark/Databricks 增强

• preview.217：Exasol 适配器 Phase 1 一次性带来完整宏包——table/view/incremental（append·merge·delete+insert·microbatch）、snapshot（timestamp/check、hard deletes）、模型契约与约束、on_schema_change、grants、persist_docs、catalog 生成、source freshness、跨库工具函数（dateadd/datediff/last_day/hash/bool_or/listagg/safe_cast/equals/split_part），以及distribute_by/partition_by/primary_key配置和交互式dbt init；
• Databricks：streaming table 配置保持（preview.221）、view_update_via_alter下的 full refresh 语义（#14359）、materialized view 查询变更检测（#16123）、get_relation_config按需跳过 tag 查询（#16057）、liquid clustering changeset（#15472）、databricks_tags逐 key 合并（#16070）、Python 模型 managed Iceberg 文件格式修正、column tags 在 snapshot/物化 v1/视图 ALTER 场景下的支持、+catalog作为+database别名、shallow clone 的 clone/table/incremental 物化处理、skip_optimize、row_filter（preview.214）、zorder与unique_tmp_table_suffix（preview.213）、query tags（preview.219）；
• Spark：初始 beta（preview.156）、insert_overwrite增量策略（preview.191）、Python 模型 submission 方法（all_purpose_cluster / serverless / workflow job，preview.94～101）、Spark Connect（preview.175.1）；
• Redshift：datasharing 跨库能力（SHOW TABLES/SHOW COLUMNS FROM TABLE/SHOW SCHEMAS/SHOW GRANTS ON TABLE，preview.175～217）、IAM/Identity Center/access_key 认证、drop_without_cascade、is_serverless等 profile 标志；
• Athena / SQL Server / Postgres / Salesforce：Athena 认证与Backend::Athena（preview.175.1/175），SQL Server backend（preview.126），Salesforce/Postgres 迁移到统一 auth 架构。

从源码结构看，crates/dbt-adapter/src 下的auth.rs、relation/、engine/等模块正是这些适配器共用的垂直化基座；多个版本反复出现"用Relation(AdapterType::X)取代XRelation专属类型"的重构（Postgres/Snowflake/BigQuery/Redshift/Salesforce），说明引擎在把"每适配器一套类型"收敛为"一套类型 + 适配器枚举"。

四、dbt State 运行缓存：复用、克隆与保鲜

"dbt State"（早期叫 Run Cache）是 Fusion 对增量执行的核心投入，几乎每个 preview 版本都有相关条目。可归纳为几条主线：

4.1 缓存决策与节点复用

• preview.204：在依赖 last-modified 预取仍在飞行时推测性提交模型/快照/数据测试，节点不再被完整预取阻塞；
• preview.205：compare_unrendered_code——候选先按 unrendered node hash（dbt_node_state携带）匹配，不一致再回退到编译 SQL hash；可用RUN_CACHE_COMPARE_UNRENDERED_CODE服务默认值和节点级state: compare_unrendered_code:覆盖；同时节点 hash 编码与 Python dbt State 客户端对齐，保证 dbt Core/Fusion 之间同一节点 hash 一致；
• preview.207：allow_clonesprofile target 选项（将clone_chain_depth_limit置 0 来关闭 clone 候选）；
• preview.221：state:modified现在能检测 check 的meta变更；description仍不参与比较（与模型行为一致）。

4.2 克隆与全量刷新语义

• preview.221：allow_clones: false对 seed 生效——seed 在 run-cache 复用时被重建而非跨环境克隆；clone 目标若不是表则先 drop 再 clone；dev 目标残留旧 VIEW 时先 drop 再跑 clone DDL，避免静默回退全量重建；
• preview.204：--full-refresh重建后数据测试不再错误复用；dbt State 会记录增量模型的 full-refresh 执行并刷新缓存表元数据；
• preview.213：RUN_CACHE_API_CLIENT_MAX_ATTEMPTS（默认 3，最大 5）控制瞬时连接错误的重试。

4.3 保鲜（freshness）与元数据预取

• preview.208：Snowflake freshness 元数据预取自适应——小库用一次宽table_schema IN (...)扫描，多 schema 库保留裁剪后的逐 schema 查询，由adaptive_metadata_fetch（默认开启）控制；
• preview.204：配置了 metadata warehouse 时，按 schema 并行（受 threads 约束）抓取 last-modified，替代顺序 dump；
• preview.221：dbt freshness的结果以dbt_rt.freshness发布（原dbt_rt.source_freshness），新增resource_type列区分 source/model；
• 认证侧（preview.213）：CI 等非交互环境下，由可再派生凭证（client credentials 或平台 token 交换）铸成的 token 不再落盘state_auth.json，避免临时 runner 遗留凭证。

4.4 容错语义

preview.204 强调：账户被禁用/锁定时 dbt State 自行禁用并继续，但用户可操作的认证错误仍然致命；state:modified对语义模型/metrics 的误报做了系统修复（manifest round-trip、previous-state metrics 加载、与 dbt-core 对齐 metric 内容比较）。此外 preview.220 引入propagate配置（模型/seed/snapshot 级，项目级用+propagate），声明节点物化后向哪些计算平台发布输出，lake compute 节点在 catalog 不会隐式绑定时强制 Snowflake 绑定。

五、信息模式（information schema）与索引体系

Fusion 把"可查询的元数据"做成了第一等公民，这是区别于经典 dbt 的重要工程创新。

5.1--generate-info-schema与target/info_schema

• preview.219正式引入：写出可查询的 parquet 层target/info_schema/v<n>/，按资源类型一张表，分布在dbt、dbt_rt、dbt_internal三个命名空间，外加生成的views.sql；schema 版本由目录名、dbt.project列和 parquet key-value 共同携带；数据经由target/index/平面索引暂存（已有索引时复用，避免元数据 epoch 重复摄入），否则私有暂存，保证--no-write-index不物化索引；
• preview.221：dbt show --info与--inline直接读项目元数据而非已发布的target/info_schema/工件，不再要求先跑--generate-info-schema；无元数据时报告InfoSchemaUnavailable（dbt1656）并提示可写入的命令；
• 错误码体系（preview.221）：信息 schema 写入失败 →InfoSchemaWriteFailed（dbt1657，当--generate-info-schema失败）；从parse产出的工件缺编译代码/列类型/列级血缘/运行结果 →InfoSchemaIncomplete（dbt1658）；build/run/check上默认索引写入失败 →IndexWriteFailed（dbt1659）。三者均可被warn_error_options定位，此前共享Generic（dbt1000）导致无法定向。

5.2 索引布局与性能

• preview.220：索引与元数据 parquet 默认落到target/private/（原target/index、target/metadata）；--index-dir、--metadata-dir、DBT_INDEX_DIR、DBT_METADATA_DIR仍可覆盖；dbt clean会清理遗留的公开副本；
• preview.216：dbt build/dbt run默认写 parquet 索引到target/index/，不启用 partial parse；--no-write-index退出；
• preview.221：dbt parse --generate-info-schema在 warm parse 上也能写出工件（此前 partial-load 快速路径会在写点之前返回，导致退出 0 但什么都没写）；
• 底层实现：preview.221 提到"dbt-index runner 把渲染后的 dbt 日志行转发给 progress sink，供 Wizard 流式展示 dbt 命令输出"；preview.220 提到索引视图表面统一到 dbt-index-core 单一定义（views.sql、docs/MCP 注册、DuckDB ingest bootstrap 共用一个注册路径，并有跨两个 DuckDB driver 的 DDL 可移植性测试）。

从源码结构看，crates/dbt-index-core 承担了info_schema/、ingest/、epoch_layers.rs、parquet.rs等职责，与 changelog 中"epoch-append parquet"、crack_epochs增量摄取（preview.180 提到 9× 更快的增量 ingest）等条目一一对应。

5.3 parse-time checks 与信息 schema 视图

• preview.217：checks/下的 SQL 文件被解析为节点，parse 后经info_schema()视图对元数据索引执行，失败会阻止dbt build在编译/执行前启动；dbt check按需运行；
• preview.220：parse-time checks 直接查询项目元数据而非由索引构建的视图，索引写失败不再跳过整个 check 门禁；check 视图与信息 schema 一一对应（一个 check 能读的每个视图都是那里同名的一张表），checks也发布到信息 schema，dag_nodes对 checks 可用，原 checks-only 的graph_nodes视图移除（union 各资源类型视图可得同样行）；
• preview.221：raw_code不再提供给 parse-time checks 中无内容的视图（models的 payload 被trim_model_payload剥掉源 SQL；seeds/sources本无 SQL）——防止"过滤空列却自信通过"的误判。

六、docs v2：可静态托管的文档站点

docs 体系在 preview.210 前后完成了一次"去服务器化"改造：

• preview.210：dbt docs generate写出可静态托管的 docs v2 站点——parquet 工件由浏览器端 DuckDB-WASM（运行时从 CDN 加载）查询，无需任何服务器进程；运行dbt compile --write-index或dbt build --write-index先行（列级血缘需加--static-analysis strict），dbt docs generate只导出索引而非重建；dbt docs serve变成纯静态文件托管（原 JSON API 与 analytics relay 一并移除）；站点落到target/index.html，沿用 v1 的target/发布管线无需改动；hash 路由 + 相对资源 URL，任意路径/任意主机可服务；
• preview.212：dbt docs generate现在先编译再导出（内部执行compile --write-index），新项目一条命令即可出站；--no-compile导出上一次--write-index写出的索引（不存在则报错），这也是使用列级血缘的形式；
• preview.203：Dockerfile与docker-compose.yml支持自托管dbt docs serve（见 crates/dbt-docs-server）；
• preview.214：修复 Docker 镜像——从 dbt-core GitHub Releases 下载发布二进制并校验 SHA256SUMS，多阶段、多架构、带健康检查、非特权用户运行（--build-arg DBT_VERSION=可覆盖）。

前端侧（crates/dbt-docs-server/web，517 个前端文件）从 preview.213 起持续进行 OSS 迁移：dbt-dag→ 本地 xyflow/dagre、sourdough Ryecon 图标 → lucide-react、sourdough UI 组件 → radix/shadcn、TanStack Table/Query 等，最终移除@dbt-labs/dbt-dag、@dbt-labs/biga、@dbt-labs/sourdough依赖，实现"白标 + 可独立构建"的开源形态。

七、LSP 与 VS Code 扩展：编辑器内体验

语言服务器是 Fusion 的"开发者日常"入口，相关条目贯穿始终：

• preview.221：dbt lsp可运行在无显式项目目录的编辑器中、忽略不支持的 LSP 通知；LSP 重命名模型会同步更新schema.yml中的模型名；修复了等待文档重解析导致的自饿死死锁（completion/signature help 场景）；
• preview.220：LSP 增加 ref hover 的 parents/children 血缘；VS Code 扩展新增 "Sign in to dbt platform" 命令，仅在功能真正需要平台时才要求登录；新增 dbt-autofix 执行框架（经uvx）；
• preview.214：lsp.formatter.enabled客户端设置控制dbt fmt修复作为信息级诊断上报；.sqlfluff配置在 linter 或 formatter-diagnostics 开启时加载；symbolicjinja_render_mode下 formatter 通过探索污染的{% if %}分支变体合并修复；
• preview.219：无插件 Neovim 集成（客户端渲染 CTE 预览）；dbt fmt经由 LSP 启用（dbt fmt命令本身在 preview.204 增加了--check，preview.212 支持--fix下的规则抑制与源码位置修正）；
• preview.212～221：VS Code 扩展自动安装/更新 Fusion 引擎二进制、Extension Info 一键复制版本信息、原生 Jinja 语法高亮、-- funcsign:签名高亮、查询结果单元格详情面板（含 JSON 美化与查找）、Catalog 面板重构、lineage 默认深度 1（preview.221）。

八、本地计算（sidecar）：DuckDB 上的跨方言翻译

"本地计算"指用 DuckDB 作为 sidecar 执行远程方言 SQL，changelog 中积累了海量翻译条目，可归纳为：

• 机制：--compute sidecar/--compute local/--compute service（preview.118 合并到--compute旗标；preview.209 增加compute: local拼写，支持测试级/项目级与 CLIdbt --compute local）；单元测试可通过+compute覆盖全局（preview.191）；preview.93 完成 sidecar/service 统一；
• BigQuery 函数族（preview.220/214/212/209/199 等）：PARSE_DATE/PARSE_TIMESTAMP、TIMESTAMP_SUB/CURRENT_TIMESTAMP、DATE/DATETIME/DATETIME_TRUNC/TIMESTAMP_TRUNC、JSON_EXTRACT_SCALAR、GENERATE_UUID、FORMAT_DATE、MD5/TO_HEX、UNNEST WITH OFFSET、数组/JSON/正则/窗口表达式、RANGE静态分析、相关标量子查询与 relation 限定列在UNNEST上的保留、timestamp 构造器/算术/差值、FARM_FINGERPRINT、布尔聚合等；
• Snowflake 函数族：LEAD/LAG的 IGNORE NULLS、ARRAY_CONTAINS/ARRAYS_OVERLAP、扩展REGEXP_REPLACE、TO_CHAR(TIME)、EQUAL_NULL、UUID_STRING、LISTAGG排序与 fixture 表达式、OBJECT_AGG/OBJECT_CONSTRUCT_KEEP_NULL/OBJECT_INSERT/OBJECT_DELETE、SEQ1-8、DIV0NULL、MD5_NUMBER_UPPER64/LOWER64、TO_DECIMAL族、try_to_*族、temporal*_from_parts/*_to_*桥接 STRPTIME、array_construct_compact/array_except/array_unique_agg、zeroifnull、sha2、regexp_like、jarowinkler_similarity等；
• 正确性细节：GROUP BY位置序数与整数常量冲突时包装 CAST、QUALIFY窗口表达式保留、UNPIVOT 列别名、UNION [ALL]结构比较、相关子查询的 outer-reference 重写、WHERE中 Jinja 空洞、AS SELECT未加括号的 CREATE VIEW 结构比较等。

这条"翻译管线"与 crates/dbt-adapter/src/engine（15 个文件）及 crates/dbt-adapter/src/record_batch.rs 等模块直接相关——sidecar 需要把远程方言的语义模型化为可在 DuckDB 上执行的等价 SQL。

九、新命令与 CLI 面：check、freshness、login、upgrade

9.1dbt check（parse-time 质量门禁）

• preview.217 引入：checks/目录下的 SQL 解析为节点，parse 后对元数据索引执行，失败阻止dbt build前置阶段；
• preview.220：dbt check <name> --select <subset>可组合——命名选 check、选择器选其报告行；零行结果细分skipped与pass；check 的meta变更可被state:modified感知；
• preview.221：check 结果像测试一样逐条输出（判定、颜色、耗时），违规行以表格展示；dbt check与dbt build的 check 门禁在 check 无法求值（列改名、relation 不存在）时以非零退出。

9.2dbt freshness与模型保鲜

• preview.217：新增dbt freshness命令，同时测量模型与 source；--resource-type/--exclude-resource-type支持（preview.220）；
• preview.221：结果发布为dbt_rt.freshness，带resource_type列；时间戳策略快照的SnapshotTimestampMismatch（dbt1075）误报被修复（仅当hard_deletes为invalidate/new_record时才检查）；dbt sl validate的范围被限定到所选 metric/semantic model/saved query（尊重--select）。

9.3dbt system upgrade-distribution与分发管理

• preview.213 引入：跨发行版升级命令——对全局（pip/pipx/uv tool/system）的 dbt-core 安装，安装dbt（Fusion）并移除旧包；对 standalone/unclaimed 原生二进制就地升级（--to传入安装目录）；managed-project 安装（manifest 声明 dbt-core）当时只检测并打印指引；
• preview.215：支持 managed Python 项目——把 manifest 的dbt-core依赖重写为dbt并重跑包管理器；拒绝 conda 顶层依赖（Fusion 不在 conda 频道发布），pip:子列表可正常升级；--package-manager <name>供非交互/--yes使用；manager 探测不再只依赖运行中二进制自身的安装方式；
• preview.220：支持dbt-oss依赖，两者并存时报错；
• 从源码看，crates/dbt-dist/src/upgrade.rs 即该命令实现，且 crates/dbt-dist 同时承载--version输出分类能力（preview.221 "Expose dbt-dist's --version output classifier"）。

9.4 其他值得关注的新命令

• dbt login（preview.179 起 OAuth 浏览器流 +dbt login status；preview.204 增加 machine-readable--format json --version）；
• dbt completions <shell>（preview.175，bash/zsh/fish/powershell/elvish）；
• dbt run-operation --sql <SQL>（preview.178，免写宏文件直接执行 SQL/Jinja，支持 ref 到 ephemeral 模型，记录在sql_operation.<project>.inline_query）；
• dbt show --query-id <id>（preview.220，取回已完成 dbt-compute 查询的结果，无需重跑）；
• dbt man --schema系列（profile/selector/dbt_cloud/packages/dependencies/catalogs JSON schema 导出）；
• dbt internal get-distribution-info（preview.206，发行版与发布渠道探测）；
• dbt license info（preview.146）；
• dbt state explain（preview.206，默认输出简要决策摘要，--verbose看完整推理树）。

十、Under the Hood：架构级重构脉络

10.1 新 crate 与模块拆分

从 changelog 与仓库结构可以互相印证一批"面向清晰边界"的重构：

• crates/dbt-jinja-ctx：把 load/parse/compile/run 各阶段的 Jinja 上下文从手搓 BTreeMap 迁移为类型化 struct（LoadCtx、ResolveCore、ResolveBaseCtx、ResolveModelCtx、CompileBaseCtx、CompileNodeCtx、RunNodeCtx），行为中性；
• crates/dbt-profile-schemas：profile 连接 schema 抽为轻依赖 crate，由 dbt-init 再导出；
• crates/dbt-tracked-stmt：在飞行语句跟踪抽为独立 crate，任何 ADBC 消费方都能取消运行中查询，并增加 token 级取消清扫；
• dbt-sql-ast（preview.221 引入）：统一 SQL 抽象语法树；
• dbt-db-runner：sidecar 进程，随直接 Unix 安装配套安装并在更新时保留（preview.221 起成为 opt-in companion）；dbt-repl独立成库（preview.177）；
• crates/dbt-index-core：Provider trait 抽象列级血缘/列级影响，DuckDB 实现注入；
• crates/dbt-adbc：driver 管理（driver_manager.rs、driver_channel.rs、install.rs），支撑"同一引擎多 ADBC 驱动"策略（Snowflake/BigQuery/Databricks/ClickHouse/Redshift/Athena/Spark/Postgres/Salesforce/DuckDB 等）。

10.2 Time Machine 重放与一致性

"Time Machine"（record/replay 一致性回归）是保证 Fusion 与 dbt Core 输出一致的关键基础设施，changelog 中的相关修复极具代表性：

• SQL 比较的规范化：mask 时钟/版本派生字面量（dbt_version、run_started_at、etl_batch_id、archival 路径时间戳）、UUID 字面量 canonicalizer 容忍引号间空白、__dbt_tmp后缀归一化、backup relation 标识（_DBT_BACKUP_<timestamp>）canonicalize、Snowflake 临时视图的 compact clock bounds 掩码；
• 调用匹配：get_columns_in_relation按 relation identity 匹配（忽略is_view/is_table等物化派生标志）、只读 execute（SELECT/SHOW）跨 segment 无序匹配、check_schema_exists用调用前证据回答、operation hook 的 fetch 按方法名消费写屏障；
• 版本化模型：显式latest_version的 pointer view 走独立 replay identity（TARGET_UNIQUE_ID）与 content-based matching，避免 dbt1308 失败；
• Mantle 回放偏差登记：Databricks SHALLOW CLONE 继承 PK probe 等 Fusion-only 偏差不再误报SqlMismatch（dbt1405）。

10.3 性能类改进（以 changelog 数据为准）

changelog 中给出的实测数据（引用时注明出处，不夸大）：

• preview.177：SQLite partial-parse 缓存——warm parse 4× 快（440ms vs 1840ms）、--selectwarm compile 11× 快（328ms vs 3700ms，5800 节点项目）；
• preview.180：indexcrack_epochs用 Rust payload 预解码 + flat typed parquet，增量 ingest 9× 快；--write-lineage开销从 +20s 降到 +2.4s（5843 模型）；
• preview.178：Arrow-direct fusion ingest 使冷摄取从 4.5s 降到约 500ms；
• preview.206：package-qualified 宏名解析从线性扫描改 hash 查找，elementary（约 1000 宏）的 on-run-end 从慢 1.6× 到持平；
• preview.177：typecheck 不再 clone Jinja Environment，11k 模型项目峰值 RSS 降约 130MB。

十一、升级与兼容性建议（基于 changelog 的实践要点）

1. 先做dbt clean场景的检查：preview.220 明确记录，snapshot 工件布局变更后，遗留target/目录可能触发 "Not a directory (os error 20)"，新版本write_file已能先清理陈旧文件；升级后若报类似错误，清理target/即可。
2. lake_compute改名一步到位：直接采用lakecompute（preview.221 唯一接受拼写）。
3. 显式声明 static_analysis：默认值经历了 strict→baseline 的切换，dbt_project.yml中显式声明可避免跨版本行为漂移。
4. warn_error_options 现在可用错误名+错误码双通道（preview.177），且信息 schema 类错误（dbt1656～1659）已可定向，建议 CI 中针对性配置。
5. 数据测试的缓存语义变化：缓存命中的测试在run_results.json中报reused而非pass（preview.214），下游成本统计需适配。
6. dbt check可能从"静默通过"变成"失败退出"：这是安全方向的变化，CI 若此前依赖 check 零行即绿色，需检查 check 是否真的可求值。
7. 环境变量前缀收敛：DBT_ENGINE_*已保留；旧的DBT_*别名仍在（preview.203 起DBT_ENGINE_*优先），但未知DBT_ENGINE_*变量会被拒绝，命名时注意。

结语

从2.0.0-beta.13到2.0.0-preview.221，这份 changelog 完整刻画了 dbt v2 引擎的工程形态：以 Rust 重写核心、以 ADBC 统一驱动矩阵、以 parquet 索引与信息 schema 重构元数据、以 DuckDB sidecar 实现本地计算、以 record/replay 保证与 dbt Core 的语义一致性、以 docs v2 静态站点交付文档体验。对升级者而言，本文第二节的 Breaking Changes 清单与第十一节的实践要点是最直接的行动入口；对研究者而言，文中标注的仓库路径（crates/dbt-dist、crates/dbt-index-core、crates/dbt-adapter、crates/dbt-adbc、crates/dbt-docs-server 等）是继续深入源码的第一站。后续版本的演进，仍可随时回到 CHANGELOG-fusion.md 获取一手事实。

【免费下载链接】dbtdbt enables data analysts and engineers to transform their data using the same practices that software engineers use to build applications.项目地址: https://gitcode.com/GitHub_Trending/db/dbt