如何防止dbt seed命令在生产环境中执行？

嘿，这个问题戳中了很多dbt用户的痛点——dbt seed用CSV导数据确实方便，但在生产环境误跑很容易搞乱数据，我来分享几个实用的防护办法：

• 环境判断拦截：利用dbt的target变量识别当前环境，直接禁止生产环境执行seed。你可以在dbt_project.yml里给所有seed加个前置钩子，只要检测到是生产环境就抛出错误：

  seeds:
    your_project_name:
      +pre-hook: |
        {% if target.name == 'prod' %}
          select raise_error('⚠️ 禁止在生产环境执行dbt seed！')
        {% endif %}
  

  这里的prod是你生产环境的target名称，记得改成你实际用的名字。

• 检查目标表状态再执行：针对你提到的“只在目标表为空时运行”的需求，可以用前置钩子先检查表是否存在、有没有数据，有数据就阻止seed：

  seeds:
    your_project_name:
      your_seed_table_name:
        +pre-hook: |
          {% set target_table = adapter.get_relation(database=target.database, schema=target.schema, identifier='your_seed_table_name') %}
          {% if target_table %}
            {% set row_count = run_query("select count(*) from " ~ target_table).columns[0][0] %}
            {% if row_count > 0 %}
              select raise_error('❌ 目标表已有数据，禁止执行dbt seed！')
            {% endif %}
          {% endif %}
  

  这个逻辑会先确认表存在，再查行数，只要有数据就报错终止seed操作。

• CI/CD流程管控：在生产环境的部署流水线里直接限制dbt seed的执行权限。比如写个脚本，判断当前环境是生产的话，就拒绝执行seed命令；或者要求必须传入特定的确认参数（比如--allow-prod-seed）才允许运行，平时默认拦截。

• 数据库权限限制：从底层权限入手，给生产环境的dbt执行用户只分配读取权限，不让它有创建/修改表的权限。这样就算误跑dbt seed，也会因为权限不足直接失败，从根源上避免数据污染。

这些方法可以组合使用，比如环境判断+表状态检查+CI/CD管控，多重防护更稳妥。

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