Airflow用户集成DBT远程仓库的相关配置问题咨询

1. git submodule是否为最优方案 #

这个认知在大多数场景下是成立的，优势如下：

• 支持dbt仓库和Airflow仓库独立做版本管理，二者的提交历史互不干扰，可单独回滚任意仓库的版本，适合两个项目由不同团队/角色维护的场景
• 无需频繁拷贝代码，仅需在dbt仓库更新后执行git submodule update --remote即可同步最新版本

如果你的团队规模较小、两个仓库迭代耦合度极高，也可以选择git subtree或者CI/CD构建时同步dbt代码到Airflow部署路径的方案，避免submodule需要额外执行初始化、拉取命令的额外操作。

2. dbt仓库存放路径 #

不建议直接存放在dags/目录下：Airflow Scheduler会持续扫描dags/下所有文件识别DAG，dbt项目中的大量sql、yml、宏文件会增加Scheduler的扫描负担，严重时可能导致DAG加载延迟。

推荐在~/airflow根目录下新建独立的dbt_projects/目录，将dbt仓库作为submodule拉取到该目录下，最终路径示例：

~/airflow
    - .git
    - dags/
    - dbt_projects/
        - your_first_dbt_project/  # 对应第一个dbt submodule

DAG中调用dbt命令时，直接指定对应项目的绝对路径即可，不会影响Airflow的正常调度逻辑。

3. 多dbt项目同时运行配置 #

可以按以下方案配置完全隔离的多项目运行环境：

• 目录层：每个dbt项目作为独立的submodule放在dbt_projects/目录下，各自保留项目内的dbt_project.yml配置，互不干扰
• 配置层：将所有dbt项目的连接配置统一存放在~/.dbt/profiles.yml中，每个项目对应独立的profile名称；如果项目连接配置敏感性不同，也可以单独在每个项目根目录下放专属的profiles.yml
• 运行层：执行dbt命令时通过参数指定对应项目即可，示例命令：dbt run --project-dir ~/airflow/dbt_projects/project_a --profile project_a_profile

如果不同dbt项目依赖的dbt版本、第三方包存在冲突，可以给每个项目单独创建Python虚拟环境，运行时直接调用对应虚拟环境下的dbt二进制文件即可，示例：/opt/venvs/project_a/bin/dbt run --project-dir ~/airflow/dbt_projects/project_a

Airflow调度时，无论是使用BashOperator还是dbt专属Operator，只要每个任务指定对应项目的路径、profile、虚拟环境路径即可，不存在项目冲突问题。

内容的提问来源于stack exchange，提问作者Michel Guimarães