关于使用AWS S3 Pre-signed URL实现JSON数据批量存储的优化方案咨询

嗨，这个场景我之前帮团队解决过类似的问题，给你几个接地气的方案和分析，应该能帮到你！

首先先明确：你提到的S3 multipart upload其实不太适合你的需求。它的核心是用来处理单一大文件的分块并行上传（比如几百MB/GB的文件拆成5MB以上的分片），最后合并成完整文件。但你的场景是每隔60秒生成一小段新数据，要避免加载历史JSON，用multipart反而会增加不必要的复杂度——比如每次要初始化上传、传分片、完成上传，流程繁琐，而且你的小数据块远小于multipart要求的最小分片大小（除最后一个分片外，至少5MB），完全没必要折腾这个。

下面是两个更适合你的方案：

方案一：按时间/会话拆分小文件存储（最推荐） #

这是我当时用下来最省心的方案，完全贴合你的需求：

• 客户端逻辑：不用再维护单个大JSON，每隔60秒就生成一个只包含这60秒操作数据的小JSON文件，用预签名URL直接PUT到S3。文件名要设计得有规则，比如user_123_session_xyz_20240520_1430.json，里面就存[{"action":"click", "time":"..."}, ...]这样的数组。
• 优势：客户端完全不用加载任何历史数据，每次只传几KB/几十KB的新数据，预签名URL用普通的PUT请求就行，代码逻辑超简单。
• 后续分析处理：
  • 临时分析：用S3 Select直接查询某个用户的所有小文件，过滤出需要的时间段数据，不用下载所有文件；
  • 定期合并：如果一定要生成单个大JSON，可以写个Lambda函数，触发条件是S3有新文件上传，让Lambda自动把新数据合并到该用户的主JSON文件里（这个过程在云端完成，客户端完全感知不到）；
  • 批量分析：用Athena创建表，直接按用户ID、时间戳等维度查询所有小文件的聚合数据，效率很高。

方案二：模拟S3文件追加写入（适合必须单文件的场景） #

如果业务上必须最终是单个JSON文件，又不想客户端加载历史数据，可以这么做：

• 客户端：每次把60秒的操作数据序列化成JSON数组字符串（比如[{"a":1}, {"b":2}]），用预签名URL上传到S3的一个临时位置（比如user_123/temp/20240520_1430.json）；
• 云端处理：用S3事件触发Lambda，Lambda读取这个临时文件的内容，再读取用户主JSON文件的最后部分（把末尾的]替换成, 新数据]），然后重新上传主文件；
• 注意点：这个方案需要Lambda处理文件的修改，虽然客户端不用加载历史数据，但云端会有一定的IO操作，适合用户操作频率不高的场景，否则频繁修改主文件可能会有版本冲突，需要加锁或者用S3的版本控制来处理。

总结 #

优先选方案一，简单高效，完全规避了客户端加载大文件的问题，后续分析的灵活性也最高。Multipart upload对你的场景来说有点杀鸡用牛刀，不建议用。

备注：内容来源于stack exchange，提问作者Askish