DBT中文社区

dazdata

关于DBT
DBT 是一种数据转换工作流，可帮助您完成更多工作，同时产生更高质量的结果。您可以使用 dbt 来模块化和集中分析代码，同时还为数据团队提供软件工程工作流中常见的护栏。在将数据模型安全部署到生产环境之前，通过监控和可见性协作处理数据模型，并对其进行测试和记录。

DBT 针对您的数据平台编译并运行您的分析代码，使您和您的团队能够在指标、见解和业务定义的单一事实来源上进行协作。这种单一事实来源与为数据定义测试的能力相结合，可在逻辑更改时减少错误，并在出现问题时提醒您。

DBT 优化您的工作流程
避免通过事务编写DML和DDL来删除表和管理架构更改。仅使用 SQL 语句或 Python 数据帧编写业务逻辑，返回所需的数据集，dbt 负责select物化.构建可重用或模块化的数据模型，这些数据模型可以在后续工作中引用，而不是从每次分析的原始数据开始。
显著减少查询的运行时间：利用元数据查找要优化的长时间运行的模型，并使用 dbt 易于配置和使用的增量模型。
写干利用宏、挂钩和包管理进行 ER 代码。

DBT 提供更可靠的分析
不再复制和粘贴 SQL，这可能会导致逻辑更改时出错。相反，构建可重用的数据模型，并将其提取到后续模型和分析中。更改一次模型，该更改将传播到其所有依赖项。
发布特定数据模型的规范版本，封装所有复杂的业务逻辑。此模型之上的所有分析都将包含相同的业务逻辑，而无需重新实现它。
使用成熟的源代码管理流程，如分支、拉取请求和代码评审。
在基础数据上快速轻松地编写数据质量测试。许多分析错误是由数据中的边缘情况引起的：测试可帮助分析师查找和处理这些边缘情况。

DBT产品
DBT分为dbt Core或dbt Cloud两个产品。dbt Cloud 是围绕 dbt Core 构建的，但它提供：

基于 Web 的 UI，因此更易于访问
托管环境，因此启动和运行速度更快
差异化功能，例如元数据、应用内作业调度程序、可观测性、与其他工具的集成、集成开发环境（IDE）等。
您可以在 www.getdbt.com 上了解计划和定价。

dbt Cloud
dbt 云是部署 dbt 的最快、最可靠的方法。在一个基于 Web 的 UI 中开发、测试、计划和调查数据模型。详细了解 dbt 云功能，并尝试其中一个 dbt 云快速入门。

dbt Core
dbt Core 是一个开源免费工具，使数据团队能够使用分析工程最佳实践转换数据。您可以在命令行上安装和使用 dbt Core。通过 dbt Core 的快速入门了解详细信息。

DBT的强大功能
作为 dbt 用户，您的主要关注点将是编写反映核心业务逻辑的模型（即选择查询）——无需编写样板代码来创建表和视图，也无需定义模型的执行顺序。相反，dbt 会为您将这些模型转换为仓库中的对象。

特征描述

列表处理样板代码以将查询物化为关系
对于您创建的每个模型，您都可以轻松配置具体化。具体化表示选择查询的构建策略 – 具体化背后的代码是可靠的样板 SQL，它将选择查询包装在语句中以创建新的关系或更新现有关系。阅读有关具体化的更多信息。
使用代码编译器
SQL 文件可以包含 Jinja，一种轻量级模板语言。在 SQL 中使用 Jinja 提供了一种在查询中使用控制结构的方法。例如，语句和循环。它还允许通过共享重复的 SQL。
确定模型执行顺序
通常，在转换数据时，采用分阶段方法是有意义的。DBT 提供了一种通过 ref 函数分阶段实现转换的机制。您可以从其他模型中进行选择，而不是从仓库中的现有表和视图中选择。
记录您的数据库项目
DBT 提供了一种机制来为 dbt 模型编写、版本控制和共享文档。您可以为每个模型和字段编写描述（纯文本或降价）。在 dbt Cloud 中，您可以在 dbt 项目运行时自动生成文档。
测试您的模型
测试提供了一种通过对模型生成的结果进行断言来提高每个模型中 SQL 完整性的方法。
管理包
DBT 附带了一个包管理器，它允许分析师使用和发布 DBT 代码的公共和私有存储库，然后其他人可以引用这些存储库。
加载种子文件
通常在分析中，原始值需要映射到更具可读性的值（例如，将国家/地区代码转换为国家/地区名称）或使用静态或不经常更改的数据进行丰富。这些数据源（称为种子文件）可以作为 CSV 文件保存，并使用命令加载到数据仓库中。
快照数据
通常，数据源中的记录是可变的，因为它们会随时间而变化。如果要重建历史值，在分析中处理可能很难。DBT 提供了一种通过使用快照为某个时间点的原始数据创建快照的机制。

dazdata

概述
物化是在仓库中保留 DBT 模型的策略。dbt 中内置了四种类型的物化。它们是：
表
视图
增量
临时

配置物化
默认情况下，dbt 模型物化为“视图”。通过提供如下所示的配置参数，可以使用不同的具体化来配置模型。materialized
dbt_project.yml

name: my_project
version: 1.0.0
config-version: 2

models:
my_project:
events:
# materialize all models in models/events as tables
+materialized: table
csvs:
# this is redundant, and does not need to be set
+materialized: view
或者，可以直接在模型 sql 文件中配置具体化。如果您还要为特定型号设置 [性能优化] 配置（例如，Redshift 特定配置或 BigQuery 特定配置），这将非常有用。

物化

视图
使用物化时，模型将在每次运行时通过语句重新生成为视图。viewcreate view as

优点：不会存储其他数据，源数据顶部的视图将始终包含最新记录。
缺点：执行重大转换或堆叠在其他视图之上的视图查询速度很慢。
建议：
通常从模型的视图开始，只有在注意到性能问题时才更改为另一个物化。
视图最适合不进行重大转换的模型，例如重命名、重新转换列。

表
使用物化时，您的模型将重建为table表在每次运行时，通过语句。create table as

优点：表查询速度很快
缺点：
表可能需要很长时间才能重建，尤其是对于复杂的转换
基础源数据中的新记录不会自动添加到表中
建议：
将表物化用于 BI 工具查询的任何模型，为最终用户提供更快的体验
还可以将表物化用于许多下游模型使用的任何较慢的转换

增量
incremental模型允许 DBT 自上次运行 DBT 以来将记录插入或更新到表中。

优点：只需转换新记录即可显著缩短构建时间
缺点：增量模型需要额外的配置，并且是 dbt 的高级用法。在此处阅读有关使用增量模型的更多信息。
建议：
增量模型最适合事件样式数据
当您变得太慢时，使用增量模型（即不要从增量模型开始）dbt run

临时
ephemeral模型不直接内置到数据库中。相反，dbt 会将此模型中的代码作为公共模型插入到依赖模型中表表达。

优点：
您仍然可以编写可重用的逻辑
临时模型可以帮助您保持数据仓库通过减少混乱进行清理（还可以考虑使用自定义架构将模型拆分到多个架构中）。
缺点：
不能直接从此模型中进行选择。
操作（例如，通过不能临时节点调用的宏）dbt run-operationref()
过度使用临时物化也会使查询更难调试。
建议：将临时物化用于：
DAG 早期的非常轻量级转换
仅用于一个或两个下游型号，并且
不需要直接查询

Python 具体化
Python 模型支持两种物化：