向AWS Timestream磁存储写入大量数据时数据丢失问题咨询

针对你的问题：向Timestream磁存储写入大量数据导致数据丢失而非排队，这不是预期行为，但确实和新表磁存储的冷启动扩容机制以及热点分区有关。

关键原因分析 #

1. 新表磁存储的渐进式扩容特性 #

新建的Timestream磁存储默认分区数量较少，当遭遇高吞吐量写入时，服务会启动分区扩容，但这个扩容过程是渐进式的（需要数分钟完成），而非瞬间完成。在扩容期间，若写入速率超过当前分区的处理能力，会出现部分写入请求无法被及时处理的情况。

2. 同一时间戳导致的分区热点 #

你的所有10万条记录都使用同一时间戳，而Timestream磁存储是按时间维度分区的——同一时间戳的所有记录会被分配到同一个磁存储分区。这种情况下，即使触发了扩容，热点分区的处理能力依然是瓶颈，无法承载批量写入的压力，最终导致部分记录无法被持久化。

3. 异步写入的结果未被正确捕获 #

Timestream磁存储写入是异步的，但WriteRecords API会返回RecordsIngested响应，其中包含MagneticStore字段的成功写入计数。你的Lambda函数可能没有校验每一批请求的返回结果，导致部分写入失败的情况未被发现（服务端不会主动抛出错误到日志桶，除非是严重的格式或权限问题）。

你的测试验证点对应解释 #

• 写入内存存储正常：内存存储的分区机制和处理逻辑与磁存储不同，且没有冷启动扩容的限制，能快速处理批量写入。
• 降低写入速率反而入库更少：降低速率后，可能未触发磁存储的扩容阈值，分区始终处于低处理能力状态，持续无法承载写入需求，导致更多记录丢失。
• 添加唯一维度无效：问题根源不是记录覆盖，而是分区处理能力不足，因此添加唯一维度无法解决。
• 第二次写入全部成功：第一次写入已经触发了磁存储的分区扩容和热点分区的预热，第二次写入时分区处理能力已经提升，能承载全部写入请求。

解决方案建议 #

• 分散时间戳：尽量将记录的时间戳分散开，让数据分布到多个磁存储分区，避免热点问题。
• 新表预热：在大规模写入前，先写入小批量数据触发磁存储分区扩容，等待数分钟后再执行正式写入。
• 校验API返回结果：在代码中捕获每一次WriteRecords的RecordsIngested.MagneticStore计数，与批次大小对比，对写入失败的批次进行重试。
• 控制写入速率：在新表场景下，避免瞬间压入大量请求，可通过逐步提升写入速率的方式，让磁存储有足够时间完成扩容。

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