Data Engineering Zoomcamp 技术解析：dbt Core 与 dbt Cloud 的对比、演进路线与选型指南

Data Engineering Zoomcamp 技术解析：dbt Core 与 dbt Cloud 的对比、演进路线与选型指南

【免费下载链接】data-engineering-zoomcampData Engineering Zoomcamp is a free 9-week course on building production-ready data pipelines. Join the course here 👇🏼项目地址: https://gitcode.com/GitHub_Trending/da/data-engineering-zoomcamp

本文基于 Data Engineering Zoomcamp（数据工程训练营）第四模块《Analytics Engineering》的课程笔记（4_2_1_dbt_core_vs_dbt_cloud.md），系统梳理 dbt 两大产品形态——开源命令行工具 dbt Core 与商业化 SaaS 平台 dbt Cloud——的定位差异、混合使用模式，以及 dbt Fusion 引擎带来的产品演进方向。结合本仓库第四模块真实项目（04-analytics-engineering/）中的taxi_rides_nydbt 工程与两份环境搭建指南，你将掌握 dbt Core / dbt Cloud 各自的能力边界、适配器支持现状，并能够结合自身场景做出本地（DuckDB）或云端（BigQuery）的开发选型决策。

一、dbt 是什么：位于 ELT 之 "T" 的转换层工具

在正式对比 Core 与 Cloud 之前，先明确 dbt 在数据工程链路中的位置。依据本模块开篇笔记（4_1_1_analytics_engineering_basics.md），现代数据架构以ELT（Extract → Load → Transform）为主流：先把原始数据整体载入云数据仓库（如 BigQuery、Snowflake、Redshift），再在仓库内部完成转换。dbt（data build tool）正是落在 ELT 中 "T" 环节的工具——它用 SQL + 工程化实践在数据仓库内运行转换。

dbt 的核心价值在于把软件工程最佳实践带入分析师与数据科学家的工作中：版本控制、测试、文档、模块化。它支撑起了"分析工程师（Analytics Engineer）"这一介于数据工程师与分析师的桥梁角色。本模块的实践项目taxi_rides_ny就是一套完整的 dbt 工程，其中staging → intermediate → marts三层模型结构与 Kimball 维度建模的"厨房（processing）→ 餐厅（presentation）"分层思想一一对应（详见 4_3_1_dbt_project_structure.md）。

而 dbt 本身分为两种产品形态：dbt Core与dbt Cloud，二者构成了本节笔记的核心讨论对象。

二、dbt Core：开源命令行工具

2.1 基本定位

• 诞生时间：2016 年，最初就是一个完全开源的命令行工具；
• 成本：100% 免费，运行在开发者自己的机器上；
• 开放性：全部代码公开在 GitHub 上，任何人都可以 fork、修改、二次开发。

dbt Core 的哲学是"把一切掌控在自己手中"：项目文件、依赖、profiles（数据库连接配置）都是本地的普通文件，开发者通过 CLI 命令驱动整个工作流。

2.2 在本仓库中的落地形态

本仓库第四模块提供了两条环境路径（见 04-analytics-engineering/README.md），其中Local Setup（DuckDB + dbt Core）就是 dbt Core 的典型用法，且完全免费：

• 安装方式简单直接：pip install dbt-duckdb，一次安装同时获得dbt-core框架与dbt-duckdb适配器（见 setup/local_setup.md）；
• 连接配置以~/.dbt/profiles.yml文本文件形式存在，可同时定义dev与prod两个 target：

taxi_rides_ny: target: dev outputs: dev: type: duckdb path: taxi_rides_ny.duckdb schema: dev threads: 1 extensions: - parquet settings: memory_limit: '2GB' preserve_insertion_order: false prod: type: duckdb path: taxi_rides_ny.duckdb schema: prod threads: 1 extensions: - parquet settings: memory_limit: '2GB' preserve_insertion_order: false

配置项说明（依据 setup/local_setup.md 中的注释与实测指引）：

• path：DuckDB 数据库文件路径；
• threads：并发线程数，本地开发建议保持1，避免与内存争抢；
• extensions: [parquet]：启用 Parquet 扩展以直接读取列式文件；
• memory_limit：DuckDB 内存上限，内存不足 4GB 的机器建议降到 '1GB'，16GB+ 内存可提升到 '4GB' 加速构建；
• preserve_insertion_order: false：允许 DuckDB 优化执行计划、提升并行性能。

从源码结构看，dbt Core 的所有行为都围绕 dbt_project.yml 展开——profile字段必须与profiles.yml中的顶层名称严格匹配（此处均为taxi_rides_ny），这也是 dbt Core 用户最容易踩坑的地方。

2.3 dbt Core 的工程配置证据

04-analytics-engineering/taxi_rides_ny/dbt_project.yml 展示了 dbt Core 工程的关键声明：

require-dbt-version: [">=1.7.0", "<3.0.0"] models: taxi_rides_ny: staging: +materialized: view intermediate: +materialized: table marts: +materialized: table

