多源异构RDS数据库AWS数据迁移方案咨询：DMS及DMS+Lambda可行性

1. 仅通过AWS DMS能否实现需求？ #

不能。AWS DMS的核心定位是源数据库到目标数据库的直接数据迁移/同步，虽然支持字段映射、格式转换规则，但无法在迁移流程中主动连接第三个外部数据库（clientdb3）获取补充数据。DMS任务仅支持配置单一源端（或多源合并到同一目标，但无法在迁移逻辑中跨库执行关联查询），所以无法满足“从clientdb1取数后，再从clientdb3获取补充信息插入clientdb2”的需求。

2. DMS+Lambda组合是否为最优解？ #

这个方案可行，但并非所有场景下的最优解，需结合数据量、迁移类型（全量/增量）判断：

方案可行性分析 #

你的方案逻辑通顺：

• 步骤1：用DMS将clientdb1的users数据全量/增量同步到clientdb2的临时表，可利用DMS的字段转换能力适配临时表结构。
• 步骤2：通过Oracle触发器触发Lambda，或用DMS的CDC事件（如推送到Kinesis Data Streams后触发Lambda），在Lambda中读取临时表的新记录，连接clientdb3查询users_profile的补充信息，再写入clientdb2的正式users表。

该方案的优缺点 #

• 优点：
  • 复用DMS成熟的迁移能力处理源到临时表的同步，减少自定义迁移逻辑的工作量。
  • Lambda按需执行，适合小批量、增量同步场景，成本可控。
• 缺点：
  • 若为大数量级全量迁移，单条记录触发Lambda会导致性能瓶颈，且调用成本上升。
  • 临时表的管理（如清理已处理数据）需要额外逻辑，增加架构复杂度。
  • Lambda存在最大15分钟的执行时长限制，若单条记录的跨库查询+插入逻辑复杂，可能出现超时问题。

更优替代方案推荐 #

如果是全量迁移为主，或数据量较大，推荐使用AWS Glue ETL：

• 在Glue作业中同时连接三个数据库：读取clientdb1的users表、clientdb3的users_profile表，通过用户ID等关联键完成数据整合、字段映射转换，直接写入clientdb2的users表。
• 优势：
  • Glue支持分布式处理，适配大数据量全量迁移，性能更优。
  • 统一的ETL逻辑，无需临时表和触发器，架构更简洁。
  • 支持定时调度，可重复执行，便于数据校验和重跑。

如果是增量同步需求，可结合DMS CDC + Lambda/Kinesis Data Firehose：

• 用DMS捕获clientdb1的users表增量变更，推送到Kinesis Data Streams。
• 用Lambda消费流中数据，查询clientdb3获取补充信息后写入clientdb2；或用Firehose结合自定义转换Lambda，批量处理后写入。

总结 #

• 仅DMS无法满足需求；
• DMS+Lambda适合小批量增量同步场景；
• 全量/大数据量场景下，AWS Glue ETL是更优选择。

内容的提问来源于stack exchange，提问作者Xmus Jackson Flaxon Waxon