本文旨在解决data build tool (dbt) 中，当一个模型被禁用（`enabled: false`）但仍被其他模型引用时导致的依赖错误。通过详细阐述dbt选择器（selectors）和标签（tags）的结合使用，提供了一种灵活且专业的解决方案，允许开发者动态控制模型的运行，同时保持项目依赖关系的完整性，避免复杂的jinja逻辑重构。
DBT中禁用模型引用导致的挑战
在DBT项目中，我们经常需要对模型进行精细化管理。有时，出于性能优化、调试或特定业务场景的需求，我们可能希望暂时禁用某些模型，使其在当前运行中不被执行。DBT提供了config(enabled=false)配置来达到此目的。然而，当一个模型被禁用后，如果它仍然被项目中的其他模型通过{{ ref("MODEL_NAME") }}引用，DBT在构建DAG（有向无环图）并尝试编译项目时，会抛出错误，指示存在对已禁用模型的依赖。
这种行为与开发者期望可能有所不同。理想情况下，如果一个模型被暂时禁用，而下游模型仍然需要其数据，开发者可能希望DBT能像处理源表（source table）一样，直接读取该模型上次成功运行后生成的数据表，而不是尝试重新构建它。尝试通过复杂的Jinja逻辑在{{ ref(...) }}和{{ source(...) }}之间动态切换，虽然理论可行，但在实践中往往导致代码难以维护且易出错。
解决方案：利用DBT选择器与标签实现动态执行
DBT提供了一个强大而灵活的机制来解决此类问题：选择器（Selectors）与标签（Tags）。通过定义选择器，我们可以精确控制在特定dbt run命令中包含或排除哪些模型，从而在不修改模型代码本身的情况下，实现动态的模型执行策略。
1. 定义选择器配置 (selectors.yml)
在DBT项目的主目录（与dbt_project.yml文件同级）中，创建一个名为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: 定义选择器的名称，例如my_project_with_tags_ignored。
- definition: 包含选择器的逻辑。
- union: 表示将多个选择规则合并。
- method: fqn, value: "*": 这是一条包含规则，表示选择所有模型（通过其完全限定名称fqn）。
- exclude: 在union中，exclude规则用于从当前选择集中移除特定节点。
- method: tag, value: dont_run: 这是一条排除规则，表示排除所有带有dont_run标签的模型。
通过这个配置，我们创建了一个名为my_project_with_tags_ignored的选择器。当使用这个选择器执行DBT时，它会尝试运行项目中的所有模型，但会跳过那些被明确标记为dont_run的模型。
2. 在模型中添加标签
接下来，在那些你希望能够被选择器动态排除的模型配置文件中，添加一个或多个标签。
-- models/my_model_to_skip.sql
{{
config({
"materialized": 'incremental',
"unique_key": 'some_unique_key',
"tags": ["dont_run"], -- 添加 "dont_run" 标签
})
}}
SELECT
...
FROM
...配置说明：
- tags: 在模型的config块中，可以定义一个标签列表。在这里，我们将dont_run标签添加到模型配置中。
现在，当my_model_to_skip.sql被引用时，如果使用上述选择器，DBT将知道不执行此模型。
3. 使用选择器执行DBT作业
要使用定义好的选择器来运行DBT项目，只需在dbt run命令中指定--selector参数：
dbt run --selector my_project_with_tags_ignored
执行此命令后，DBT将根据selectors.yml中定义的规则，构建并执行模型。所有带有dont_run标签的模型将被排除在本次运行之外。
工作原理与注意事项
- 编译与执行分离： 当使用选择器时，DBT会根据选择器定义的规则，首先确定本次运行需要包含哪些模型。被排除的模型将不会被编译或执行。
- 依赖关系处理： 如果一个下游模型MODEL_B引用了被排除的MODEL_A（即MODEL_B中包含{{ ref("MODEL_A") }}），而MODEL_A在本次运行中被选择器排除，DBT不会尝试重新构建MODEL_A。相反，MODEL_B在执行时将直接查询数据库中MODEL_A上次成功运行后留下的表。因此，这种策略要求被排除模型的表在数据库中必须是存在的，并且其数据是可接受的。如果MODEL_A从未成功运行过，或者其数据已过时且不适用于MODEL_B，则MODEL_B的执行可能会失败或产生不正确的结果。
- 灵活性： 你可以创建多个选择器，每个选择器对应不同的运行策略。例如，可以创建一个选择器专门用于运行所有模型（dbt run的默认行为），或者另一个选择器只运行特定标签的模型。
-
enabled: false与选择器的区别：
- enabled: false：通常用于永久性或长期性地禁用一个模型。被enabled: false禁用的模型，在任何dbt run中都不会被编译或执行，除非通过特殊的命令行参数（如--models +model_name）明确指定。如果一个被禁用的模型被ref引用，DBT会报错。
- 选择器：用于动态和临时性地从特定运行中排除模型。它不改变模型的enabled状态，而是影响DBT在本次运行中构建的执行图。选择器是解决“我想暂时跳过这个模型，但又不想破坏依赖”问题的理想方案。
- 文档参考： DBT的官方文档提供了关于节点选择和YAML选择器的详细信息，建议查阅以获取更多高级用法和最佳实践：DBT Node Selection - YAML Selectors。
总结
通过巧妙地结合DBT的选择器和标签功能，我们能够优雅地解决禁用模型引用导致的依赖问题。这种方法不仅避免了在模型代码中引入复杂的Jinja逻辑，还提供了极高的灵活性，允许开发者根据实际需求动态调整DBT的执行范围。这使得DBT项目管理更加高效和可控，特别是在大型或复杂的数据转换项目中。记住，在使用此方法时，确保被排除模型的数据表已存在且满足下游模型的依赖是成功的关键。
