前言概要
在现代数据栈中，每个人最终都会问同样的问题：dbt Core 仍然是在数据仓库中转换数据的最佳方式吗？在这篇 dbt Core 评测中，我将拨开炒作的迷雾，审视它哪些地方做得非常出色，哪些地方存在不足，以及哪些人应该（和不应该）将他们的分析工程工作流程建立在它之上。
这是一篇基于在 Snowflake、BigQuery、Databricks 和 Postgres 部署中的实际使用，以及在团队从少量模型扩展到数千个模型时所观察到的模式的，以解决问题为导向的实用评测。
本评测涵盖的内容
- dbt Core 的优势——以及分析师喜爱它的原因
- dbt Core 在 2025 年面临的挑战（以及常见的陷阱）
- 何时选择 dbt Core，何时选择替代方案或附加组件
在此过程中，我将穿插读者经常搜索的长尾话题：dbt Core vs dbt Cloud、dbt Core 功能、定价影响、治理、测试、性能调优和迁移指南。
快速入门：什么是 dbt Core——以及不是什么
dbt Core 是一个开源框架，允许你使用 SQL 和少量的 Jinja 在数据仓库中转换数据。 你可以将模型编写为 SELECT 语句；dbt 将它们编译为特定于数据库的 SQL，使用 DAG 管理依赖关系，并处理物化（表、视图、增量）。 它还内置了测试、文档、宏和环境感知配置。
dbt Core 不是：编排器、调度器、元数据目录或 GUI 优先的 ELT 平台。 它是为版本控制、对分析师友好、类似软件的工作流程而设计的转换层。
为什么 dbt Core 赢得分析师的青睐
1) SQL 优先，软件原生的工作流程
- 像对待代码一样对待转换：版本控制、代码审查、CI 检查。
- 宏和包（例如，dbt-utils）解锁可重用的、团队范围的模式。
2) 强大的测试和文档
- 自动生成的文档（带有血缘关系）有助于回答“什么驱动了这个仪表板？”。
3) 可跨数据仓库移植
- BigQuery、Snowflake、Redshift、Postgres、Databricks 等。
4) 清晰的依赖关系图和血缘关系
- DAG 支持部分构建、Slim CI 和有针对性的重新运行。
5) 充满活力的社区和生态系统
dbt Core 显现出不足之处
在这篇 dbt Core 评测中，重要的是要突出成熟团队遇到的权衡。
1) 编排蔓延
- dbt Core 不进行调度。 你需要将其连接到 Airflow、Dagster、Prefect 或你的数据仓库调度器。 这很灵活，但需要更多的活动部件。
- 随着管道规模的扩大，应急响应的复杂性也会增加；数据平台和分析工程团队之间的所有权可能会变得模糊。
2) Python 是可能的，但有既定观点
- dbt Core 中存在 Python 模型，但 SQL 优先仍然是重心。
- 与以 Spark 为中心的统一框架相比，混合 SQL/Python 管道可能会感觉不均衡。
3) 大规模的 CI/CD 性能
- 如果没有仔细的状态管理和构建分区，具有数千个模型的大型存储库可能会使 Slim CI 变慢。
- 测试套件可能会膨胀，除非你对其进行分类和隔离，否则端到端检查的速度会很慢。
4) 开箱即用的治理缺陷
- 列级血缘关系、PII 标记和策略执行通常需要额外的工具。
- 契约和暴露有所帮助，但许多企业仍然在目录（例如，Alation、Atlan、DataHub）上分层，以实现完整的数据治理。
5) 复杂的增量模型
- 增量物化功能强大，但需要使用代理键、合并策略和回填进行规范。
- 性能调优变得特定于数据仓库——在 Snowflake 上飞速运行的程序可能在 Postgres 上爬行。
dbt Core vs dbt Cloud：有什么不同？
在任何 dbt Core 评测中都会反复出现的问题：你是否应该为 dbt Cloud 付费？
- dbt Core：开源 CLI，随处运行，完全控制。 你自带编排、IDE（例如，VS Code）和 CI。
- dbt Cloud：托管 IDE、作业调度、凭据管理、可观察性和简单的元数据访问。 对于非 CLI 用户和小型团队来说，可以更快地进行入门。
谁应该更喜欢 dbt Core？
- 拥有已建立的编排器 (Airflow/Dagster/Prefect) 和成熟的 DevOps 的团队。
- 对成本敏感的组织或那些需要自定义基础架构/安全性的组织。
- 喜欢本地 IDE 和 Git 原生工作流程的高级用户。
谁应该更喜欢 dbt Cloud？
- 从浏览器 IDE 和简单的调度/警报中获益的利益相关者。
真实世界的设置：一种实用的架构
以下是我们看到的在 2025 年反复为 dbt Core 工作的参考蓝图：
- 数据仓库：Snowflake 或 BigQuery 用于通用分析；Databricks SQL 用于湖仓一体用户；Postgres 用于较小的操作。
- 编排：Dagster 或 Airflow 将 dbt build 作为任务运行；通过状态比较实现 Slim CI。
- 测试：dbt 内置测试 + Great Expectations 或 Soda 的组合，用于扩展验证。
- 可观察性：Elementary 或 OpenLineage/DataHub 用于运行元数据和血缘关系；对模型新鲜度和测试失败发出警报。
- 治理：dbt 中的契约、数据仓库中的策略标记、外部目录用于管理。
- 打包：dbt-utils、dbt-expectations 和特定于数据仓库的性能宏。
性能调优：让 dbt Core 飞起来
性能是在任何全面的 dbt Core 评测中经常提到的痛点。 关键策略：
- 利用针对你的数据仓库量身定制的增量策略（merge、insert_overwrite）。
- 使用 state:modified 仅运行受影响的模型。
- 将繁重的集成测试与快速模式测试分开；每晚运行前者。
- Snowflake：注意过度并发和数据仓库大小的自动挂起/自动恢复设置。
- BigQuery：扫描成本——使用分区过滤器和必需的 WHERE 子句。
- Databricks：Z-Ordering、Delta 优化和避免小文件问题。
- 根据手动调整的版本对宏生成的 SQL 进行基准测试。
可扩展的测试和数据契约
- 从关键维度和事实的模式测试（唯一、非空、可接受的值）开始。
- 在关键边界添加数据质量屏幕（例如，如果使用湖仓一体模式，则从摄取到 bronze → silver 的转换）。
- 在模型描述中记录假设；将暴露链接到依赖于它们的仪表板和模型。
团队工作流程：从单人到企业
由于此 dbt Core 评测涵盖了小型和大型团队，因此以下是按阶段划分的剧本：
- 在本地运行 dbt Core；通过 GitHub Actions 或编排器中的简单 cron 进行调度。
- 引入结构化分支、强制性 PR 审查和 Slim CI。
- 将单体存储库拆分为域或强制执行严格的所有权和命名空间。
- 强制执行 CI 门、质量 SLA 和仪表板新鲜度监控。
成本控制：避免意外账单
- BigQuery：在下游模型中强制使用分区过滤器；审核槽与按需；注意笛卡尔爆炸。
- Snowflake：调整数据仓库的大小；有策略地利用查询加速；停止在小型数据仓库上运行繁重的测试。
- Databricks：压缩小文件；为 SQL 工作负载选择最佳集群模式。
- 常规：按成本层标记模型；将探索性构建重新路由到更便宜的环境。
安全性和合规性考虑因素
- 使用环境变量或带有密钥管理器的 profiles.yml。
- 将生产权限限制为 CI/CD 角色；在生产中为开发人员提供只读权限。
- 使用数据仓库原生标签跟踪 PII 并强制执行屏蔽视图。
- 使用 OpenLineage 或目录平台记录血缘关系和访问权限以进行审核。
dbt Core 的替代方案和补充
一个公正的 dbt Core 评测应该承认相邻的选择：
- 在 ELT 平台中转换：Fivetran Transformations、Matillion、Talend——GUI 优先，较少以 Git 为中心。
- 编排器优先：带有软件定义资产 (SDA) 的 Dagster 可以统一摄取、转换和 ML 流程。
- 以 Notebook 为中心：Databricks 或 Hex 对于数据科学繁重的团队可能更友好；你仍然可以在内部调用 dbt。
- 指标层：dbt Semantic Layer、Transform/MetriQL 或数据仓库原生指标——考虑用于一致的业务逻辑。
dbt Core 何时是理想的选择：
- 具有强大版本控制和测试的以 SQL 为中心的分析工程。
- 你希望跨数据仓库的可移植性和蓬勃发展的开源生态系统。
何时重新考虑：
- Spark 或 Ray 是主干的繁重 Python/ML 管道。
- 在不添加目录/血缘关系层的情况下进行严格的企业治理。
dbt Core vs. Dataform vs. SQLMesh（快速了解）
- Dataform：在以 BigQuery 原生为主的商店中表现出色，具有类似的 SQL 优先理念和浏览器工具；生态系统小于 dbt。
- SQLMesh：强调环境管理、时间旅行和测试范例；对于复杂的回填和强大的 CI 具有吸引力。
- dbt Core：最大的社区、最广泛的数据仓库支持、最多的文档和大量经过实战检验的模式。
常见陷阱（以及如何避免它们）
- 单体模型：将大型查询拆分为可重用的暂存层；让 DAG 完成工作。
- 无界增量加载：定义水印和重新处理窗口；安排定期完全刷新。
- 平等地测试所有内容：优先考虑关键路径模型；将非关键测试降级为每晚进行。
- 不明确的所有权：在 YAML 中添加模型所有者；将警报路由给合适的人员。
- 过度使用宏：首选清晰而不是聪明；像记录公共 API 一样记录宏。
节省时间的工具提示
- 在本地使用带有部分解析的 dbt build，以获得更快的反馈循环。
- 采用 pre-commit hooks 进行 SQL 代码检查和 YAML 模式验证。
- 添加 Elementary 或类似工具以获取有关测试失败和新鲜度的警报。
- 对于 Databricks 用户，首选 Delta 增量 + Z-Ordering 用于大型事实。
顺便说一句：加速日常工作流程
如果你正在评估围绕 dbt Core 的开发人员生产力，值得注意的是，了解代码库和 YAML 约定的 AI 助手可以减少 PR 周期，并帮助更快地编写测试和宏。 可以解释血缘关系差异、建议宏重构或起草模型描述的工具可以缩短新分析工程师的入职时间。
结论：dbt Core 仍然是黄金标准吗？
简而言之：是的——对于数据仓库中以 SQL 为中心的分析工程，dbt Core 在 2025 年仍然是默认选择。 它稳定、被广泛采用且可扩展。 但它不是一个完整的平台。 对于编排、可观察性和治理，你可能会添加补充工具。 对于以 Python 为主或以 ML 为中心的团队，请考虑以 Spark 为主的堆栈或 Dagster 领导的架构是否更适合你的重心。
将 dbt Core 视为转换层中可靠的引擎：开放、可移植、可预测。 成功的团队会将其与有条不紊的工作流程和一小套盟友工具包配对。
可执行的后续步骤
- 试点：从一个重点领域（例如，收入分析）和 20-40 个模型开始。
- 基线质量：在第一天将模式测试添加到每个模型；强制执行 PR 审查。
- CI/CD：使用状态比较设置 Slim CI；记录构建目标和标签。
- 可观察性：尽早添加一个轻量级的血缘关系/警报层（Elementary、OpenLineage 或类似工具）。
- 规模：对繁重的事实进行分区，在合理的情况下采用增量，并按模型跟踪成本。
主要要点
- dbt Core 评测共识：数据仓库中以 SQL 为中心的转换的最佳选择。
- 注意事项：编排蔓延、大规模的 CI 性能、治理缺陷。
- 选择 dbt Cloud 以获得便利；选择 dbt Core 以进行控制。
- 成功来自于将 dbt Core 与良好的实践相结合，而不仅仅是出色的工具。
常见问题解答
Q1：什么是 dbt Core，它与 dbt Cloud 有何不同？
dbt Core 是用于基于 SQL 的转换和测试的开源 CLI 框架。 dbt Cloud 是托管服务，具有 Web IDE、调度和管理功能。
Q2：dbt Core 可以免费用于生产工作负载吗？
是的，dbt Core 是开源且免费的。 你仍然需要为你的数据仓库以及你采用的任何编排、可观察性或目录工具付费。
Q3：我应该在何时选择 dbt Core 而不是 dbt Cloud？
如果你想要最大的控制权、已经拥有编排器并且喜欢本地 IDE，请选择 dbt Core。 选择 dbt Cloud 以获得更快的入门、内置调度和托管环境。
Q4：dbt Core 可以处理 Python 模型和机器学习管道吗？
dbt Core 支持 Python 模型，但它主要针对 SQL 转换进行了优化。 对于 ML 繁重的工作流程，请考虑以 Spark 为主或以 Dagster 为中心的堆栈，并在 SQL 适合的地方调用 dbt。
Q5：如何大规模提高 dbt Core 的性能？
使用带有适当分区的增量模型，利用 Slim CI 和基于状态的构建，并根据每个数据仓库调整物化。 添加可观察性以尽早发现缓慢的模型和成本峰值。
