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现代数据架构以ELTExtract → Load → Transform为主流先把原始数据整体载入云数据仓库如 BigQuery、Snowflake、Redshift再在仓库内部完成转换。dbtdata 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 SetupDuckDB dbt Core就是 dbt Core 的典型用法且完全免费安装方式简单直接pip install dbt-duckdb一次安装同时获得dbt-core框架与dbt-duckdb适配器见 setup/local_setup.md连接配置以~/.dbt/profiles.yml文本文件形式存在可同时定义dev与prod两个 targettaxi_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 中的注释与实测指引pathDuckDB 数据库文件路径threads并发线程数本地开发建议保持1避免与内存争抢extensions: [parquet]启用 Parquet 扩展以直接读取列式文件memory_limitDuckDB 内存上限内存不足 4GB 的机器建议降到 1GB16GB 内存可提升到 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: tablerequire-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 工程代码在本地用 DuckDBtarget.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 SetupBigQuery 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.mddbt 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课程笔记明确给出了三个理由强迫学习者理解底层机制dbt Core 把 profiles、依赖解析、物化过程全部暴露出来学完 Core 再学 Cloud 会轻松很多dbt Cloud 抽象过多直接上手 Cloud 容易知其然而不知其所以然概念可迁移如果选择 dbt Cloud BigQuery 跟学核心概念分层模型、测试、文档、物化策略同样成立学习成果可以平滑迁移。6.2 两条路径任选其一本模块官方 README04-analytics-engineering/README.md为学习者提供了完全等价的两条路径路径技术栈成本入口本地方案DuckDB dbt Core免费setup/local_setup.md云端方案BigQuery dbt Clouddbt Cloud 免费 Developer 计划 BigQuery 按量计费setup/cloud_setup.md6.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 Core本地DuckDBdbt Cloud云端BigQuery安装/注册pip install dbt-duckdb注册 dbt Cloud使用免费 Developer 计划连接配置手写~/.dbt/profiles.yml上传服务账号 JSONUI 填写 Dataset 与 Location连接验证dbt debug点击 Test Connection日常开发VS Code dbt Power User 扩展网页 Studio IDE构建全部模型dbt buildIDE 中运行 build 任务指定环境运行dbt run --target prod部署环境中的定时 Job文档托管需自行解决dbt docs serve仅限本地平台自动托管其中文档托管与制品备份正是课程笔记强调的 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 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现代数据架构以ELTExtract → Load → Transform为主流先把原始数据整体载入云数据仓库如 BigQuery、Snowflake、Redshift再在仓库内部完成转换。dbtdata 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 SetupDuckDB dbt Core就是 dbt Core 的典型用法且完全免费安装方式简单直接pip install dbt-duckdb一次安装同时获得dbt-core框架与dbt-duckdb适配器见 setup/local_setup.md连接配置以~/.dbt/profiles.yml文本文件形式存在可同时定义dev与prod两个 targettaxi_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 中的注释与实测指引pathDuckDB 数据库文件路径threads并发线程数本地开发建议保持1避免与内存争抢extensions: [parquet]启用 Parquet 扩展以直接读取列式文件memory_limitDuckDB 内存上限内存不足 4GB 的机器建议降到 1GB16GB 内存可提升到 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: tablerequire-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 工程代码在本地用 DuckDBtarget.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 SetupBigQuery 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.mddbt 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课程笔记明确给出了三个理由强迫学习者理解底层机制dbt Core 把 profiles、依赖解析、物化过程全部暴露出来学完 Core 再学 Cloud 会轻松很多dbt Cloud 抽象过多直接上手 Cloud 容易知其然而不知其所以然概念可迁移如果选择 dbt Cloud BigQuery 跟学核心概念分层模型、测试、文档、物化策略同样成立学习成果可以平滑迁移。6.2 两条路径任选其一本模块官方 README04-analytics-engineering/README.md为学习者提供了完全等价的两条路径路径技术栈成本入口本地方案DuckDB dbt Core免费setup/local_setup.md云端方案BigQuery dbt Clouddbt Cloud 免费 Developer 计划 BigQuery 按量计费setup/cloud_setup.md6.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 Core本地DuckDBdbt Cloud云端BigQuery安装/注册pip install dbt-duckdb注册 dbt Cloud使用免费 Developer 计划连接配置手写~/.dbt/profiles.yml上传服务账号 JSONUI 填写 Dataset 与 Location连接验证dbt debug点击 Test Connection日常开发VS Code dbt Power User 扩展网页 Studio IDE构建全部模型dbt buildIDE 中运行 build 任务指定环境运行dbt run --target prod部署环境中的定时 Job文档托管需自行解决dbt docs serve仅限本地平台自动托管其中文档托管与制品备份正是课程笔记强调的 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考