在 AWS 上实现 DolphinScheduler 工作流的自动化跨环境部署

概览

在构建现代数据平台时，企业客户通常利用 Amazon EMR 处理大数据工作负载，使用 Amazon RDS 存储元数据，并采用 Apache DolphinScheduler 进行工作流编排。随着业务规模扩展，客户面临的一个共同挑战是：如何在保持开发敏捷性的同时，确保从开发环境到生产环境的发布安全且合规。

传统的手动配置方式存在显著的运维开销（Operational Overhead）：

配置漂移风险：手动在目标环境中创建工作流、复制任务配置、调整参数，一个包含 20 个任务的工作流可能需要 30 分钟以上的操作时间，且容易引入人为错误（Human Error）。

环境差异处理复杂：不同环境的数据源连接、全局参数、凭证配置各不相同，手动修改容易遗漏导致生产事故。

依赖关系管理困难：工作流之间存在 DEPENDENT 和 SUB_PROCESS 类型的依赖，跨环境部署时需要确保依赖的工作流已存在且引用正确。

缺乏审计追踪：手动部署难以追踪变更历史，不符合企业合规要求。

本文将介绍一种自动化解决方案，帮助数据工程团队在 AWS 环境中实现 DolphinScheduler 工作流的无缝迁移，该方案与 AWS Well-Architected Framework 的卓越运营支柱保持一致。

图1：企业数据平台多环境架构

方案收益

维度	收益
效率提升	将 30 分钟的手动操作缩短到秒级自动化执行
错误减少	自动化映射消除配置漂移和人为错误
合规审计	详细的部署报告支持存储到 Amazon S3 进行审计追踪
安全集成	与 AWS Secrets Manager 集成，安全管理凭证

方案架构

该解决方案采用分层架构设计，可部署在 Amazon EC2 运维实例或集成到 AWS CodePipeline CI/CD 流水线中。

图2：跨环境部署工具系统架构

核心组件

组件	功能	AWS 集成
CLI 命令行接口	提供 deploy、precision、list-envs 等命令	可集成到 AWS CodeBuild
DeploymentService	处理整个工作流的批量部署	–
PrecisionDeploymentService	处理任务级别的增删改操作	–
映射服务层	数据源、全局参数、依赖关系的跨环境转换	支持 Amazon RDS 数据源映射
凭证管理	安全获取 API Token	AWS Secrets Manager

部署流程

常规部署采用 5 步流程，确保每次部署可重复、可审计：

图3：常规部署 5 步流程

前置条件

在开始之前，请确保满足以下条件：

AWS 环境要求：

• 具有适当 IAM 权限的 AWS 账户（需要 Secrets Manager 读取权限）

• DolphinScheduler 实例运行在 Amazon EC2 或 Amazon EKS 上

• 元数据存储在 Amazon RDS（MySQL 或 PostgreSQL）中

• 部署工具运行环境与 DolphinScheduler API 端点之间的网络连通性

软件要求：

• Python 3.8+

• pip 包管理器

• 必要的 Python 依赖（requests, pyyaml, boto3）

凭证配置：

在 AWS Secrets Manager 中创建以下密钥：

# 开发环境 Token
aws secretsmanager create-secret \
  --name "dolphinscheduler/dev/api-token" \
  --secret-string "your-dev-token-value"

# 生产环境 Token
aws secretsmanager create-secret \
  --name "dolphinscheduler/prod/api-token" \
  --secret-string "your-prod-token-value"

实施演练

步骤一：配置环境

创建 multi_environments.yaml 配置文件：

安全提示：我们强烈建议不要在配置文件中硬编码敏感凭证。该方案集成 AWS Secrets Manager，在运行时安全获取 DolphinScheduler 访问令牌。

# multi_environments.yaml
environments:
  dev:
    api_endpoint: "http://dev-dolphinscheduler.internal:12345/dolphinscheduler"
    # 推荐：引用 AWS Secrets Manager 中的密钥名称
    token_secret_id: "dolphinscheduler/dev/api-token"
    # 或者直接配置 token（不推荐用于生产环境）
    # token: "your-dev-token"
  prod:
    api_endpoint: "http://prod-dolphinscheduler.internal:12345/dolphinscheduler"
    token_secret_id: "dolphinscheduler/prod/api-token"

# 项目配置
project_names:
  - "data_platform"

# 项目名称映射（源项目 -> 目标项目）
project_mapping:
  "data_platform": "prod_data_platform"

# 数据源映射（RDS 实例）
datasource_mappings:
  "dev_rds_mysql": "prod_rds_mysql"
  "dev_emr_hive": "prod_emr_hive"

# 全局参数映射
global_params_mappings:
  global:
    - source_key: "env"
      source_value: "dev"
      target_value: "prod"
    - source_key: "s3_bucket"
      source_value: "data-platform-dev"
      target_value: "data-platform-prod"
  workflows:
    "etl_daily":
      - source_key: "batch_size"
        source_value: "1000"
        target_value: "10000"

步骤二：验证环境连接

在执行部署前，先验证环境配置和连接性：

