本文探讨了在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, column2FROM {{ source('my_source', 'raw_data') }}WHERE some_condition;
这个标签本身不会影响模型的构建行为，它只是一个元数据标记。
可灵大模型
可灵大模型（Kling）是由快手大模型团队自研打造的视频生成大模型
214 查看详情 
步骤二：定义选择器
在你的DBT项目根目录（与 dbt_project.yml 同级）下，创建一个名为 selectors.yml 的文件。在这个文件中，你可以定义一个或多个选择器，用于指定在 dbt run 命令中包含或排除哪些模型。
为了实现跳过带有 dont_run 标签的模型，我们可以定义一个选择器，它首先选择所有模型（fqn: “*”），然后明确排除带有 dont_run 标签的模型：
# selectors.ymlselectors: - 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 配置的误用，并提供了一个更健壮、可维护的解决方案。
以上就是DBT模型依赖管理：通过选择器和标签实现灵活的模型运行与跳过策略的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/572328.html
微信扫一扫 
支付宝扫一扫 
