使用DBT创建表及跨环境复制表结构相关技术咨询

是否可以使用DBT创建新表？ #

完全可以，建物理表是DBT的核心基础能力，不需要额外插件就能实现：

• 常规建表只需要在SQL模型文件头部加{{ config(materialized='table') }}配置，写好表对应的字段加工逻辑后执行dbt run，DBT会自动在当前连接的目标库、目标schema下生成对应物理表，默认如果表已经存在，会先删除旧表再重建。
• 如果只需要建空表不需要灌数据，在SELECT语句末尾加where 1=0就行，运行后只会生成表结构，不会写入任何业务数据。

举个最简单的模型例子，对应文件路径models/dim_user.sql：

{{ config(
    materialized='table',
    alias='dim_user_info'
) }}

select
    user_id,
    user_name,
    register_time,
    user_level
from raw_data.user_raw
-- 要灌数就删掉下面这行
where 1=0

执行dbt run --select dim_user就能在目标库生成dim_user_info表。

是否能够借助DBT将数据库dev环境中已存在的表结构复制到其他环境？ #

可以实现，按使用场景选对应方案就行：

• 长期用优先选规范方案：先把dev环境里已经建好的表的加工逻辑沉淀成标准DBT模型，在DBT的连接配置里提前维护好test、prod等不同环境的数据库地址、账号权限，切换到目标环境后执行dbt run，就能在对应环境生成和dev结构完全一致的表。这种方式还能同步字段注释、表描述、数据血缘这些元信息，后续改结构只要调整模型代码就能多环境同步，不会出现多环境表结构对不上的问题。
• 临时快速复制可以用跨源读的方式：把dev环境配成项目的外部数据源，给DBT用的账号开dev环境目标表的读权限，写一个简单的空表模型直接读取dev的表结构，切到目标环境运行就能完成复制，代码示例：

{{ config(materialized='table') }}
select *
from {{ source('dev_env', 'the_table_you_want_to_copy') }}
where 1=0

注意：如果目标环境是生产环境，别用第二种临时方案，绝大多数企业的生产环境会做网络隔离，禁止直接跨环境访问dev资源，这种操作也不符合数据安全规范。

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