• require-dbt-version：锁定 dbt 版本范围以保证可复现性；
• 分层物化策略：staging用 view（轻量、随源数据实时刷新），intermediate与marts用 table（固化中间结果与最终结果）。

值得一提的兼容性细节：项目内的 sources.yml 用 Jinja 条件语法同时兼容本地与云端两种环境：

database: | {%- if target.type == 'bigquery' -%} {{ env_var('GCP_PROJECT_ID', 'please-add-your-gcp-project-id-here') }} {%- else -%} taxi_rides_ny {%- endif -%}

这段配置直接体现了课程笔记中"dbt Core 与 dbt Cloud 被设计为彼此兼容"的论断：同一份 dbt 工程代码，在本地用 DuckDB（target.type == 'duckdb'）跑 dbt Core，或迁移到云端用 BigQuery 跑 dbt Cloud，均无需改动模型逻辑。

三、dbt Cloud：托管型 SaaS 平台

3.1 基本定位

• 诞生时间：dbt Core 问世约两年后（约 2018 年），由 dbt Labs（前身 Fishtown Analytics）推出；
• 形态：付费 SaaS 平台，用户无需自行管理基础设施；
• 替你处理的重活：
  • 托管 dbt 文档站点；
  • 任务编排（Orchestration）与定时调度；
  • 环境搭建与管理；
  • dbt 制品（artifacts，如manifest.json、run_results.json）的备份——这正是Slim CI（仅构建变更部分的 CI）得以实现的基础；
• 协作与安全特性：适合团队/企业使用的权限管理、代码评审、环境隔离等功能。

3.2 在本仓库中的落地形态

本模块另一条环境路径Cloud Setup（BigQuery + dbt Cloud）（见 setup/cloud_setup.md）展示了 dbt Cloud 的核心体验：

• dbt Cloud 提供免费 Developer 计划，足以完成本课程学习；
• 通过网页 IDE 完成项目创建、BigQuery 连接（上传服务账号 JSON 后自动提取 project_id 与认证信息）、仓库管理；
• 连接配置中的Dataset设为dbt_prod后，dbt 会自动按分层生成dbt_prod_staging、dbt_prod_intermediate、dbt_prod_marts数据集，与 dbt_project.yml 中的三层materialized配置一一对应。

3.3 环境模型：dbt Cloud 的关键抽象

依据 setup/cloud_setup.md，dbt Cloud 将运行上下文划分为两类环境：

• Development Environment（开发环境）：个人工作区，使用个人凭据，写入形如dbt_<your_name>的临时 schema，互不影响——对应 dbt Core 本地devtarget 的语义；
• Deployment Environment（部署环境）：生产工作区，使用服务账号凭据，由定时任务驱动，写入dbt_prod_*生产 schema——对应 dbt Core 中--target prod的运行方式。

这种"草稿文件夹 vs 已发布文件夹"的抽象，是 dbt Cloud 把 dbt Core 中profiles.yml多 target 能力产品化、并附加团队协作能力的结果。从仓库证据看，Cloud 端的部署环境与 Core 端 profiles.yml 中prodtarget 的目标完全一致——再次印证两者底层共享同一套 dbt 工程语义。

四、混合使用：Core 与 Cloud 的互补模式

课程笔记指出，现实中两者的典型用法是混合共存（Hybrid Approach）：

• 更偏技术向的用户用 dbt Core（本地开发、完全掌控代码与执行细节）；
• 非技术向用户用 dbt Cloud（网页 IDE、无需关心环境与基础设施）；
• 两者被设计为兼容：开发者可以在本地用 dbt Core 开发模型，生产运行则由 dbt Cloud 定时任务执行；
• 2024 年 10 月，dbt Labs 官方发文阐明两种产品应当并存的思路。

本仓库正是这种混合模式的工程实证：taxi_rides_ny项目（04-analytics-engineering/taxi_rides_ny/）是同一份代码，既可通过 dbt Core + DuckDB 本地运行，也可上传到 dbt Cloud + BigQuery 云端运行；sources.yml 中针对target.type的条件渲染，就是为了让这份工程在两种形态下无缝切换而设计的。

五、dbt Fusion：下一代统一引擎

5.1 引擎重写与核心改进

• 时间点：2025 年 5 月，dbt Labs 宣布基于新引擎Fusion对代码库进行全面重写；
• 关键改进：
  • 编译速度大幅提升：dbt 代码编译最快可达原来的30 倍；
  • 开发者体验更好：能在运行/构建之前捕获大量错误，从而节省时间与计算成本；
• 演进方向：dbt Core 仍会被继续维护，但Fusion 是 Core 与 Cloud 共同的未来方向。

从课程笔记的表述看，Fusion 带来的不仅是速度，更是把"编译期"变成"错误捕获期"的范式转变——这与 dbt Core 中dbt compile命令"零成本提前发现 Jinja 错误"的实践（详见 4_6_1_dbt_commands.md）一脉相承，只是 Fusion 将其内建到了引擎层。

