Airflow运行GCS数据摄入DAG报指定存储桶不存在404错误

云上老周

2026-8-31

问题根因

从报错请求的URL可以看到，实际上传时访问的存储桶为dtc_data_lake_animated-surfer-338618，其中animated-surfer-338618是GCP数据工程教程中的默认示例项目ID，和你配置的自定义项目ID不符，本质是你配置的环境变量没有被实际执行任务的进程读取，高频触发场景包括：

你使用的是CeleryExecutor，任务实际运行在worker容器中，修改docker-compose配置后仅重启了scheduler、webserver服务，未重启worker容器，旧worker进程仍保留初始启动时加载的旧环境变量
修改docker-compose配置后未重新创建容器，旧容器的环境变量缓存未被清除
DAG代码中存在逻辑覆盖了读取到的BUCKET变量，比如通过f"dtc_data_lake_{PROJECT_ID}"规则拼接桶名，而PROJECT_ID读到了旧值
Airflow UI中配置的GCP默认连接、Variable变量里存了旧的项目ID/桶名，优先级高于系统环境变量

修复步骤

第一步：完全停掉所有Airflow相关容器，清除旧容器实例

docker-compose down
# 如果不需要保留历史任务运行记录，可以加-v参数删除挂载的卷，彻底清理缓存
# docker-compose down -v

第二步：重新构建镜像并启动所有服务

docker-compose build
docker-compose up -d

第三步：验证worker容器内的环境变量是否正确（Celery模式下任务跑在worker中，必须校验该容器）

# 替换为你实际的airflow worker容器名，可通过docker ps查看
docker exec -it <airflow-worker-container-name> bash
# 进入容器后执行以下命令校验输出
echo $GCP_PROJECT_ID
echo $GCP_GCS_BUCKET

校验输出必须和你配置的real-dtc-de、dtc_data_lake_real-dtc-de完全一致，如果输出旧值，检查docker-compose.yml中worker服务是否正确引用了x-airflow-common公共配置块，确保环境变量被同步到所有服务（webserver、scheduler、worker、triggerer）

第四步：检查Airflow连接配置
打开Airflow UI，进入Admin -> Connections页面，找到google_cloud_default连接，确认配置中没有硬编码旧的项目ID、存储桶名，可直接清空连接配置中的项目ID字段，优先使用系统环境变量的配置
第五步：校验DAG代码逻辑
打开DAG文件，确认BUCKET变量读取后没有被其他逻辑覆盖，不要硬编码桶名拼接规则；可在上传函数开头加日志打印实际使用的桶名，方便调试：

import logging

def upload_to_gcs(bucket, object_name, local_file):
    logging.info(f"Uploading to bucket: {bucket}")
    # 保留原有上传逻辑即可
    client = storage.Client()
    bucket = client.bucket(bucket)
    blob = bucket.blob(object_name)
    blob.upload_from_filename(local_file)

第六步：权限校验
确认你挂载的服务账号密钥，拥有目标存储桶dtc_data_lake_real-dtc-de的storage.objects.create权限，且该存储桶确实创建在real-dtc-de项目下，不存在跨项目访问的权限问题。

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