DynamoDB已有表添加GSI后，如何高效回填百万条数据的GSI属性？

针对100万条现有数据的GSI属性回填需求，结合DynamoDB的特性，推荐以下几个高效方案，按场景优先级排序：

方案1：低峰期用Scan + BatchWriteItem批量更新 #

这是最直接的实现方式，适合业务能接受低峰期少量性能影响的场景：

• 步骤：
  1. 用Scan API遍历全表，通过ExclusiveStartKey实现分页，每次获取100-200条数据（根据表的读写容量调整）
  2. 对每条记录，用现有属性计算出GSI的PK和SK
  3. 调用BatchWriteItem，将计算好的GSI属性以PUT操作批量写入（每次最多25条，符合DynamoDB批量操作限制）
  4. 循环执行直到所有数据处理完成
• 关键优化：
  • 只扫描必要属性：用ProjectionExpression指定只获取计算GSI键需要的属性+主键，减少数据传输量
  • 控制吞吐量：通过Limit参数和批量大小调整读写消耗，避免打满表的预置容量；如果是按需模式，监控CloudWatch消耗避免成本飙升
  • 幂等处理：更新前检查记录是否已存在GSI属性，跳过已处理的记录，防止重复操作
• 优缺点：实现简单，无需额外服务；但Scan会占用表的读容量，可能影响线上业务，必须在低峰期执行

方案2：全表导出到S3 + Lambda批量更新 #

适合不能占用DynamoDB读容量、对线上业务零影响的场景：

• 步骤：
  1. 用DynamoDB的全表导出功能，把所有数据导出到S3（该操作不占用表的读写容量，异步执行）
  2. 配置S3事件触发Lambda函数，当导出的Parquet/JSON文件生成时，触发Lambda处理
  3. 在Lambda中读取S3文件的批量数据，计算GSI的PK和SK，调用BatchWriteItem更新回DynamoDB
  4. 设置Lambda的并发数（比如50-100），控制更新速率，避免压垮DynamoDB
• 关键优化：
  • 用S3前缀过滤，避免重复处理同一文件
  • Lambda中用批量读取S3文件的方式，减少IO开销
  • 利用DynamoDB的BatchWriteItem失败重试机制，处理写入失败的条目
• 优缺点：完全不占用DynamoDB的读容量，对业务无影响；需要配置S3和Lambda，步骤稍多，但整体可控

方案3：AWS Glue ETL作业（适合超大规模数据） #

如果后续还有类似的批量数据处理需求，用Glue可以更自动化地完成：

• 步骤：
  1. 在AWS Glue中创建爬虫，连接目标DynamoDB表，生成数据表结构
  2. 创建Glue ETL作业，用Python或Scala编写脚本：读取DynamoDB数据，计算GSI属性，然后写回原表
  3. 配置作业的资源（比如DPU数量），设置读写速率限制，避免影响线上
  4. 触发作业执行，Glue会自动并行处理数据，无需手动分页和批量逻辑
• 关键优化：
  • 启用Glue的**动态帧（DynamicFrame）**处理，自动处理数据格式转换
  • 配置写回DynamoDB时的批量大小和并发数，控制吞吐量消耗
• 优缺点：自动化程度高，适合大规模数据；但需要熟悉Glue的配置，有一定学习成本，适合有ETL需求的团队

通用注意事项 #

• 临时调整容量：如果是预置读写容量模式，可临时提升容量到合适值，操作完成后再降回，避免等待时间过长
• 监控与告警：通过CloudWatch监控DynamoDB的ConsumedReadCapacityUnits、ConsumedWriteCapacityUnits和ThrottledRequests指标，及时调整处理速率
• 测试验证：先在测试环境用小批量数据验证方案，确认GSI属性计算正确、更新逻辑无问题后，再处理生产环境数据

内容的提问来源于stack exchange，提问作者Ajay Narain Mathur