5.2 Fusion 的适配器限制（截至 2026 年初）

Fusion 并非对所有数据库适配器开箱即用：

• 已支持的主流适配器：Snowflake、Databricks、Postgres（及其衍生数据库）、BigQuery、Redshift；
• 明确暂不支持：DuckDB（截至笔记更新时）、以及大量社区维护的适配器；
• 影响：如果你使用的是小众适配器，Fusion 引擎以及最新版本 dbt Cloud 可能无法正常工作；
• 现状：适配器支持正在持续扩展中，最新列表需查阅 dbt 官方文档。

这一限制对本课程的选型产生了直接影响——正因为Fusion 尚未支持 DuckDB，本模块本地路径继续采用 dbt Core + DuckDB 组合，并在 setup/local_setup.md 中特别说明：dbt Labs 官方 VS Code 扩展（基于 Fusion 引擎）要求 Fusion 且不支持 dbt Core，因此本地开发需要改用社区维护的dbt Power User by AltimateAI扩展，它支持包括 DuckDB 在内的所有适配器。

5.3 统一许可证的新愿景

Fusion 时代的核心产品思路是终结 Core 与 Cloud 的二元割裂：

• 不再区分"Core 用户"与"Cloud 用户"，而是让每个人都拥有一份 dbt 许可证（license）；
• 用户可以选择两种工作方式：
  • dbt Cloud IDE（网页端）；
  • VS Code + dbt Labs 官方扩展（本地端）；
• 两种方式底层都由同一个 Fusion 引擎支撑，保证体验与能力一致。

这解释了课程笔记中反复强调的观点：Core 与 Cloud 是"同一套 dbt 语义的两种外壳"，未来将在 Fusion 引擎下走向统一。

六、课程选型建议与学习路线

6.1 为什么本课程选 DuckDB + dbt Core

课程笔记明确给出了三个理由：

1. 强迫学习者理解底层机制：dbt Core 把 profiles、依赖解析、物化过程全部暴露出来，学完 Core 再学 Cloud 会轻松很多；
2. dbt Cloud 抽象过多：直接上手 Cloud 容易"知其然而不知其所以然"；
3. 概念可迁移：如果选择 dbt Cloud + BigQuery 跟学，核心概念（分层模型、测试、文档、物化策略）同样成立，学习成果可以平滑迁移。

6.2 两条路径任选其一

本模块官方 README（04-analytics-engineering/README.md）为学习者提供了完全等价的两条路径：

6.3 核心结论

课程笔记给出的底线结论是：先学哪一个并不重要——尤其作为数据顾问，你大概率会同时接触两者。真正值得投入精力的是两者共享的底层基础：

• dbt 三层模型结构（staging / intermediate / marts，见 4_3_1_dbt_project_structure.md）；
• 核心命令与选择语法（dbt build、--select、--target、state 选择器，见 4_6_1_dbt_commands.md）；
• 测试、文档、宏与包等工程化能力。

七、实操对照：同一份工程在两种形态下的运行方式

为了直观对比 Core 与 Cloud 的差异，这里列出taxi_rides_ny工程在两条路径下的关键操作对照（依据 setup/local_setup.md 与 setup/cloud_setup.md）：

其中"文档托管"与"制品备份"正是课程笔记强调的 dbt Cloud 增值点——在 dbt Core 下，dbt docs generate产出的catalog.json与manifest.json需要自己找地方持久化（例如云存储桶），而 dbt Cloud 将这一切内置化（细节见 4_6_1_dbt_commands.md 中关于dbt docs与 state 选择器的说明）。

八、总结与展望

dbt Core 与 dbt Cloud 的关系可以用一句话概括：同一引擎的两种交付形态。Core 是 2016 年诞生的开源 CLI 工具，代表"完全掌控"；Cloud 是 2018 年前后推出的托管 SaaS，代表"开箱即用"。两者被设计为兼容共存的混合模式，而 2025 年宣布的 Fusion 引擎重写（最高 30 倍编译加速、编译期错误捕获、统一许可证）正在把两者的底层重新统一，同时受限于适配器支持进度（目前不含 DuckDB）仍需持续演进。

对本课程学习者而言，最稳妥的路径是：先用 DuckDB + dbt Core 打牢基础，再迁移到 dbt Cloud + BigQuery 体会托管平台的效率——无论未来 Fusion 如何演进，dbt 的分层建模、测试驱动、文档即代码等核心方法论都不会过时。

本文事实依据来源于本仓库第四模块课程笔记与 setup/local_setup.md、setup/cloud_setup.md、taxi_rides_ny/dbt_project.yml 等真实工程文件。关于 dbt Fusion 的适配器支持与最新产品动态，请以 dbt 官方文档为准（本笔记更新于 2026 年 2 月）。

【免费下载链接】data-engineering-zoomcampData Engineering Zoomcamp is a free 9-week course on building production-ready data pipelines. Join the course here 👇🏼项目地址: https://gitcode.com/GitHub_Trending/da/data-engineering-zoomcamp