本文探讨了在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.ymlselectors: - name: my_project_with_tags_ignored definition: # 联合操作：首先选择所有模型，然后排除带有特定标签的模型 union: - method: fqn # fqn (Fully Qualified Name) 表示选择所有模型 value: "*" - exclude: # 排除操作 - method: tag # 通过标签进行排除 value: dont_run # 排除带有 'dont_run' 标签的模型
选择器解析：
无阶未来模型擂台/AI 应用平台
无阶未来模型擂台/AI 应用平台，一站式模型+应用平台
35 查看详情 
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
以上就是DBT中引用被禁用模型时报错的解决方案：使用选择器管理模型执行的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/574423.html
微信扫一扫 
支付宝扫一扫 
