本文探讨了在data build tool (dbt) 中，当一个模型被禁用（`enabled: false`）但仍被其他模型引用时导致的错误。传统的禁用方法会从dag中移除模型，使引用失败。本教程将介绍如何利用dbt的选择器（selectors）和标签（tags）机制，实现更灵活的模型运行策略，允许在特定执行中跳过某些模型的构建，同时确保依赖模型能继续读取这些已存在的数据表，从而有效管理复杂的项目依赖。
理解DBT中禁用模型的挑战
在DBT项目中，我们经常需要控制哪些模型在特定运行时需要构建。一个常见的做法是在模型配置中使用 enabled: false 来禁用某个模型：
{{config(
materialized='incremental',
enabled=false
)}}
SELECT * FROM ...然而，这种方法有一个重要的副作用：当一个模型被设置为 enabled: false 时，DBT会将其完全从项目的有向无环图（DAG）中移除。这意味着，如果其他模型通过 {{ ref("MODEL_NAME") }} 引用了这个被禁用的模型，DBT将在解析依赖关系时抛出错误，因为它无法找到这个“不存在”的模型。
对于那些希望在某些运行中跳过模型构建，但在其他运行中又需要其下游依赖能够访问其已存在数据表的场景，enabled: false 显然不是一个理想的解决方案。它强制我们必须在“运行”或“完全禁用并破坏依赖”之间做出选择。
解决方案：利用DBT选择器和标签
DBT提供了一个强大且灵活的机制——选择器（selectors）和标签（tags），来精确控制哪些模型应该包含在特定的 dbt run 命令中。通过结合使用这两者，我们可以在不修改模型 enabled 状态的情况下，动态地决定哪些模型需要构建，同时允许未被构建的模型作为现有数据表被引用。
核心思路是：
- 给需要跳过的模型打上特定标签。
- 定义一个选择器，在运行DBT时排除带有该标签的模型。
步骤一：为模型添加标签
首先，在那些你希望能够选择性跳过构建的模型中，为其 config 块添加一个自定义标签。例如，我们可以使用 dont_run 标签：
-- models/my_project/some_long_running_model.sql
{{
config({
"materialized": 'incremental',
"unique_key": 'some_unique_key',
"tags": ["dont_run"], -- 添加自定义标签
})
}}
SELECT
column1,
column2
FROM {{ source('my_source', 'raw_data') }}
WHERE some_condition;这个标签本身不会影响模型的构建行为，它只是一个元数据标记。
步骤二：定义选择器
在你的DBT项目根目录（与 dbt_project.yml 同级）下，创建一个名为 selectors.yml 的文件。在这个文件中，你可以定义一个或多个选择器，用于指定在 dbt run 命令中包含或排除哪些模型。
为了实现跳过带有 dont_run 标签的模型，我们可以定义一个选择器，它首先选择所有模型（fqn: "*"），然后明确排除带有 dont_run 标签的模型：
# selectors.yml
selectors:
- name: my_project_with_tags_ignored # 选择器名称
definition:
# 联合操作：选择所有模型，然后排除带有"dont_run"标签的模型
union:
- method: fqn
value: "*" # 选择所有模型
- exclude:
- method: tag
value: dont_run # 排除带有"dont_run"标签的模型解释：
- name: 这是你将在 dbt run 命令中使用的选择器名称。
- definition: 定义选择器的逻辑。
- union: 允许你组合多个选择规则。
- method: fqn 和 value: "*": 这是一个通配符，表示选择项目中的所有模型、种子、快照等。
- exclude: 指定要从上述选择中排除的节点。
- method: tag 和 value: dont_run: 表示排除所有带有 dont_run 标签的节点。
步骤三：使用选择器运行DBT
现在，当你想要执行整个项目，但跳过那些标记为 dont_run 的模型时，可以在命令行中使用你定义的选择器：
dbt run --selector my_project_with_tags_ignored
执行此命令后，DBT会：
- 解析整个项目的DAG，包括所有模型，无论它们是否有 dont_run 标签。
- 根据 my_project_with_tags_ignored 选择器的定义，从执行计划中移除所有带有 dont_run 标签的模型。
- 构建剩余的模型。
- 对于那些被排除但被其他模型引用的模型（例如 some_long_running_model），DBT会假定其对应的数据表已经存在于数据库中，并允许依赖模型正常读取这些表。
这种方法的优势
- 不破坏依赖关系： 与 enabled: false 不同，使用选择器和标签不会从DAG中移除模型定义，只是在特定运行中跳过其构建。因此，下游模型仍然可以成功地 ref() 这些模型。
- 灵活性： 你可以根据需要创建多个选择器，以应对不同的运行场景（例如，运行所有模型、只运行特定标签的模型、排除特定路径的模型等）。
- 清晰的项目结构： 模型的 config 块保持简洁，enabled 状态保持为 true，避免了复杂的Jinaj条件判断来切换 ref 和 source。
- 易于维护： 标签和选择器是DBT的内置功能，有良好的文档支持，比自定义的Jinaj宏更易于理解和维护。
注意事项与最佳实践
- 数据表必须存在： 当你使用选择器跳过某个模型的构建时，DBT会期望该模型对应的数据表已经存在于数据库中。如果数据表不存在，而依赖模型尝试 SELECT 它，则会遇到数据库级别的错误。因此，这种方法适用于那些已经构建过且数据相对稳定的模型。
- 完整运行： 当你需要更新所有模型（包括那些通常被跳过的模型）时，只需执行标准的 dbt run 命令（不带 --selector 参数），或者创建一个包含所有模型的选择器。
- 组合选择器： DBT的选择器功能非常强大，你可以根据模型名称、路径、标签等多种属性进行组合选择。详细用法请参考DBT官方文档：DBT Node Selection - YAML Selectors。
- 版本控制： selectors.yml 文件应纳入版本控制，以便团队成员共享和理解运行策略。
总结
通过巧妙地利用DBT的选择器和标签机制，我们可以优雅地解决禁用模型在被引用时导致的依赖错误。这种方法提供了一种灵活且非破坏性的方式来控制DBT项目的执行流程，使得在复杂的数据转换项目中，能够根据业务需求动态地跳过某些模型的构建，同时保持数据依赖的完整性。它避免了对 enabled 配置的误用，并提供了一个更健壮、可维护的解决方案。
