DynamoDB亚秒级延迟升高为何导致Spark应用整体延迟上涨6倍

1. 成功请求延迟的统计偏差 #

你在CloudWatch看到的DynamoDB PutItem 平均延迟是仅统计成功请求的服务端处理耗时，不包含两类隐性耗时：

• 被限流请求的指数退避等待时间：DynamoDB写入容量不足时会返回ThrottlingException，AWS SDK默认会自动重试，重试间隔按指数退避规则从几十ms逐步涨到几秒，这部分等待时间不会被计入DynamoDB服务端的latency指标，但会直接累加进Spark作业的处理耗时
• 请求在客户端的排队耗时：你的Spark作业用的DynamoDB客户端连接池、请求线程池容量是固定的，单条请求处理耗时变长会导致连接/线程被快速占满，后续请求需要排队等待空闲资源，排队耗时会随着请求延迟上涨呈非线性增长

2. 批处理场景的延迟叠加效应 #

你的作业单批要处理20万条写入请求，假设你配置的DynamoDB写入并行度是固定的：

• 常规情况下单条请求总耗时（客户端+服务端+网络）约5ms，每秒可处理 并行度 * 200 条请求，30秒刚好处理完20万条
• 当服务端latency涨1.5ms后，叠加排队、重试耗时，单条请求总耗时可能涨到20ms以上，单秒处理能力直接降到原来的1/4，处理时间自然翻数倍

3. 作业调度的恶性循环 #

你的作业是每分钟调度一次，当单次作业处理耗时超过1分钟后，会出现作业堆积：后一次调度的作业启动后，会和未跑完的前序作业争抢DynamoDB的写入吞吐量，进一步加剧限流问题，形成「延迟升高→作业堆积→争抢资源→延迟进一步升高」的负循环，最终耗时涨到3分钟。

• 查看DynamoDB CloudWatch指标的WriteThrottleEvents项，确认延迟升高时段是否有明显的限流事件
• 抽查Spark Executor日志，搜索ThrottlingException关键字，统计单批作业的DynamoDB请求重试次数，正常重试次数应该远低于1%，异常场景下重试次数可能达到30%以上
• 核算实际写入DynamoDB的总请求数（含重试），异常场景下总请求数可能是20万的数倍

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