dbt-core项目中的Redshift大小写敏感问题解析

问题背景

在使用dbt-core进行数据测试时，特别是针对Redshift数据库时，开发人员可能会遇到一个关于大小写敏感的棘手问题。当使用accepted_values测试并启用store_failures: true选项时，测试可能会因为生成的列名大小写不一致而失败。

问题现象

具体表现为：当测试值中包含大写字母（如"United States"）时，dbt生成的列名会保留原始大小写（如"accepted_values_stg_amplitude__event_country__United_States"），而Redshift数据库实际上会将其转换为小写形式（如"accepted_values_stg_amplitude__event_country__united_states"）。这种不一致导致dbt在查找关系时出现模糊匹配错误。

根本原因

这个问题的根源在于Redshift数据库的enable_case_sensitive_identifier参数设置。当该参数设置为false（默认值）时，Redshift会忽略标识符的大小写差异，将所有标识符视为小写。而dbt-core在生成测试关系名称时保留了原始大小写，导致两者不一致。

解决方案

推荐方案：使用自定义测试名称

最简单可靠的解决方案是为测试指定一个全小写的自定义名称：

models:
  - name: stg_amplitude__event
    columns:
      - name: country
        data_tests:
          - accepted_values:
              name: test_name_all_lowercase
              values: ['United States']

这种方法不需要修改任何底层配置或代码，是最安全的选择。

数据库配置方案：启用大小写敏感标识符

如果组织允许，可以考虑修改Redshift集群参数组的enable_case_sensitive_identifier设置为true。这将使Redshift尊重标识符的大小写，从根本上解决问题。但需要注意，这种更改可能会影响现有查询和应用程序。

高级方案：覆盖测试物化逻辑（不推荐）

对于有特殊需求的用户，可以创建自定义的测试物化逻辑，强制将所有标识符转换为小写：

{%- materialization test, default -%}
  {% set relations = [] %}
  {% if should_store_failures() %}
    {% set identifier = model['alias'] | lower %}
    ...
{%- endmaterialization -%}

但这种方法需要维护自定义代码，可能会与未来dbt版本产生兼容性问题，一般不建议使用。

最佳实践建议

1. 在Redshift环境中，始终使用小写标识符可以避免大多数大小写相关问题
2. 对于关键测试，使用显式的自定义名称可以增强可读性和稳定性
3. 在团队协作环境中，统一命名规范可以减少此类问题的发生
4. 考虑在项目文档中明确记录命名规范，特别是当项目需要支持多种数据库时

总结

dbt-core与Redshift的大小写敏感问题是一个典型的数据库适配器特性差异问题。通过理解底层机制和采用适当的解决方案，开发人员可以有效地规避这一问题，确保数据测试的稳定运行。在实际项目中，推荐优先采用自定义测试名称的方案，它既简单又不会引入额外的维护负担。