是否可以将动态值传递到dbt源新鲜度测试中？

问题描述

我正在尝试根据基础来源的“ synced_at”列的中位数和标准差来动态确定在dbt sources.yml中指定的新鲜度检查中的警告和错误。

要完成此操作，我想我可能会尝试在source.yml文件的新鲜度块中传递一个宏，如下所示：

# sources.yml
...
    tables:
      - name: appointment_type
        freshness:
          error_after:
            count: test_macro()
            period: hour
...

位置：

{%- macro test_macro(this) -%}

{# /*
The idea is {{ this.table }} would parameterize a query,going over the same column name for all sources,_fivetran_synced,and spit out the calculated values I want. This makes me feel like 
it needs to be a prehook,that somehow stores the value in a var,and that is accessed in the source.yml,instead of calling it directly. 

In this case a trivial integer is attempted to be returned,just as an example.
*/ #}
{{ return(24) }}

{%- endmacro -%}

但是这会导致类型错误。大概根本不调用该宏。将其包装在Jinja引号中还会返回错误。

我很好奇，目前是否可以通过任何方式将动态值传递给新鲜度检查？

解决方法

由于这个原因，今天不可能从.yml文件中调用宏：dbt需要能够静态地解析这些文件并验证内部对象（包括资源属性，例如源freshness ），然后对数据库运行任何查询。

我认为您可以通过覆盖collect_freshness宏以返回而不是简单地max(synced_at)（是与{{1 }}，基于所有Fivetran current_timestamp时间戳进行标准化。感觉很棘手，但可能。

与此同时，我会在这里轻轻地推动您实现更大的目标。我们认为源新鲜度应该是说明性。您可以告诉Fivetran您希望它多久同步一次数据，并添加max(synced_at)块来测试这些期望。您可以像上面所设想的那样运行即席查询，以确定这些期望是否合理。显然，某些表的更新频率不高或无法预测，但是我发现重写或删除这些表的新鲜度期望比增加其帐户的复杂性更为有用。

dbt jinja2 python sql sql