S3流式JSON数据与Redshift表关联的最优实现方案咨询

方案1：Redshift Spectrum + Lambda自动分区注册（优先推荐，完全匹配数据留存在S3的核心需求） #

该方案直接解决原Redshift Spectrum方案的所有痛点：

• 替换定时运行的Glue Crawler，改用S3对象创建事件触发Lambda执行分区注册，新文件写入S3后秒级即可完成元数据同步，无15分钟的定时延迟，满足近实时查询要求
• 不存在爬取任务冲突问题：Lambda仅针对新写入对象的所属分区执行ALTER TABLE <external_table> ADD PARTITION命令，单次执行耗时低于1秒，无全量扫描逻辑，不会出现任务重叠冲突
• 数据全程留存在S3中，无需导入Redshift本地存储，Redshift Spectrum可直接完成S3外部表与Redshift本地表的关联查询，无需使用Athena

配置提示：S3写入时按照时间/业务维度设置分区前缀（例如s3://your-bucket/dt=2024-06-15/hour=14/），Lambda仅需要从新对象的S3路径中提取分区键值即可完成注册，无需额外扫描。

方案2：缓冲队列优化的Lambda+COPY批量导入（适合热数据低延迟查询场景） #

该方案解决原Lambda触发COPY方案的高并发连接问题：

• S3对象创建触发后不直接建立Redshift连接执行COPY，先将新对象的S3路径写入SQS标准队列做缓冲削峰
• 配置定时Lambda（例如每1分钟执行1次），批量拉取队列中积攒的所有S3路径，仅建立1次Redshift连接即可完成整批次对象的导入，单批次可合并上千个对象的导入任务
• 可灵活控制定时Lambda的最大并发数，从根源上避免Redshift连接数过高导致的服务异常

存储优化提示：如果不需要全量数据长期留存Redshift，可配置定时任务定期清理冷数据，仅保留最近7/30天的热数据即可，不会占用Redshift的大量存储资源。

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