DolphinScheduler 3.4.2：EMR Serverless 插件落地，补数据与安全治理全面加固

预计阅读时间：10 分钟

Apache DolphinScheduler 3.4.2 作为 3.4.x 系列的维护版本，没有停留在"修修 bug"的层面。社区在这次发布中塞进了不少实打实的新能力——Amazon EMR Serverless 任务插件让无服务器计算场景有了原生支持，监控中心做了可见性增强，补数据流程、权限控制、安全治理和底层架构也都动了刀。如果你正在用 3.4.x，这个版本值得认真看一眼。

EMR Serverless 任务插件：跑批不再自己管集群

3.4.2 新增了 Amazon EMR Serverless 任务插件，直接在 DolphinScheduler 工作流里提交 Spark 或 Hive 作业到 EMR Serverless 应用，省掉自管 EMR 集群的运维负担。

实际使用时，你需要在 DolphinScheduler 中创建 EMR Serverless 类型的任务节点，配置好 AWS 区域、应用 ID 和作业参数。一个最小可用的任务定义大致如下：

# DolphinScheduler EMR Serverless 任务配置示例
taskType: EMR_SERVERLESS
taskParams:
  # AWS 区域，与你的 EMR Serverless 应用一致
  region: us-east-1
  # EMR Serverless 应用 ID（需提前在 AWS 控制台或 CLI 创建）
  applicationId: "00x1y2z3a4b5c6d7e8f9g0h1i2j3k4l"
  # 作业运行配置
  executionRoleArn: "arn:aws:iam::123456789012:role/EMRServerlessExecutionRole"
  jobDriver:
    # Spark 提交参数
    sparkSubmit:
      entryPoint: "s3://my-bucket/scripts/etl_job.py"
      entryPointArguments: ["--date", "${system.biz.date}"]
      sparkSubmitParameters: "--conf spark.executor.memory=2G --conf spark.driver.memory=1G"
  configurationOverrides:
    monitoringConfiguration:
      s3MonitoringConfiguration:
        logUri: "s3://my-bucket/logs/"

运行前需要确认的事项：

AWS IAM 执行角色已授予 EMR Serverless 所需权限（emr-serverless:StartJobRun 等）。
EMR Serverless 应用已创建并处于 STARTED 状态，可用 AWS CLI 检查：

aws emr-serverless list-applications --region us-east-1
# 确认返回的 applicationId 与配置一致，state 为 STARTED

DolphinScheduler 服务器能访问 AWS API（网络、VPC 端点或公网出口）。

监控中心增强：从"能看到"到"能定位"

3.4.2 对监控中心做了增强，重点不在仪表盘变漂亮，而是让你更快定位问题节点。增强方向包括：

工作流实例状态聚合：不再只看单条任务日志，能在监控面板直接看到某批次工作流的失败节点分布。
告警阈值细化：支持按任务类型、工作流维度设置不同告警规则，避免全局阈值导致噪音过多。
历史趋势对比：补数据场景下可以对比正常日与补数据日的执行时长差异，快速发现资源瓶颈。

这些改进对夜间补数据值班场景尤其有用——失败任务集中在哪几个节点、是不是同一类插件出问题，一眼就能看出轮廓。

补数据场景优化：批量跑历史不再踩坑

补数据（backfill）是调度系统的高频痛点。3.4.2 在这块做了针对性优化：

批量补数据参数传递：多天补数据时，日期参数能正确传递到每个子工作流，不再出现"第一天跑了后面几天没参数"的情况。
补数据依赖检查：补数据工作流的依赖关系检查与正常调度一致，避免上游未完成就触发下游。
补数据实例隔离：补数据实例与正常调度实例在监控面板分开展示，不会互相淹没。

一个典型的补数据命令行调用：