# 列出所有配置的环境
python ds_deploy.py list-envs

# 列出指定环境的工作流
python ds_deploy.py list-workflows --env dev

# 查看特定工作流的详细信息
python ds_deploy.py list-workflows --env dev --workflow etl_daily

输出示例：

可用环境:
  - dev: http://dev-dolphinscheduler.internal:12345/dolphinscheduler
  - prod: http://prod-dolphinscheduler.internal:12345/dolphinscheduler

列出环境 dev 的工作流
找到 4 个工作流:
  - dwd_user: 用户维度表ETL (项目: data_platform)
  - dwd_order: 订单维度表ETL (项目: data_platform)
  - dws_daily: 日汇总宽表 (项目: data_platform)
  - ads_report: 报表数据生成 (项目: data_platform)

步骤三：常规部署 – 批量部署工作流

场景：数据工程团队完成了一组 ETL 工作流的开发和测试，需要将开发环境的 4 个相互依赖的工作流部署到生产环境。

工具会自动分析工作流间的依赖关系（DEPENDENT 和 SUB_PROCESS 类型任务），并按拓扑顺序部署：

图4：工作流依赖关系跨环境映射

图5：工作流依赖拓扑排序

第一步：执行 dry-run 预览部署计划

python ds_deploy.py deploy --source dev --target prod \
  --workflows dwd_user,dwd_order,dws_daily,ads_report --dry-run

输出示例：

常规部署工作流: dev -> prod
⚠️  干运行模式，不会执行实际部署

================================================================================
DolphinScheduler 跨环境部署结果
================================================================================
✅ 部署状态: 成功
部署ID: deploy_20260119_143052

部署统计:
┌─────────────┬──────────┬──────────┬──────────┬─────────────┐
│    状态     │    成功   │   失败   │   总计    │    成功率   │
├─────────────┼──────────┼──────────┼──────────┼─────────────┤
│  工作流数量  │     4    │     0    │     4    │   100.0%    │
└─────────────┴──────────┴──────────┴──────────┴─────────────┘

工作流依赖关系:
┌─────────────────────────────────────────┬─────────────────────────────────────┐
│              工作流名称                  │            依赖的工作流              │
├─────────────────────────────────────────┼─────────────────────────────────────┤
│ dwd_user                                │ (无依赖)                            │
│ dwd_order                               │ (无依赖)                            │
│ dws_daily                               │ dwd_user, dwd_order                 │
│ ads_report                              │ dws_daily                           │
└─────────────────────────────────────────┴─────────────────────────────────────┘

拓扑排序后的部署顺序:
┌──────┬─────────────────────────────────────────┬─────────────────────────────────────┐
│ 序号 │               工作流名称                 │               部署状态               │
├──────┼─────────────────────────────────────────┼─────────────────────────────────────┤
│    1 │ dwd_user                                │ ✅ 新建成功                         │
│    2 │ dwd_order                               │ ✅ 新建成功                         │
│    3 │ dws_daily                               │ ✅ 更新成功                         │
│    4 │ ads_report                              │ ✅ 更新成功                         │
└──────┴─────────────────────────────────────────┴─────────────────────────────────────┘
================================================================================

第二步：确认计划后执行实际部署

python ds_deploy.py deploy --source dev --target prod \
  --workflows dwd_user,dwd_order,dws_daily,ads_report

步骤四：精细发布 – 任务级别控制

场景：在已上线的 etl_daily 工作流中，需要新增一个数据质量检查任务 data_quality_check，同时删除一个已废弃的任务 legacy_validation。

python ds_deploy.py precision --source dev --target prod \
  --workflow etl_daily \
  --upsert data_quality_check \
  --delete legacy_validation \
  --dry-run

输出示例：

精细控制部署: etl_daily (dev -> prod)

精细控制操作:
  • 工作流 etl_daily: 部署任务: data_quality_check; 删除任务: legacy_validation
⚠️  干运行模式，不会执行实际部署

================================================================================
DolphinScheduler 跨环境部署结果
================================================================================
✅ 部署状态: 成功

任务部署详情:
┌─────────────┬──────────┬──────────┬──────────┬──────────┬──────────┐
│    操作     │   新建    │   更新   │    删除  │    跳过   │   总计   │
├─────────────┼──────────┼──────────┼──────────┼──────────┼──────────┤
│   任务数量   │    1     │     0    │     1    │     0    │    2     │
└─────────────┴──────────┴──────────┴──────────┴──────────┴──────────┘

任务操作详情:
┌─────────────────────┬─────────────────────┬──────────┬─────────────────────┐
│     工作流名称       │        任务名称      │   操作   │       变更说明       │
├─────────────────────┼─────────────────────┼──────────┼─────────────────────┤
│ etl_daily           │ data_quality_check  │   新建   │   新增数据质量检查    │
│ etl_daily           │ legacy_validation   │   删除   │   移除废弃任务        │
└─────────────────────┴─────────────────────┴──────────┴─────────────────────┘
================================================================================

确认无误后，移除 --dry-run 参数执行实际部署。

