DBT模型执行：解决依赖错误问题

在使用DBT构建数据管道时，禁用某些模型可能导致依赖错误。本文针对这一问题，提出了一种巧妙的解决方案：利用DBT选择器和标签实现动态模型执行控制。通过为特定模型添加标签，并在运行时配置选择器排除这些模型，依赖模型仍能引用其已存在的输出，从而将这些模型视为数据源。此方法无需修改`ref`调用，确保了项目的灵活性，避免构建失败。这种策略尤其适用于计算成本高昂、数据更新不频繁但下游模型又需要其最新输出的模型，可以有效地节省资源和时间，提高DBT项目管理效率。

本文探讨了DBT中引用被禁用模型导致错误这一常见问题，并提供了一个利用DBT选择器和标签的强大解决方案，以实现对模型执行的动态控制。通过对特定模型进行标记，并配置选择器在运行时排除它们，依赖模型仍能引用这些已存在的输出，从而有效地将它们视为数据源，无需修改`ref`调用，确保了项目的灵活性并避免了构建失败。

在数据构建工具（DBT）项目中，开发者有时希望在特定运行中跳过某些模型的执行，例如通过在模型配置中设置 enabled=false。然而，当一个被禁用的模型被其他模型通过 {{ ref("model_name") }} 引用时，DBT会抛出错误，因为它无法解析一个指向不存在于当前运行图中的模型的依赖。这种行为限制了项目的灵活性，尤其是在需要动态控制哪些模型应该被构建，而哪些模型仅需作为现有数据源被引用的场景。

问题分析：enabled=false 的局限性

当你在DBT模型中设置 enabled=false 时，DBT会在构建执行图（DAG）时完全排除该模型。这意味着该模型将不会被编译、运行或包含在任何依赖解析中。因此，如果其他模型尝试使用 {{ ref("disabled_model") }} 来引用它，DBT将无法找到 disabled_model 的定义，从而导致编译或运行时错误，因为它认为这是一个无效的依赖引用。

然而，在许多情况下，我们希望被跳过的模型能够像一个已经存在的表一样被对待，即其最新的输出仍然可以被其他模型引用，而无需重新执行其构建逻辑。这正是DBT选择器和标签机制可以提供优雅解决方案的场景。

解决方案：利用DBT选择器和标签

DBT的选择器（Selectors）提供了一种强大的方式来精确控制在 dbt run 或 dbt build 命令中执行哪些模型、测试或快照。结合模型标签（Tags），我们可以实现动态地排除某些模型，同时允许依赖它们的其他模型正常运行，并引用这些被排除模型在上次成功运行后生成的数据。

步骤一：配置模型标签

首先，为那些你希望能够选择性跳过执行的模型添加一个或多个标签。这些标签可以是任意字符串，但建议使用描述性的名称，例如 dont_run、skip_for_daily_run 等。

在你的模型文件中，通过 config 块添加 tags 配置：

-- models/my_project/my_skipped_model.sql
{{
  config({
    "materialized": 'incremental',
    "unique_key": 'id',
    "tags": ["dont_run"], -- 为模型添加 'dont_run' 标签
    "description": "这个模型在大多数运行中会被跳过，但其输出会被引用。"
  })
}}

select
    id,
    name,
    status,
    updated_at
from {{ source('raw_data', 'users') }}
where is_active = true

步骤二：定义选择器

在DBT项目的主目录（与 dbt_project.yml 文件同级）中，创建一个名为 selectors.yml 的文件。在这个文件中，你可以定义一个或多个选择器。我们将定义一个选择器，它将运行项目中的所有模型，但会排除那些带有 dont_run 标签的模型。

# selectors.yml
selectors:
  - name: my_project_with_tags_ignored # 选择器的名称
    description: "运行除标记为 'dont_run' 之外的所有模型"
    definition:
      # 'union' 表示包含所有符合以下条件的节点
      union:
        - method: fqn
          value: "*" # 包含所有完全限定名（FQN）的节点，即项目中的所有模型
        # 'exclude' 表示从上述结果中排除符合以下条件的节点
        - exclude:
            - method: tag
              value: dont_run # 排除所有带有 'dont_run' 标签的节点

这个选择器定义的核心逻辑是：首先选择项目中的所有模型（fqn: "*"），然后从这个集合中排除所有带有 dont_run 标签的模型。

步骤三：执行DBT任务

现在，当你想要执行一个排除特定模型的DBT任务时，可以在 dbt run 命令中使用 --selector 参数，并指定你定义的选择器名称：

dbt run --selector my_project_with_tags_ignored

执行此命令后，DBT将构建并运行所有模型，除了那些被标记为 dont_run 的模型。如果其他模型引用了 my_skipped_model（例如 {{ ref("my_skipped_model") }}），DBT将不会尝试重新构建 my_skipped_model，而是会假定 my_skipped_model 对应的表已经存在于目标数据库中，并允许依赖模型直接引用其现有数据。

当你需要运行包括 dont_run 模型的完整项目时，只需执行标准的 dbt run 命令，或定义另一个不排除这些模型的选择器。

工作原理

使用选择器和标签的方案与 enabled=false 的根本区别在于DBT如何处理依赖关系：

• enabled=false: DBT在解析项目DAG时会完全忽略该模型，导致任何对其的 ref 引用都无法解析，从而引发错误。它从根本上将模型从项目中移除。
• 选择器与标签: DBT在构建项目DAG时会包含所有模型，因此 ref 引用可以成功解析。然而，当执行 dbt run --selector 命令时，选择器会告诉DBT在当前运行中跳过某些模型的 实际构建 过程。这意味着DBT不会为这些被跳过的模型生成SQL并执行它，而是会假设它们在目标数据库中已经存在，并允许依赖它们的其他模型使用这些已存在的表。这就像将它们视为一个外部数据源，但又保留了DBT的依赖管理优势。

注意事项与最佳实践

1. 何时使用: 这种方法特别适用于那些计算成本高昂、数据更新不频繁，但在下游模型中又需要其最新输出的模型。你可以选择性地跳过它们的重新计算，从而节省资源和时间。
2. 与 enabled=false 的对比: 再次强调，enabled=false 适用于你希望永久或长时间从项目中移除某个模型的情况。而选择器和标签则适用于需要动态、灵活地控制模型执行，同时保持依赖关系解析的场景。
3. 灵活性: 你可以根据不同的业务需求或调度策略，创建多个选择器。例如，一个选择器用于每日增量更新，排除某些全量模型；另一个选择器用于每周全量刷新，包含所有模型。
4. 清晰的标签策略: 确保你的标签名称具有描述性，并且在团队内部有明确的约定，以避免混淆。
5. 文档参考: DBT官方文档提供了关于选择器的详细信息和高级用法，强烈建议查阅：DBT Node Selection - YAML Selectors。

总结

通过巧妙地结合DBT的选择器和模型标签，我们可以优雅地解决在DBT中引用被禁用模型所导致的依赖错误。这种方法不仅实现了对模型执行的动态控制，提高了项目的灵活性，还允许下游模型继续利用上一次成功运行的模型输出，而无需修改 ref 调用，从而避免了构建失败，并优化了资源利用。掌握这一技巧，将使你的DBT项目管理更加高效和健壮。

本篇关于《DBT模型执行：解决依赖错误问题》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！