来自官方的一些dbt 最佳实践

限制对原始数据的依赖性

您的项目将取决于存储在数据库中的原始数据。我们建议制作所谓的“基本模型”，以最大限度地减少对原始数据表的依赖性。在此约定中，基本模型可以具有以下职责：

仅选择与当前分析相关的字段以限制复杂性。以后可以随时添加更多字段。
执行任何所需的类型转换。
执行字段别名以将字段名称合理化为项目中使用的标准格式。
充当给定原始数据表的唯一访问点。

在此约定中，所有后续数据模型都建立在基本模型之上而不是原始数据之上 - 仅允许基本模型从原始数据表中进行选择。这可以确保基本模型中的所有转换都将应用于此数据的所有使用，并且如果源数据表移动（或位于不同环境中的不同架构或表中），则可以在单一的地方。

有关基本模型的简单示例，请查看此Quickbooks基本模型。

首先构建视图

在构建新的dbt模型时，默认情况下将这些新模型实现为视图是很常见的。视图部署速度非常快，而且配置选项很少。由于模型行为由配置控制，因此您可以在项目需要发展时更新特定模型的配置，而无需修改模型代码。

要将项目配置为默认视图，您需要将以下内容放入dbt_project.yml：

YAML

models:
  [your-project-name]:
    enabled: true
    materialized: view

管理多个环境

dbt支持target给定项目中的多个s ~/.dbt/profiles.yml。用户可以配置默认值，target并可以使用--target传递给的标志覆盖此设置dbt run。我们建议您将默认设置设置target为开发环境，然后target专门切换到生产环境以部署到生产环境。

使用target管理多个环境，您可以灵活地根据自己的选择设置环境。通常，环境由同一数据库中的模式管理：所有测试模型都部署到调用的模式dbt_[username]，生产模型部署到调用的模式analytics。理想的设置将生产和测试数据库完全分开。无论哪种方式，我们强烈建议维护多个环境并使用管理部署target。

源控制工作流程

我们认为所有dbt项目都应该通过源代码管理来管理。我们使用git进行所有源代码控制，并使用分支和拉取请求来保持主分支成为组织真实的唯一来源。

以交互方式使用dbt

当您的项目变得足够大时，dbt run可能需要一段时间。dbt提供了三种主要方法来解决此问题，以便您可以快速部署对数据库的更改：

在开发过程中尽可能使用视图而不是表。视图通常比表更快地部署，并且在开发过程中，后续分析查询尽可能快地运行通常并不重要。以后可以轻松更改此设置，它不会对您的业务逻辑产生任何影响。
使用dbt_project.yml禁用你没有目前的工作项目的部分。如果给定项目中有多个模块，请关闭当前未处理的模块，以便不会对每个模块进行部署dbt run。
将--models旗帜传递给dbt run。此标志使dbt仅部署您指定的模型及其依赖项。如果您正在处理特定模型，这会在大型项目中的部署时间上产生非常显着的差异。