Amazon EMR配置：仅在前序定时任务完成后启动新任务

这个问题我之前帮好几个开发者踩过坑——CloudWatch Events本身确实没有直接的「任务未完成则跳过」开关，但咱们有几个靠谱的方案可以实现这个需求，我给你拆解一下：

方案1：CloudWatch Events + Lambda 检查集群状态（最直接的轻量方案） #

核心思路是把原来直接启动EMR的定时触发，改成先触发Lambda函数做状态检查，再决定是否启动新集群：

• 第一步：修改你的CloudWatch Events规则，把目标从「启动EMR集群」换成「触发Lambda函数」。
• 第二步：在Lambda函数里编写逻辑：
  1. 调用EMR的list-clusters API，过滤出状态为STARTING/RUNNING/WAITING的集群，同时匹配你给定时任务集群打的专属标签（比如给这类集群加TaskType:2HourlyDataSync的标签，方便精准过滤）。
  2. 如果查询结果为空（没有正在运行的目标集群），就调用run-job-flow API启动新集群；如果有正在运行的集群，直接跳过执行，或者打个日志记录一下就行。
• 权限配置：给Lambda的IAM角色加上elasticmapreduce:ListClusters和elasticmapreduce:RunJobFlow的权限，确保能正常调用EMR API。

举个Lambda里的Python代码片段参考（核心逻辑）：

import boto3

emr_client = boto3.client('emr')

def lambda_handler(event, context):
    # 查询符合条件的运行中集群
    response = emr_client.list_clusters(
        States=['STARTING', 'RUNNING', 'WAITING'],
        Filters=[
            {
                'Name': 'tag:TaskType',
                'Values': ['2HourlyDataSync']
            }
        ]
    )
    # 如果没有运行中的集群，启动新集群
    if not response['Clusters']:
        emr_client.run_job_flow(
            # 这里填你原来的EMR集群配置：Name、ReleaseLabel、Instances、Steps等
            Name='2-Hourly-Data-Processing',
            ReleaseLabel='emr-6.10.0',
            # ... 其他原有配置
            Tags=[{'Key': 'TaskType', 'Value': '2HourlyDataSync'}]
        )
    else:
        print("已有运行中的任务集群，跳过本次启动")

方案2：用AWS Step Functions编排（更优雅的可扩展方案） #

如果你的任务后期可能需要加分支逻辑、失败告警或者多步骤协调，Step Functions是更好的选择——它内置了状态流转和等待逻辑，能完美处理任务依赖：

• 构建一个状态机，流程大致是：
  1. 检查EMR状态：调用和方案1一样的Lambda函数，判断是否有运行中的集群。
  2. 分支判断：如果没有运行中的集群，进入「启动EMR集群」状态；如果有，进入「跳过执行」状态直接结束。
  3. 等待集群完成：启动集群后，可以用Step Functions的Wait任务配合轮询EMR状态，或者直接监听EMR的CloudWatch事件来触发状态机流转。
• 最后把CloudWatch Events的触发目标改成这个Step Functions状态机即可。

这个方案的优势是可视化管理流程，后期加告警、重试逻辑都很方便，适合复杂的任务编排场景。

方案3：DynamoDB分布式锁（最灵活的跨服务方案） #

如果你的任务不止EMR，还有其他上下游服务需要协调执行顺序，可以用DynamoDB做一个简单的分布式锁：

• 提前创建一个DynamoDB表，主键设为lock_id（字符串类型）。
• 每次定时任务触发时，先尝试向表中写入一条锁记录：
  • 主键值设为EMR_2Hourly_Task_Lock，同时设置TTL（比如2.5小时，比你的定时周期略长，防止异常情况锁一直存在）。
  • 写入时用ConditionExpression: attribute_not_exists(lock_id)，确保只有当锁不存在时才能写入成功。
• 如果写入成功，启动EMR集群；如果写入失败，说明有任务在运行，直接跳过。
• 当EMR集群正常完成后，再触发Lambda删除这条锁记录（或者让TTL自动过期）。

注意：如果集群异常终止，要记得加兜底逻辑（比如用CloudWatch告警监听EMR的FAILED状态，触发Lambda删除锁），避免锁一直占用导致后续任务无法启动。

总结 #

• 简单场景直接用方案1，快速实现，成本低；
• 需要可视化流程或扩展逻辑选方案2，后期维护更省心；
• 跨服务协调用方案3，灵活性最高。

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