覆盖 DBT 中的源宏以允许测试运行的动态源答案

【问题标题】：Overriding source macro in DBT to allow for dynamic sources for test runs覆盖 DBT 中的源宏以允许测试运行的动态源
【发布时间】：2022-01-11 14:38:24
【问题描述】：

我的目标是能够根据我正在执行的 DBT 运行类型来获得“动态”资源。更准确地说，我正在尝试找到一种解决方案来对我们的 DBT 模型进行端到端的业务测试。我不是指模式或简单的数据测试，而是业务逻辑测试。例如，我有一些带有测试数据的输入表，我运行 DBT 模型，然后我断言最终表包含所需的结果。我可以使用不同的“测试”配置文件在单独的模式中创建所有目标表，但我仍然需要能够从一组不同的源中进行选择，这将是我使用测试数据创建的测试表。

我想我可以在源文件中使用 jinja 并结合一些变量来实现这一点，但我想知道是否有更好的方法可以在不更改源文件的情况下做到这一点。就像，开发人员不必担心编写也适用于测试的代码。为此，我想知道我们是否可以覆盖源宏，或者按照这些方式做一些事情来合并这种行为——类似于我们覆盖generate_schema_name 宏时。类似于（在python伪代码中）：

def source(schema_name, table_name):
    if env('is_test') == true:
        return schema_name + table_name + '_test'
    else:
        return schema_name + table_name

我想这里的复杂性还在于源宏的作用远不止于此，例如为文档的沿袭设置一些信息，我绝对想保留这些信息。

欢迎提出此方法之外的任何建议！

【问题讨论】：

标签： dbt

【解决方案1】：

我认为您应该有单独的数据库进行测试，并在dbt_project.yml 文件中设置用于配置数据库名称的变量

所以当运行测试时，你应该可以使用--vars 选项。

【讨论】：

我认为这通常是一个很好的解决方案，但不幸的是，我认为它不适用于我们的案例，因为我们在 AWS Athena 和 AFAIK 上我们只有 1 个区域数据库（数据目录）。我们只能使用模式，但不能使用数据库——因此是源的问题。
@Catazza：我还没有与 AWS 合作过。但是如果是这样的话，那我们能不能把schema作为变量呢？

【解决方案2】：

如果这是您正在寻找的内容，则不是肯定的，但我之前已经使用动态源做过一些工作。我需要合并 5 个存在于 5 个单独模式中但具有相同表名的表。我希望我提供的内容至少能让你朝着正确的方向前进。

你有两张桌子：

my_database.my_schema.tableA

my_database.my_schema.tableA_test

所以你的源文件看起来像这样：

-- src.yml

sources:
  - name: my_schema
    database: my_database
    tables:
      - name: tableA
      - name: tableA_test

您询问是否有任何方法可以覆盖现有宏，例如生成宏。不幸的是，我个人并没有针对我的情况以这种方式实现它，因为我不想将它应用到更大的规模（只是模型的一小部分）。

然后我有我的模型：

-- my_model.sql

{%- set tbl = get_source(table_name) -%}

select 
    '{{tbl}}' as source,
    column1,
    column2,
    column3
from {{ source( 'my_schema' , tbl ) }} i

并且该模型调用此宏来调整表名：

-- my_macro.sql

{% macro get_source(table_name) %}

{% if target.name = 'test' %}
{% set output = table_name ~ '_test' %}
{% else %}
{% set output = table_name %}
{% endif %}

{{ return(output) }}

{% endmacro %}

我还没有完全测试过这个，但是我已经得到了一些版本的动态模式来工作，所以这里有潜力。我也可能误解了这个问题，所以如果这完全关闭，请告诉我。

【讨论】：