DBT 1.4版本按指定时间运行测试的配置有效性及方案问询

1. 你的enabled逻辑是否有效？ #

你的配置无效，核心问题有三个：

• 语法错误：now()..hour多了一个冗余的点，正确写法应为now().hour
• 时区不符：now()返回的是dbt执行机器的本地时间，并非UTC时间，无法满足你“UTC 05:00之后运行”的需求
• 冗余转换：enabled属性可直接接受Jinja返回的布尔值，不需要手动转成'true'/'false'字符串

但需要明确：DBT的enabled配置确实支持Jinja表达式，只是你的写法存在错误。

2. 修正后的可用配置 #

如果你的需求是在编译阶段判断UTC时间（比如定时任务中编译和执行在同一时间窗口），可以使用以下配置：

version: 2
models:
  - name: my_first_model
    tests:
      - my_first_model_test:
          name: my_first_model_test
          config:
            enabled: "{{ utcnow().hour >= 5 }}"

关键改动：

• 用utcnow()替代now()，确保获取UTC时间
• 修正语法为utcnow().hour
• 直接返回布尔值，省去字符串转换步骤

3. 按时间条件执行测试的最佳方式 #

需要注意：enabled是在编译阶段解析的，时间判断的是dbt编译代码时的时间，而非测试实际执行的时间。如果编译和执行间隔较长，这个逻辑可能不符合预期。针对不同场景，最佳方式分为两种：

场景一：编译/执行时间窗口一致（比如定时任务） #

使用上面修正后的enabled配置即可，简单直接，能满足大部分定时触发的需求。

场景二：需要在执行阶段动态判断时间 #

此时不能依赖enabled，要把时间判断逻辑写到测试内部：
如果是自定义测试，修改测试SQL如下：

{% test my_first_model_test(model) %}
    {% if utcnow().hour < 5 %}
        -- 时间不满足时，返回空结果让测试直接通过
        select 1 as dummy where 1=0
    {% else %}
        -- 这里写你的实际测试逻辑
        select * 
        from {{ model }} 
        where your_test_condition = false
    {% endif %}
{% endtest %}

如果是使用DBT内置测试（比如unique、not_null），可以封装成自定义测试，或者在调用时结合Jinja条件判断（但这仍属于编译阶段逻辑）。

内容的提问来源于stack exchange，提问作者Victor Longui