批处理架构的隐藏成本：从 DynamoDB Bulk Executor 看限流与退出机制

2026 年 10 月 13 日，AWS 发布 DynamoDB Bulk Executor 的架构复盘。这款工具通过 AWS Glue 执行批量任务，同时提供本地命令行体验。文章披露了一个容易忽视的细节：用户按下 Ctrl+C，仅停止客户端并不会自动终止云端作业。团队因此增加中断处理，由监控循环主动请求停止 Glue 任务。AWS 原文

这一细节值得延伸讨论：当命令行背后连接着远程计算资源，“退出”其实是一项分布式协议。对平台团队而言，取消请求是否送达、远端是否停止、已经完成的修改是否保留，应当成为可观察的状态。界面消失并不意味着资源释放，也不意味着已经执行的写入被撤销。以上是本文的工程分析，并非该工具已具备完整回滚能力。

先分清性能优化和账单优化

DynamoDB 官方文档明确指出，Scan 的过滤表达式在读取完成后才应用；即使返回的数据更少，读取容量消耗也不会因此减少。扫描结果还需要按分页游标继续读取，单次结果不能代表整张表。Scan 文档

因此，评估批处理不能只看网络传输了多少数据。减少返回内容可能降低应用侧处理负担，但不应直接推导为数据库费用下降。建议把数据库消耗、计算时间和传输量分开记录，再判断优化落在哪一层。否则，一次明显变快的运行，也可能没有减少最主要的费用。

分布式限流需要反馈机制

AWS 此前公开的实现使用 S3 协调各工作进程：进程写入消耗状态，汇总线程生成共享结果，各进程据此调整本地速率。该方案还对调整幅度进行平滑处理，避免速率过度跳动。分布式限流说明

这提供了一种设计思路：在节点数量和负载持续变化时，固定分配额度可能不够灵活。不过，异步汇总意味着反馈存在延迟。将这类控制机制用于生产表前，团队仍需明确允许的突发量、状态过期后的行为，以及批任务与在线业务争用容量时的优先级。不能仅凭配置了一个上限，就默认获得任何时间窗口内都严格成立的保证。

把操作语义写进验收条件

官方选型文档指出，批操作方案需要结合事务、幂等性、数据规模以及成本与耗时权衡；Bulk Executor 是开源工具，不包含官方支持。批操作选型文档

据此，本文建议先用小范围任务验证四件事：失败后如何确认已完成的范围，重试是否产生重复副作用，停止请求如何核实，以及如何恢复误修改的数据。涉及删除或更新时，应先准备可验证的恢复路径。

这次复盘最有价值的启发，是把批处理当成有生命周期、有资源边界的系统。并行度决定任务能跑多快，而退出机制、限流反馈和操作语义，决定它能否被放心交给生产环境。