AWS Step Functions搭配EMR Add Step运行长驻流作业的问题咨询

• 成本过高：Step Functions按状态转换次数计费，长期运行的作业如果带有状态轮询、重试逻辑，会产生大量状态转换，累计成本远高于直接用EMR独立集群调度的方案。
• 故障恢复灵活性差：状态机如果因为内部错误、权限变更、EMR集群异常中断，整个执行实例会直接失败，无法无缝接续流处理进度，需要额外开发快照恢复逻辑嵌入工作流，复杂度很高。
• 资源占用冗余：长期运行的状态机执行实例会持续占用Step Functions的执行配额，同账号下如果部署多个这类作业，很容易占满配额导致其他工作流无法正常启动。
• 运维复杂度高：流处理作业的日常调试、参数调整都需要同步修改状态机配置，无法像直接运行在EMR上的作业那样灵活调整，问题排查需要同时核对Step Functions和EMR两套日志，定位难度翻倍。

• 最长执行时间限制：标准工作流的单个执行实例最大运行时长是1年，Express工作流只有5分钟，如果流处理作业需要运行超过1年，必须额外开发执行实例轮换逻辑，否则到期会被平台强制终止。
• 执行历史配额限制：单个执行实例最多保留25000条事件历史，超过配额后工作流会直接失败，长期运行的作业如果有频繁的心跳、重试、状态切换动作，很容易提前触达这个阈值。
• 吞吐量限制：长期运行的执行实例如果每秒的状态转换请求超过账号默认配额（不同区域默认值不同，通常为每秒几十次），会被平台限流导致状态更新失败，进而触发工作流异常。
• 历史保留限制：执行实例终止后，运行历史数据最多保留90天，超过后无法回溯历史运行信息，如果需要长期留痕要额外开发日志导出逻辑。

• 本身调用超时：Add Step的同步调用最长超时为60秒，如果提交请求时EMR集群负载高、响应慢，会直接导致API调用超时失败，这个失败只会影响步骤提交动作，不会影响已经提交完成的步骤运行。
• 步骤级超时配置：EMR Step本身默认无超时限制，但如果调用Add Step时手动配置了TimeoutSeconds参数，超过设定值后步骤会被EMR自动终止，未主动配置的情况下不会触发这个逻辑。
• 与Step Functions集成的超时：Step Functions的EMR Add Step状态默认有20秒的API调用超时，也可以通过TimeoutSeconds字段调整最长到900秒，如果这个值设置的比EMR集群响应提交请求的时间短，会出现Step Functions侧判定提交失败，但EMR侧实际上已经成功提交步骤的情况，导致重复提交作业。
• 心跳检测超时：如果EMR集群节点出现网络分区、EMR控制面异常，无法上报步骤运行状态，Step Functions侧会因为长时间收不到状态更新，触发内置的超时判定，标记步骤执行失败，但实际上作业可能还在EMR集群上正常运行。

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