dbt运行模型时重复拼接profiles与project配置中schema名称的问题求助

嗨，这个问题我之前也碰到过，核心原因是dbt默认的schema命名逻辑在搞鬼！

默认情况下，dbt会把profiles.yml里设置的schema作为基础前缀，然后把你在dbt_project.yml里用+schema指定的自定义schema拼在后面，所以你这里两个都是openair，就变成了openair_openair。

给你几个可行的解决办法，按需选就行：

方法1：直接覆盖schema（最直接） #

把dbt_project.yml里的+schema改成不带+的schema，这样会完全替换掉profiles.yml里的schema配置，而不是拼接：

models:
  +transient: false
  profile_name:
    openair:
      +database: XX
      schema: openair  # 去掉前面的+号，直接设置schema
      +materialized: table

方法2：自定义schema生成逻辑（适合全局统一规则） #

如果你的项目里有多个模型组需要统一这个规则，可以在macros文件夹下新建一个宏文件（比如macros/generate_schema_name.sql），重写默认的generate_schema_name逻辑，让它直接返回你指定的自定义schema，不拼接前缀：

{% macro generate_schema_name(custom_schema_name, node) -%}
    {%- set default_schema = target.schema -%}
    {%- if custom_schema_name is none -%}
        {{ default_schema }}
    {%- else -%}
        {{ custom_schema_name }}  # 直接用自定义schema，跳过拼接
    {%- endif -%}
{%- endmacro %}

这个宏会让所有设置了+schema的模型直接用你指定的名称，不会再和profiles.yml里的schema拼接。

方法3：运行时指定schema（临时应急用） #

如果只是临时测试，不想改配置，可以在运行dbt命令的时候直接指定schema：

dbt run --schema openair

这个参数会覆盖所有配置文件里的schema设置，直接生成指定名称的schema。

至于你说其他系统类似配置没问题，大概率是那些系统要么用了上面的自定义宏，要么profiles.yml里的schema和dbt_project.yml里的+schema是不同值，或者他们在dbt_project.yml里用的是不带+的schema配置，你可以对比下其他系统的配置文件确认下~

备注：内容来源于stack exchange，提问作者averma