AWS PostgreSQL多库多表复制到Redshift的最优方案咨询

针对你提出的多PG库全量同步到Redshift的需求，以下是AWS生态内几个可行方案的对比和选型建议：

方案1：AWS Glue ETL（你当前考虑的方案） #

• 优势
  • 完全托管服务，无需维护底层计算资源，支持同时对接多个PostgreSQL数据源，90张表的元数据可通过Glue爬虫自动扫描获取，无需手动建表映射
  • 全量同步逻辑开发成本低，支持批量配置多表同步任务，小表可并行执行，大表自动分片处理，1.5亿条记录的表使用Spark引擎处理完全可以覆盖30分钟的同步窗口
  • 原生支持EventBridge定时触发，30分钟调度配置简单，可直接对接CloudWatch做运行监控和异常告警
• 劣势
  • 大表频繁全量扫描源库会对源PostgreSQL造成一定查询压力，建议对接只读副本避免影响业务
  • 按量计费模式下，大表同步的成本略高于其他轻量方案

方案2：Redshift COPY + Lambda + EventBridge 组合方案 #

• 优势
  • 成本最低，加载效率最高：先通过Lambda触发将PG表全量导出到S3，再调用Redshift原生COPY命令批量加载，1.5亿条记录的表加载耗时仅需要3-5分钟，完全满足时效要求
  • 对源库影响小：导出操作可直接走只读副本，S3中间层可做数据备份，加载失败可以直接回滚
  • 调度灵活：EventBridge 30分钟触发Lambda即可，可自行控制小表批量并发、大表单独调度的逻辑
• 劣势
  • 需要自行开发多源连接管理、表结构变更适配、失败重试的逻辑，开发量比Glue高
  • 扩展性差，后续如果需要增加数据清洗、增量同步的需求需要重构整条链路

方案3：AWS DMS（数据库迁移服务）方案 #

• 优势
  • 零代码配置，直接在控制台配置7个PG为源端、Redshift为目标端即可，自动处理表结构映射，可自行配置源库压力上限，避免影响业务
  • 扩展性强，如果后续需要从全量刷新切换为增量同步，直接修改任务配置即可，无需重构链路
• 劣势
  • 定时调度灵活度低，30分钟触发全量任务需要配合EventBridge调用DMS API实现，没有Glue的调度原生方便
  • 90张表分优先级调度需要额外开发控制逻辑，批量任务管理成本较高

选型参考 #

• 如果你后续有数据清洗、数仓建模的规划，优先选AWS Glue，开发效率最高，和AWS大数据生态集成度最好，完全满足当前需求
• 如果你没有复杂数据处理需求，想要最低成本，优先选Redshift COPY + Lambda方案，运维成本和资源成本都是最低的
• 如果你后续计划切换为增量同步，不想写ETL代码，优先选AWS DMS，配置门槛最低，同步链路稳定性最高

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