同一AWS账号内迁移DynamoDB表并修改数据结构的最优方案咨询

以下是几种针对不同场景的实用方案，覆盖全量/增量、小/大数据量的需求：

1. Lambda + DynamoDB Streams（实时增量迁移首选） #

• 操作步骤：
  1. 给源DynamoDB表开启DynamoDB Streams，捕获所有数据变更（插入、更新、删除）
  2. 创建Lambda函数，订阅该流
  3. 在Lambda代码里编写数据转换逻辑：比如重命名字段、拆分/合并属性、新增计算字段等
  4. 将转换后的数据写入目标DynamoDB表
• 优势：实时同步数据变更，无需手动触发，适合持续同步的场景；Lambda按调用量计费，成本可控
• 注意点：
  • 处理流数据时要做幂等性校验，避免重复写入
  • 开启Lambda的批量处理模式，减少函数调用次数，提升效率
  • 配置错误重试和死信队列，避免丢失数据

2. AWS Glue ETL（全量大数据量迁移首选） #

• 别被之前的误解限制，Glue本身就是做数据转换的ETL工具，完全支持异构结构迁移：
  1. 创建Glue爬虫，爬取源DynamoDB表，自动生成数据Schema
  2. 创建Glue Job（用PySpark或Scala编写），在Job里实现自定义转换逻辑：比如字段映射、数据格式转换、过滤无效数据等
  3. 配置Job的输出为目标DynamoDB表，执行Job完成全量迁移
• 优势：原生支持DynamoDB和大规模数据处理，能自动并行处理，适合TB级别的大表迁移；可以定时触发，支持增量同步（结合Glue书签）
• 注意点：
  • 提前配置Glue的IAM角色，确保有DynamoDB的读写权限和Glue的相关权限
  • 测试阶段用小数据集验证转换逻辑，避免全量迁移出问题

3. 自定义SDK脚本（小数据量/高度自定义场景） #

• 用boto3（Python）或其他AWS SDK编写脚本，灵活控制整个流程：
  1. 用scan或query API分页读取源表数据
  2. 对每条数据执行结构转换操作
  3. 用batch_write_item API批量写入目标表，减少API调用次数
• 优势：完全自定义逻辑，适合有特殊转换需求的场景；无需依赖额外服务，开发成本低
• 注意点：
  • 控制扫描速率（通过Limit参数或调整读取容量），避免影响源表的正常业务
  • 加入异常捕获和重试机制，处理写入失败的情况
  • 大表分批次处理，避免内存溢出

4. PartiQL + 批量操作（简单结构转换场景） #

• 如果只是简单的字段重命名、新增固定字段等轻量转换，可以用PartiQL简化操作：
  1. 用PartiQL的SELECT语句查询源表数据
  2. 转换数据结构后，用PartiQL的INSERT语句写入目标表；或者结合BatchWriteItem批量写入
• 优势：语法类似SQL，上手快，适合简单转换需求
• 注意点：PartiQL单次查询有数据量限制，大表还是要结合分页处理

通用最佳实践 #

• 迁移前先在测试环境验证转换逻辑和性能，确保数据正确性
• 目标表提前配置合适的读写容量（或开启按需模式），避免因写入量过大被限流
• 全量迁移后，建议用Lambda Streams做一段时间的增量同步，确保新旧数据完全一致
• 迁移完成后，对比源表和目标表的数据量，验证迁移完整性

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