基于AWS服务设计每日百万DynamoDB记录处理流程的方案咨询

整体架构流程 #

通过EventBridge定时触发，串联DynamoDB导出、ETL处理、文件分发、响应处理的全流程，具体步骤如下：

1. 定时触发与DynamoDB数据导出 #

• 用Amazon EventBridge设置每日低峰时段的定时规则，触发DynamoDB全表导出任务。
• 直接使用DynamoDB Export to S3功能，将100万条记录以Parquet/JSON格式导出到指定S3桶。这种方式不占用DynamoDB读写容量，避免影响在线业务，导出效率远高于自定义Scan操作。

2. 业务逻辑处理与请求文件拆分 #

• S3接收到导出文件后，自动触发AWS Glue ETL任务。
• 在Glue作业中加载导出数据，执行自定义业务逻辑（字段转换、规则校验等）。
• 配置Glue输出参数，指定单文件最大大小（如1GB）或单文件记录数上限（如1万条），Glue会自动将处理后的数据拆分为符合要求的请求文件，写入目标S3桶。

3. 请求文件发送至第三方应用 #

• 配置S3的PutObject事件，将新生成的请求文件路径推送至Amazon SQS队列。
• 部署Lambda函数作为SQS消费者，批量拉取消息后，根据文件路径读取S3文件，调用第三方应用API完成发送。
• 设置SQS可见性超时和3次重试机制，重试失败的消息转入死信队列（DLQ），留存待人工排查。

4. 响应文件处理与DynamoDB更新 #

• 约定第三方应用将响应文件写入指定S3桶，通过S3 PutObject事件触发Glue任务或Lambda函数。
• 加载响应文件，匹配原记录主键，生成DynamoDB批量更新请求。
• 使用DynamoDB BatchWriteItem API或Glue DynamoDB连接器批量更新记录。为避免触发DynamoDB限流，可控制批量写入大小、调整并发速率，或开启DynamoDB自动扩容。

关键故障点与应对方案 #

• DynamoDB导出失败：通过CloudWatch监控导出任务状态，失败时触发SNS告警；同时配置EventBridge重试机制（间隔1小时重试2次）。
• Glue任务失败：开启Glue自带的2次重试功能；通过CloudWatch Logs监控作业日志，失败时触发告警；作业中加入数据校验逻辑，将异常数据写入单独的S3“异常桶”，后续人工处理。
• 请求发送失败：死信队列留存失败请求，配合CloudWatch告警通知运维；Lambda中加入超时处理和幂等逻辑，避免重复发送导致第三方应用重复处理。
• 响应文件异常/丢失：S3中配置生命周期规则，保留响应文件至少7天；处理前先做MD5完整性校验，校验失败则触发告警，通知第三方重新生成响应。
• DynamoDB更新失败：BatchWriteItem返回未成功写入的项目，在代码中实现重试逻辑；监控DynamoDB写入吞吐量指标，接近阈值时调整批量写入参数，避免限流。

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