将S3小文件复制合并至另一桶以优化AWS Athena查询性能的方案咨询

方案可行性评估 #

你当前设计的方案是可行的入门级方案，但算不上最优，存在多个容易被忽略的风险点和优化空间，具体如下：

现有方案的遗漏考虑点 #

• 重复消费/数据丢失风险：SQS默认是至少一次投递，如果你没有在Lambda处理完合并、写入目标桶、确认删除SQS消息之前做幂等校验，可能出现同一个文件被合并多次，或者处理失败导致消息回滚后重复处理，最终目标桶出现重复数据。
• 小文件长尾问题：如果业务波峰波谷明显，低峰期消息不足x条时，会一直积压小文件没法触发合并，导致目标桶长期存在大量小文件拖慢Athena查询性能。
• Lambda运行时长限制：如果x设置过大，读取、合并、写入大文件的耗时可能超过Lambda最多15分钟的运行时长上限，导致任务失败。
• 成本损耗：每次Lambda都要调用多次S3 GetObject接口，每秒1个文件的情况下，每天就是86400次S3读请求，加上SQS的请求费用，长期运行成本偏高。
• 数据格式兼容性问题：直接拼接JSON文件会导致合并后的文件不是合法的JSON数组或者JSON Lines格式，Athena查询的时候会直接报错，你需要额外处理格式，要么按行拼接存为.jsonl格式，要么包装为合法JSON数组。
• 分区适配问题：你没有提到按时间/业务字段做分区的设计，后续数据量上来后，Athena查询要扫描全量数据，性能还是会很差，Glue爬虫爬取全量文件的耗时也会越来越长。
• 源文件归档逻辑缺失：合并完成后的源桶小文件没有清理/归档逻辑，源桶的存储成本会持续增长。

更优的替代方案 #

• 首选方案：用AWS Kinesis Firehose做自动合并。直接把S3事件通知发送到Kinesis Firehose，配置缓冲区大小（比如64MB/128MB）和缓冲区间隔（比如5分钟/15分钟），Firehose会自动把小文件累积到阈值后合并写入目标bucket2，还支持直接转格式为Parquet/ORC等列存格式，Athena查询性能比纯JSON高3~10倍，不需要自己维护Lambda和SQS的逻辑，可靠性更高。
• 次选方案：定时批量合并+现有流式方案互补。保留现有SQS+Lambda的方案作为实时写入路径，同时额外加一个每天/每小时运行的Glue ETL任务，对目标桶过去一个周期的小文件做二次合并，同时清理重复、无效的小文件，解决低峰期长尾小文件的问题。

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