如何通过Spring Batch分块处理向AWS S3存储桶已有文件写入数据

S3本身不支持原生的随机追加写入，结合你当前的迁移阶段需求，有两个可直接落地的实现方案，都可以适配Spring Batch的分块处理流程，有效降低单次处理的数据量：

方案1：复用现有分段上传逻辑绑定Chunk配置 #

你当前已经在使用AWS SDK v2的uploadPart接口，只需要调整逻辑和Spring Batch的Chunk机制绑定即可，几乎不用重构核心代码：

• 调整Step的Chunk大小配置，设置为你能接受的单次处理量级，比如单条数据1KB的话可设置为200条/Chunk，1000条的接口返回会被拆分为5次Chunk处理
• 在自定义的FlatFileItemWriter<T>中维护两个全局状态：分段上传任务ID（uploadId）、已上传分片的ETag与编号映射列表
• Step启动时调用createMultipartUpload接口初始化S3分段上传任务，拿到uploadId
• 每处理完一个Chunk，就将当前Chunk序列化后的数据作为一个分片调用uploadPart接口上传，记录返回的ETag和对应分片编号
• Step执行完成后调用completeMultipartUpload接口合并所有分片，生成完整的S3对象

注意：S3分段上传最多支持10000个分片，除最后一个分片外单个分片最小大小为5MB，你可以根据单条数据的平均大小计算合理的Chunk阈值，避免触发S3接口限制。

方案2：本地临时文件分块追加后全量上传 #

如果你的单条数据体积很小，拆分后的Chunk达不到S3分片上传的最小5MB要求，可以选用这种实现成本更低的方案：

• 每个Chunk处理完成后，将序列化后的数据直接追加写入本地磁盘的临时文件
• Step执行完成后，调用SDK的putObject接口将完整的临时文件上传到S3，上传完成后删除本地临时文件即可
• Spring Batch本身提供了Step执行完成后的扩展回调点，可直接绑定临时文件清理逻辑，无需额外开发状态管理代码

选型建议 #

单批次总数据量超过100MB优先选方案1，内存占用更低，分片可断点续传，不会因为单次上传失败导致全量重传；单批次总数据量不足100MB直接选方案2即可，代码改动量最小。

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