# 通过 DolphinScheduler API 批量补数据（示例）
curl -X POST "http://ds-server:12345/dolphinscheduler/projects/{projectCode}/process-definition/{processCode}/schedule/create" \
  -H "Content-Type: application/json" \
  -H "token: your-api-token" \
  -d '{
    "schedule": "0 0 2 * ?",
    "warningType": "FAILURE",
    "warningGroupId": 1,
    "processInstancePriority": "MEDIUM",
    "workerGroup": "default",
    "environmentCode": -1
  }'

# 补数据时指定日期范围
curl -X POST "http://ds-server:12345/dolphinscheduler/projects/{projectCode}/execute-process/{processCode}" \
  -H "Content-Type: application/json" \
  -H "token: your-api-token" \
  -d '{
    "scheduleTime": "2025-01-01 00:00:00,2025-01-10 00:00:00",
    "failureStrategy": "END",
    "startNodeList": "",
    "taskDependType": "TASK_POST",
    "execType": "COMPLEMENT_DATA",
    "runMode": "RUN_MODE_SERIAL",
    "processInstancePriority": "HIGH",
    "workerGroup": "default",
    "dryRun": 0
  }'

注意 scheduleTime 用逗号分隔起止日期，execType 设为 COMPLEMENT_DATA，runMode 选串行或并行取决于上游依赖是否允许并行回填。

安全治理与权限控制：细到操作级别

权限方面 3.4.2 不再只做"谁能看哪个项目"的粗粒度控制，而是往操作级别收紧：

细粒度权限：工作流定义的创建、编辑、删除、上线可以分别授权，不再一给就全给。
数据源权限隔离：不同团队只能访问授权范围内的数据源连接，避免误操作跨库。
审计日志增强：关键操作（删除工作流、强制杀实例、修改数据源密码）写入审计日志，可追溯。

如果你是多团队共用一套 DolphinScheduler，这些权限细化直接决定了能不能放心开放平台。

底层架构优化：稳定性从内部开始

3.4.2 在底层做了不少"用户看不到但能感受到"的改动：

Master 与 Worker 之间的心跳与任务分发机制做了容错增强，减少网络抖动导致的误判失败。
任务插件加载机制重构，新增插件不再需要改核心代码，扩展性更好——EMR Serverless 插件本身就是这个机制的产物。
数据库连接池与事务管理优化，高并发补数据场景下数据库压力更可控。

升级建议与注意事项

从 3.4.0 或 3.4.1 升级到 3.4.2，整体是平滑的，但有几件事要提前确认：

检查项	说明
数据库 schema	执行升级 SQL 脚本（`sql/upgrade/3.4.2/`），权限表有新增字段
自定义任务插件	新插件加载机制兼容旧插件，但自定义插件需确认是否依赖了被移除的内部 API
EMR Serverless 网络	如果要用新插件，先确认 Worker 节点到 AWS API 的网络通路
告警规则	监控中心增强后告警维度变了，旧规则需要重新对齐新的配置格式

升级步骤简要：

# 1. 备份数据库
mysqldump -h ds-db -u root -p dolphinscheduler > ds_3.4.1_backup.sql

# 2. 执行 schema 升级
mysql -h ds-db -u root -p dolphinscheduler < sql/upgrade/3.4.2/dolphinscheduler_dml.sql
mysql -h ds-db -u root -p dolphinscheduler < sql/upgrade/3.4.2/dolphinscheduler_ddl.sql

# 3. 替换二进制包，重启服务
tar -xzf apache-dolphinscheduler-3.4.2-bin.tar.gz
# 按你的部署方式（standalone / cluster / docker）重启各组件

风险边界：如果你在 3.4.x 上有大量自定义插件或深度定制了权限逻辑，升级前务必在测试环境跑一轮完整回归。权限表结构变了，直接跳过升级脚本会导致权限校验异常。

3.4.2 不是一个大版本跳跃，但它的改动方向很明确——让补数据不再踩坑、让权限能管到操作级、让 EMR Serverless 场景有原生支持、让监控能真正定位问题。如果你在日常调度中遇到过这些痛点，升级的收益是直接的。