本文探讨了在 data build tool (dbt) 项目中，当一个模型被禁用（`enabled=false`）后仍被其他模型引用时导致的错误。传统禁用方法会中断依赖链，而本文提出的解决方案是利用 dbt 的选择器（selectors）功能。通过为不需要运行的模型设置特定标签，并配置选择器来排除这些标签，可以在不运行特定模型的同时，允许其下游模型引用其已存在的物化表，从而避免错误并实现灵活的项目运行管理。
理解 DBT 模型禁用与依赖引用问题
在 DBT 项目开发过程中，我们经常会遇到需要临时停止某些模型运行的场景。例如，一个模型可能还在开发中，或者其数据更新频率较低，不需要每次都重新计算。DBT 提供了一个 config 参数 enabled=false，允许开发者禁用特定模型：
{{
config(
materialized='incremental',
enabled=false
)
}}
-- 你的 SQL 逻辑然而，这种直接禁用模型的方式会引发一个常见的问题：如果其他模型通过 {{ ref("MODEL_NAME") }} 引用了被禁用的模型，DBT 在执行时会抛出错误，因为它无法找到并构建这个被禁用的依赖。这意味着，即使你希望下游模型能够像引用一个源表一样，使用被禁用模型已存在的物化结果，enabled=false 的设置也会阻碍整个项目的运行。
开发者可能尝试使用 Jinja 逻辑动态判断模型是否启用，并相应地切换 ref 或 source 函数。例如：
{% if is_model_enabled("MODEL1") %}
{{ ref("MODEL1") }}
{% else %}
{{ source('SCHEMA_NAME', 'MODEL1') }}
{% endif %}这种方法虽然理论上可行，但在大型项目中会使代码变得异常复杂和难以维护，因为它需要在每个引用点进行条件判断。
解决方案：利用 DBT 选择器管理模型执行
DBT 提供了一个强大且灵活的特性——选择器（selectors），它允许我们精确控制在 dbt run 命令中包含或排除哪些模型。通过巧妙地结合选择器和模型标签，我们可以优雅地解决上述问题，实现“不运行特定模型但允许引用其现有物化结果”的目标。
核心思路是：
- 为那些你希望在某些运行中不构建的模型打上特定的标签。
- 创建一个选择器配置，在运行 DBT 时排除带有这些标签的模型。
当一个模型被选择器排除时，DBT 不会尝试去构建它。但如果其他模型引用了它，DBT 会假设该模型已存在于数据库中（即其上次成功运行的物化结果），并将其视为一个外部表或视图来处理，从而避免了依赖错误。
步骤一：创建 selectors.yml 文件
在你的 DBT 项目根目录（与 dbt_project.yml 同级）创建一个名为 selectors.yml 的文件。在这个文件中，你可以定义一个或多个选择器。
以下是一个示例配置，它定义了一个名为 my_project_without_disabled_models 的选择器，该选择器将运行项目中除带有 dont_run 标签之外的所有模型：
selectors:
- name: my_project_without_disabled_models
definition:
# 联合操作：包含所有模型，然后排除带有 'dont_run' 标签的模型
union:
- method: fqn # fqn 表示完全限定名称，"*" 代表所有模型
value: "*"
- exclude: # 排除操作
- method: tag # 排除方法基于标签
value: dont_run # 排除带有 'dont_run' 标签的模型说明：
- name: 选择器的唯一名称，用于在命令行中引用。
- definition: 定义选择器的逻辑。
- union: 允许你组合多个选择规则。这里我们先包含所有模型 (fqn: "*")。
- exclude: 从包含的模型集中排除符合特定条件（如标签）的模型。
- method: 定义选择或排除的依据，可以是 fqn (完全限定名称)、tag (标签)、path (文件路径) 等。
步骤二：为模型添加标签
对于那些你希望在特定运行中不构建，但仍能被引用的模型，你需要在其配置中添加一个与 selectors.yml 中定义的排除标签相匹配的标签。
-- models/my_disabled_model.sql
{{
config({
"materialized": 'incremental',
"unique_key": 'some_unique_key',
"tags": ["dont_run"], -- 为此模型添加 'dont_run' 标签
})
}}
SELECT
column1,
column2
FROM
some_source_table
WHERE
some_condition现在，这个 my_disabled_model 模型被标记为 dont_run。
步骤三：使用选择器运行 DBT
要运行你的 DBT 项目，同时排除带有 dont_run 标签的模型，请使用 dbt run 命令并指定你创建的选择器：
dbt run --selector my_project_without_disabled_models
执行此命令后，DBT 将会：
- 构建项目中所有不带 dont_run 标签的模型。
- 当其他模型 ref("my_disabled_model") 时，DBT 不会尝试构建 my_disabled_model，而是会查找数据库中 my_disabled_model 对应的已存在表或视图，并将其作为输入。
这样，你既避免了 enabled=false 带来的依赖错误，又实现了动态控制模型运行的目的。
进一步的应用与注意事项
- 运行所有模型： 当你需要运行所有模型（包括那些带有 dont_run 标签的模型）时，只需执行标准的 dbt run 命令，或者创建一个包含所有模型的选择器。
- 多重选择器： 你可以定义多个选择器来满足不同的运行需求，例如，只运行特定业务领域模型、只运行增量模型等。
- 标签的灵活性： 标签是非常灵活的，你可以为模型设置多个标签，并在选择器中组合使用它们进行更精细的控制。
- 避免 Jinja 复杂性： 这种方法避免了在每个 ref 语句中编写复杂的 Jinja 条件逻辑，使模型代码更加简洁和可读。
- 依赖图的可视化： 即使模型被选择器排除，DBT 的依赖图仍然会显示这些模型的存在及其依赖关系，只是它们不会在当前运行中被构建。
- 数据时效性： 请注意，当一个模型被选择器排除时，其下游模型将使用该模型上次成功构建后的数据。因此，这种方法适用于那些数据时效性要求不那么高，或者其数据在后台通过其他方式保持更新的模型。
总结
通过巧妙利用 DBT 的选择器和标签功能，我们可以有效地管理模型在项目中的执行。这种方法提供了一种强大且灵活的机制，可以在不破坏模型间依赖关系的前提下，动态地决定哪些模型需要运行，哪些模型可以作为已存在的物化结果被引用。这不仅解决了 enabled=false 带来的痛点，还提升了 DBT 项目的可维护性和运行效率，是管理复杂 DBT 项目的推荐实践。
