DBT CLI传入run_date变量无法以字符串正常使用问题排查

问题背景 #

在dbt项目的YML文件中，用dbt_date.yesterday()定义了DATE类型的变量run_date，默认值为昨日日期，直接在SQL中使用时一切正常。但通过CLI执行命令：

dbt run --select test_model --vars '{run_date: "2023-12-01"}'

覆盖变量时，传入的2023-12-01无法被正常识别为字符串，导致SQL执行失败。测试SQL如下：

{% set run_date_dash = var("run_date") %}

SELECT REPLACE(SAFE_CAST( {{ run_date_dash }} as STRING), "-","") as test_date

尝试在SQL中添加单引号，但因默认变量是DATE类型而失效；用jinja条件判断做临时方案（如下代码），但写法冗余不够优雅，且后续在WHERE子句中使用仍存在问题：

{% set run_date_dash = var("run_date") %}

{% if run_date_dash == dbt_date.yesterday() %}
  SELECT
    1 as test,
    REPLACE(CAST(
      cast(
        datetime_add(
          cast(
            cast(timestamp(datetime(current_timestamp(), 'Europe/Amsterdam')) as date) as datetime
          ),
          interval -1 day
        ) as date
      ) as STRING
    ), "-", "") as test_date
{% else %}
  SELECT
    1 as test,
    REPLACE(CAST('{{ run_date_dash }}' as STRING), "-", "") as test_date
{% endif %}

解决方案：自定义宏统一处理日期变量 #

通过自定义宏可以完美解决这个问题，既能兼容默认的DATE类型变量，也能正确解析CLI传入的字符串日期，还可按需扩展其他日期处理逻辑。

1. 创建自定义宏 #

在dbt项目的macros目录下新建文件（比如date_utils.sql），添加以下宏代码：

{% macro process_run_date(run_date_var) %}
    {% if run_date_var is string %}
        -- 处理CLI传入的字符串日期，添加单引号保证SQL语法正确
        '{{ run_date_var }}'
    {% else %}
        -- 处理默认的DATE类型变量，直接转为字符串
        cast({{ run_date_var }} as string)
    {% endif %}
{% endmacro %}

2. 在模型中调用宏 #

修改测试SQL，用宏来统一处理run_date变量：

{% set run_date_dash = var("run_date") %}

SELECT REPLACE(SAFE_CAST( {{ process_run_date(run_date_dash) }} as STRING), "-","") as test_date

3. WHERE子句中的适配用法 #

如果需要在WHERE子句中使用该变量，宏同样能保证语法正确：

{% set run_date_dash = var("run_date") %}

SELECT *
FROM your_target_table
WHERE record_date = cast({{ process_run_date(run_date_dash) }} as date)

原理说明 #

宏通过jinja的is string判断变量类型：

• 若为CLI传入的字符串类型日期，自动添加单引号包裹，符合SQL字符串语法要求；
• 若为默认的DATE类型变量，直接转为字符串格式，保证两种场景下的处理逻辑统一。
  这种方式彻底规避了条件判断的冗余，同时确保SQL执行的正确性。

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