步骤五：集成 CI/CD 流水线

最佳实践：为确保生产环境稳定性，我们建议将该工具集成到 AWS CodePipeline 工作流中。

Build 阶段：在 AWS CodeBuild 中运行工作流定义的单元测试。

Staging 阶段：执行 --dry-run 标志，将输出报告存储到 Amazon S3 进行审计记录。

Approval 阶段：使用 CodePipeline 的手动审批步骤，审核 dry-run 报告。

Deploy 阶段：执行实际部署到生产环境。

# CodeBuild buildspec.yml 示例
version: 0.2
phases:
  install:
    commands:
      - pip install -r requirements.txt
  build:
    commands:
      # Dry-run 并保存报告到 S3
      - python ds_deploy.py deploy --source dev --target prod --dry-run > report.txt
      - aws s3 cp report.txt s3://deployment-audit-bucket/$(date +%Y%m%d)/
  post_build:
    commands:
      # 实际部署（在审批后的阶段执行）
      - python ds_deploy.py deploy --source dev --target prod

异常处理示例

数据源映射异常：如果映射配置缺失或目标数据源不存在，工具会提供详细的错误信息：

❌ 部署检查失败，程序退出码: 1

部署失败：数据源映射验证不通过

失败的工作流: etl_daily
问题类型: 数据源映射关系不完整

❌ 详情:
  工作流 'etl_daily', 任务 'load_data':
    数据源 'dev_rds_mysql' 在目标环境中不存在，且未配置映射关系

建议修复方案:
  在 multi_environments.yaml 中添加数据源映射:
    datasource_mappings:
      "dev_rds_mysql": "prod_rds_mysql"

循环依赖检测：当工作流之间存在循环依赖时，工具会检测并报告：

❌ 部署检查失败，程序退出码: 1

检测到循环依赖，无法确定部署顺序

循环依赖关系:
  workflow_a → workflow_b → workflow_c → workflow_a

建议:
  请检查以上工作流的 DEPENDENT 或 SUB_PROCESS 任务配置，
  移除循环依赖后重新执行部署。

常见问题

Q: 部署后工作流状态为 OFFLINE？

A: 这是预期行为。工具部署后工作流默认为离线状态，需要手动上线或通过调度配置自动上线，这符合生产环境的变更控制要求。

Q: DEPENDENT 任务依赖映射失败？

A: 检查依赖的工作流是否已在目标环境中存在，或是否在当前部署批次中。工具会按拓扑顺序部署，确保依赖先于被依赖者部署。

Q: 如何处理跨账户部署？

A: 确保部署工具运行环境具有访问两个账户 Secrets Manager 的 IAM 权限，并配置适当的 VPC Peering 或 Transit Gateway 实现网络连通。

总结

本文演示了如何在 AWS 环境中自动化 DolphinScheduler 工作流的跨环境部署。通过采用该方案，客户可以将部署时间从数小时缩短到分钟级，同时消除配置漂移风险。

该方案与 AWS Well-Architected Framework 的卓越运营支柱保持一致，实现了一致、可重复、自动化的部署流程。结合 AWS Secrets Manager 进行凭证管理、AWS CodePipeline 进行 CI/CD 编排、Amazon S3 进行审计日志存储，为企业级数据平台提供了完整的 DevOps 解决方案。

价值维度	效果
效率提升	将手动配置时间从 30 分钟缩短到秒级
错误减少	自动化映射消除人为错误和配置漂移
合规审计	详细的部署报告支持企业合规要求
安全性	与 AWS Secrets Manager 集成，无明文凭证

适用场景：多环境数据平台的工作流发布管理、CI/CD 流水线中的自动化部署、需要满足合规审计要求的企业级数据工程团队。

*前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营，具体信息以中国区域官网为准。

本篇作者

AWS 架构师中心：云端创新的引领者

探索 AWS 架构师中心，获取经实战验证的最佳实践与架构指南，助您高效构建安全、可靠的云上应用

亚马逊AWS官方博客

在 AWS 上实现 DolphinScheduler 工作流的自动化跨环境部署

概览

方案收益

方案架构

核心组件

部署流程

前置条件

实施演练

步骤一：配置环境

步骤二：验证环境连接

步骤三：常规部署 – 批量部署工作流

步骤四：精细发布 – 任务级别控制

步骤五：集成 CI/CD 流水线

异常处理示例

常见问题

总结

本篇作者

AWS 架构师中心：云端创新的引领者

了解

资源

开发人员

帮助

亚马逊AWS官方博客

在 AWS 上实现 DolphinScheduler 工作流的自动化跨环境部署

概览

方案收益

方案架构

核心组件

部署流程

前置条件

实施演练

步骤一：配置环境

步骤二：验证环境连接

步骤三：常规部署 – 批量部署工作流

步骤四：精细发布 – 任务级别控制

步骤五：集成 CI/CD 流水线

异常处理示例

常见问题

总结

本篇作者

AWS 架构师中心： 云端创新的引领者

了解

资源

开发人员

帮助

AWS 架构师中心：云端创新的引领者