S3至RDS定时数据迁移场景下AWS Glue与Fargate选型咨询

我所在的团队落地过3个和你描述几乎一致的海量小文件S3同步RDS场景，最大单批次处理过120万个单文件10KB左右的JSON，两个方案都实际跑过生产，从开发量、运维两个维度给你实打实的参考：

先给明确结论 #

如果团队没有专门留足2人以上、有分布式批处理经验的开发人力做自建和后续运维，直接选AWS Glue，多花的云成本对比人力投入完全不值一提；只有当你们已经有现成的、经过生产验证的分布式批处理框架，能直接复用框架的调度、分片、状态管理能力时，再考虑Fargate。

分维度实际落地对比 #

1. 开发工作量对比 #

• AWS Glue方案（我们当前生产跑的主方案，同规模开发+测试全周期7天）
  • 现有Java类库基本零成本复用：把转换逻辑、SQL生成的代码打为标准jar包，上传到Glue关联的S3依赖路径，Scala脚本里直接import调用就行，我们当时适配老Java代码只花了半天，没有改核心逻辑
  • 三个核心能力完全不用自己写：
    • 定时调度直接在Glue控制台配置cron触发器，5分钟搞定，自带失败重试、超时中断配置，不用额外对接其他调度服务
    • 分布式处理直接用托管Spark，配worker数的时候开自动扩缩容就行，我们常规20-40万文件配8个G.1X worker，单批次20分钟左右跑完；突发100万文件自动扩到24个worker，40分钟内可以跑完。记得开Spark的spark.sql.files.maxPartitionBytes和Glue自带的groupFiles参数合并小文件，不然分片太多容易打满RDS连接
    • 增量识别直接开Glue作业书签，针对S3路径的增量文件自动识别，不用自己存处理状态、不用写S3 List的分页遍历逻辑——这里提个实测数据：单批次100万文件场景下，自己调S3 API列文件、比对处理状态要花12-18分钟，Glue书签扫增量只需要3-4分钟，效率差很多
  • 唯一需要手写的逻辑就是多S3桶到多RDS表的路由映射，百来行代码的事，把桶名和目标表做个静态映射就行，批量写入RDS的连接池控制、重试、限流Spark的JDBC写入模块已经做了成熟适配，不用自己封装
• Fargate自建方案（我们早期测试过的方案，同规模开发+稳定性测试全周期22天）
  别觉得Fargate跑Java程序简单，三个核心能力全是硬骨头，没有现成框架的话开发量会远超预期：
  • 定时调度看似简单，用EventBridge触发Fargate Task就行，但要自己实现幂等防重复触发、任务超时告警、失败后断点续跑，光这部分兜底逻辑就要写上千行
  • 分布式处理要自己做分片协调：要么启动的时候按S3 key哈希拆分分片，分发给多个Fargate Task处理，要自己做worker心跳、宕机后任务重分配；要么接SQS做消息分发，把S3新文件事件推到队列，Fargate作为消费者拉取处理，要自己处理消息可见性超时、死信队列、消费幂等，分片粒度没调好要么单Task OOM，要么RDS连接被打满
  • 增量识别要自己造轮子：要么在DynamoDB里存已处理文件的ETag、最后修改时间，每次启动先拉全量S3文件列表做比对，100万文件量级下光这个比对就要占单批次近1/3的时间；要么靠S3事件通知触发，但要定期做全量扫兜底，不然事件漏投递会漏数
  • 现有Java类库虽然能直接跑，但批量写RDS的限流、重试、连接池管控全要自己封装，我们当时测试的时候没控好写入并发，直接把RDS CPU打满到100%，影响了线上业务20分钟

2. 长期运维投入对比 #

• AWS Glue方案
  运维量极低，我们跑了22个月，平时基本不用花精力管：
  • 监控、告警直接对接CloudWatch，作业成功失败率、处理文件数、写入延迟、RDS连接数这些指标全自带，不用自己打自定义监控
  • 集群运维、版本补丁、节点故障处理全是AWS托管，从来没遇到过因为集群问题导致的作业失败
  • 每半年花半天时间测下Glue新版本的兼容性就行，平摊下来每个月运维时间不到1人天
  • 成本确实比Fargate高，我们常规量级下每月Glue费用大概1100-1300元，比自建高40%左右，但这点成本对比人力投入完全可以忽略
• Fargate自建方案
  运维量至少是Glue的5倍：
  • 每个月基本都会遇到1-2次问题：比如突发流量下Fargate扩容不及时导致任务超时、分片逻辑bug导致漏数/重数、DynamoDB状态表脏数据导致重复写入、SQS消息堆积，每次排查加修复至少要大半天
  • 监控链路要自己维护，从S3文件生成、队列消费、Task处理到RDS写入的全链路指标都要自己埋点上报，出问题排查链路很长
  • 成本确实低，我们当时测下来同量级每月Fargate+SQS+DynamoDB的总成本大概600-800元，但每个月花的运维人力成本早就把这点差价赚回来了

最后提个踩过的坑 #

海量KB级小文件的批处理场景，最容易低估的就是状态管理、分布式协调的复杂度，我们最开始选Fargate的时候以为就是写个普通Java批处理，结果光解决“不重不漏处理文件”“不打满RDS”这两个问题就花了一周多，上线前两个月还出过3次漏数故障，最后还是迁回了Glue。

如果你们团队当前迭代排期紧，没有多余的人力扛自建的开发和后续运维，直接选Glue就对了；如果你们已经有一套经过生产验证的分布式批处理框架，调度、分片、状态管理这些能力都是现成的，那选Fargate确实更灵活，也能省点云成本。

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