基于K8s的Airflow多仓库DAG导入及结构设计咨询

背景 #

我们通过官方Helm Chart在Kubernetes上部署Airflow，采用KubernetesExecutor与git-sync组件，单Gitlab仓库的DAG运行正常，但在加载多仓库DAG时遇到结构设计瓶颈，计划通过git submodules实现，当前设计的基础Airflow仓库结构如下：

.
├── dags/
│   ├── common/
│   │   ├── common_dag_1.py
│   │   ├── common_dag_2.py
│   │   └── util/
│   │       └── util_code_dag_1.py
│   └── added_repo_1/
│       ├── added_dag_1
│       ├── added_dag_2
│       └── util/
│           └── util_code_added_dag_1.py
├── plugins/
│   ├── hooks/
│   ├── sensors/
│   └── operators/
└── tests/

问题1：多个待导入仓库包含大量Jupyter Notebook、Python包或测试脚本等无关代码，是否需要拆分重构仅保留相关代码？ #

必须拆分或通过配置过滤无关内容：

• Airflow的git-sync会同步整个子模块仓库到容器中，无关代码会增加镜像体积、延长同步时间，还可能引入依赖冲突或安全风险。
• 最优方案是让每个待导入仓库单独维护专供Airflow的分支/子仓库，只保留DAG文件、DAG专属工具代码，剔除所有无关内容。
• 若无法拆分仓库，可通过git submodules的sparse-checkout功能，仅拉取仓库中DAG相关的目录（比如每个待导入仓库的airflow_dags/目录），避免同步冗余内容。

问题2：待导入仓库的测试是否应在原仓库通过CI/CD执行？基础仓库的tests目录应存放哪些内容？ #

• 待导入仓库的测试必须在原仓库执行CI/CD：这些测试（如DAG单元测试、业务逻辑测试）与业务代码强绑定，原仓库的CI/CD能在代码变更时即时验证，避免无效或错误代码流入Airflow。
• 基础仓库的tests/目录仅存放跨仓库的通用测试内容：
  • 所有DAG的Airflow规范校验（如DAG ID唯一性、任务依赖合法性、语法正确性）
  • 基础仓库中common/目录下通用工具函数的单元测试
  • Airflow自定义插件（hooks/sensors/operators）的测试
  • 多仓库DAG加载后的集成测试（验证所有子模块DAG能被Airflow正常解析）

问题3：有哪些优化整体项目结构的建议？ #

• 子模块目录规范化：在基础仓库dags/下为每个子模块创建与仓库名对应的独立目录（如dags/repo_a/、dags/repo_b/），避免目录层级混乱。
• 通用与专属代码分离：将跨仓库复用的工具代码抽离到基础仓库dags/common/util/，避免重复开发；业务专属的工具代码留在对应子模块的util/目录中。
• 依赖管理统一化：在基础仓库根目录维护requirements.txt或pyproject.toml，统一管理所有DAG和插件的通用Python依赖；若子模块有专属依赖，可在子模块目录下单独存放requirements_local.txt，通过Helm配置extraRequirements或自定义初始化脚本额外安装。
• 子模块版本锁定：在基础仓库中锁定每个子模块的特定commit，禁止自动同步到仓库最新代码，确保DAG运行的稳定性，避免意外引入未测试的变更。
• 权限与路径校验：确保所有子模块的DAG目录及文件权限符合Airflow要求（可读权限），同时在基础仓库中配置.gitignore，避免同步子模块的临时文件、日志等内容到Airflow容器。

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