本文探讨了在data build tool (dbt) 中，当一个模型被禁用（`enabled=false`）但仍被其他模型引用时导致的错误。针对此问题，教程详细介绍了如何利用dbt的选择器（selectors）功能，通过标签（tags）动态控制模型的运行，从而避免依赖错误，并实现灵活的项目执行管理，无需复杂的jinja逻辑。
DBT中引用禁用模型的问题与解决方案
在Data Build Tool (DBT) 项目中，我们经常需要根据不同的场景选择性地运行某些模型。一种常见的做法是在模型配置中使用 enabled=false 来禁用特定模型，例如：
{{config(
materialized='incremental',
enabled=false
)}}然而，当一个模型被禁用后，如果它仍然被项目中的其他模型通过 {{ ref("MODEL_NAME") }} 引用，DBT在执行时会抛出错误，指出存在对一个已禁用模型的依赖。这通常发生在用户希望暂时跳过某个模型的构建，但又希望依赖它的下游模型能继续从已存在的物理表（如同源表一样）读取数据，而不是因为依赖关系失败。
尝试通过复杂的Jinja逻辑来判断模型是否启用，并动态切换 ref 到 source 的方式，虽然理论上可行，但在实际项目中会变得非常难以维护和理解。幸运的是，DBT提供了一个更优雅、更强大的解决方案：选择器（Selectors）。
为什么enabled=false不适用于此场景？
enabled=false 的作用是完全将该模型从DBT的图谱中移除，这意味着DBT在构建依赖图时不会考虑它。因此，当其他模型尝试 ref 一个被禁用模型时，DBT会认为该引用无效，因为它在当前的执行图谱中找不到对应的节点，从而导致构建失败。它并没有提供一种机制来“假装”这个模型是一个已存在的源表。
使用DBT选择器管理模型执行
DBT选择器提供了一种灵活的方式来定义要在特定DBT运行中包含或排除哪些模型。通过结合标签（tags），我们可以轻松实现动态地运行项目子集，而不会遇到禁用模型依赖的问题。
步骤一：定义选择器文件
在你的DBT项目主目录（与 dbt_project.yml 文件同级）创建一个名为 selectors.yml 的文件。在这个文件中，你可以定义一个或多个选择器。
以下是一个示例，定义了一个名为 my_project_with_tags_ignored 的选择器，它的作用是运行所有模型，但排除那些带有 dont_run 标签的模型：
# selectors.yml
selectors:
- name: my_project_with_tags_ignored
definition:
# 联合操作：首先选择所有模型，然后排除带有特定标签的模型
union:
- method: fqn # fqn (Fully Qualified Name) 表示选择所有模型
value: "*"
- exclude: # 排除操作
- method: tag # 通过标签进行排除
value: dont_run # 排除带有 'dont_run' 标签的模型选择器解析：
- name: 选择器的唯一标识符。
- definition: 定义选择器的逻辑。
- union: 允许你合并多个选择逻辑。这里我们结合了两个部分。
- 第一个部分 method: fqn, value: "*" 表示选择项目中的所有模型。
- 第二个部分 exclude 定义了要从上述选择中排除的模型。
- method: tag, value: dont_run 表示排除所有带有 dont_run 标签的模型。
步骤二：为需要条件执行的模型添加标签
接下来，在那些你希望能够选择性跳过构建的模型中，添加一个 tags 配置。例如，如果你有一个模型叫做 my_complex_model，你希望在某些运行中跳过它：
-- models/my_complex_model.sql
{{
config({
"materialized": 'incremental',
"unique_key": 'some_unique_key',
"tags": ["dont_run"], -- 添加 'dont_run' 标签
})
}}
SELECT
...
FROM
{{ ref('upstream_model') }}
WHERE
...步骤三：使用选择器执行DBT任务
现在，当你想要执行整个项目，但跳过那些带有 dont_run 标签的模型时，可以使用以下命令：
dbt run --selector my_project_with_tags_ignored
执行此命令后，DBT会：
- 解析 selectors.yml 文件，找到 my_project_with_tags_ignored 选择器。
- 根据选择器的定义，构建一个只包含未标记为 dont_run 的模型的执行图谱。
- 运行这个子集模型。
关键优势：
- 避免依赖错误： 因为带有 dont_run 标签的模型根本没有被包含在当前的执行图谱中，DBT在构建依赖关系时不会尝试去解析它们，因此不会出现“引用已禁用模型”的错误。
- 灵活性： 你可以根据需要创建不同的选择器，结合标签、模型名称、路径等多种方法来精确控制每次运行的模型范围。
- 可维护性： 相比于复杂的Jinja条件判断，使用标签和选择器使项目配置更加清晰和易于管理。
运行时机与替代方案
- 常规运行： 当你希望运行所有模型（包括那些带有 dont_run 标签的模型）时，只需执行标准的 dbt run 命令即可。
- 特定标签运行： 你也可以创建另一个选择器，专门选择带有特定标签的模型，或者使用命令行直接指定标签：dbt run --models tag:dont_run。
总结
通过巧妙地利用DBT的选择器和标签功能，我们可以优雅地解决引用禁用模型时遇到的依赖错误问题。这种方法不仅避免了复杂的Jinja逻辑，还提供了极高的灵活性，使得DBT项目的模型管理和执行策略更加强大和可控。建议深入阅读DBT官方文档中关于节点选择（Node Selection）和YAML选择器（YAML Selectors）的部分，以充分发挥其潜力。
参考资料：
- DBT官方文档 - Node Selection: https://www.php.cn/link/8c2208cf33090f61a75c8dbfdf78b61b
