如何为每周Glue作业动态调整DynamoDB RCU并避免影响生产？

针对你需要每周调度Glue作业从DynamoDB迁移数据到Redshift的需求，我整理了几个靠谱的自动化方案，既能提升迁移速度，又能确保生产流量不受影响：

1. 用AWS Step Functions编排完整工作流（推荐） #

这是最可控的端到端方案，把RCU调整、Glue作业执行、RCU恢复串成一个自动化流程，全程无需人工干预：

• 步骤1：保存原始RCU配置
  调用DynamoDB的DescribeTable API获取当前表的预置RCU值，将其存在Step Functions的状态变量中，作为后续恢复的基准。
  示例boto3代码片段：

  import boto3
  dynamodb = boto3.client('dynamodb')
  response = dynamodb.describe_table(TableName='your-target-table')
  original_rcu = response['Table']['ProvisionedThroughput']['ReadCapacityUnits']
  

• 步骤2：临时提升RCU
  调用UpdateTable API将RCU设置为目标值（比如1500），然后等待表状态变为ACTIVE——可以用Step Functions的Wait状态轮询确认，或者结合Lambda用WaitForTaskToken机制。

• 步骤3：执行Glue作业
  在Step Functions中直接触发Glue作业，并配置等待作业完成的状态（Step Functions原生支持追踪Glue作业的执行状态）。

• 步骤4：恢复原始RCU
  作业成功完成后，再次调用UpdateTable API将RCU恢复到之前保存的original_rcu值。

• 调度配置
  用Amazon EventBridge给Step Functions状态机设置每周定时触发规则，比如每周日凌晨低峰期执行。

  注意：由于你已经开启了DynamoDB自动扩缩容，恢复RCU时一定要用作业启动前的原始预置值，而非当前的RCU，避免覆盖自动扩容的结果。

2. 在Glue作业脚本中直接集成RCU调整逻辑 #

如果不想额外维护Step Functions，可以把RCU调整逻辑直接嵌入Glue作业的Python脚本：

• 在作业开头添加代码，获取并保存当前RCU值；
• 调用API提升RCU，确认表状态正常后再执行迁移逻辑；
• 用try-finally块兜底，确保即使作业中途失败，RCU也能恢复：

  import boto3
  import time
  
  dynamodb = boto3.client('dynamodb')
  table_name = 'your-target-table'
  target_rcu = 1500
  
  # 保存原始RCU配置
  original_rcu = dynamodb.describe_table(TableName=table_name)['Table']['ProvisionedThroughput']['ReadCapacityUnits']
  
  try:
      # 临时提升RCU
      dynamodb.update_table(
          TableName=table_name,
          ProvisionedThroughput={'ReadCapacityUnits': target_rcu}
      )
      # 等待表状态变为ACTIVE
      while True:
          table_status = dynamodb.describe_table(TableName=table_name)['Table']['TableStatus']
          if table_status == 'ACTIVE':
              break
          time.sleep(30)
      
      # 执行你的数据迁移核心逻辑
      # ... 这里写原本的Glue迁移代码 ...
  
  finally:
      # 恢复原始RCU，无论作业成功或失败
      dynamodb.update_table(
          TableName=table_name,
          ProvisionedThroughput={'ReadCapacityUnits': original_rcu}
      )
  

  注意：要给Glue作业的执行角色添加dynamodb:DescribeTable和dynamodb:UpdateTable权限；同时可以配置CloudWatch告警，监控作业失败事件，避免极端情况下RCU未恢复。

3. 利用DynamoDB Auto Scaling临时调整策略 #

如果你已经在用DynamoDB自动扩缩容，可以通过临时修改Auto Scaling策略实现RCU动态调整：

• 创建临时目标追踪策略，将RCU的最小值和最大值都设置为目标值（比如1500），覆盖原有策略；
• 等待Auto Scaling将RCU调整到目标值（通常几分钟内完成）；
• 启动Glue作业，完成后恢复原来的Auto Scaling策略（改回原有最小/最大RCU配置）；
• 同样可以用EventBridge定时触发策略调整和作业执行流程。

替代方案：换迁移方式，完全避开RCU占用 #

如果不想调整RCU，还可以采用对生产流量零影响的迁移方式：

• DynamoDB导出到S3 + Glue迁移：利用DynamoDB原生导出功能，每周定时将表数据导出到S3（该操作基于底层快照，不占用RCU，对生产读写无干扰），再用Glue作业从S3读取数据迁移到Redshift。这种方式迁移速度更快，且完全隔离生产流量与迁移流量。
• 优化Glue作业并行度：在Glue作业中启用DynamoDB并行扫描，配置合理的分片数，提升读取效率的同时避免集中消耗RCU；同时增加Glue作业的DPU数量，提升整体处理能力，可能无需大幅提升RCU就能将作业时间压缩到可接受范围。

额外注意事项 #

• 所有自动化操作都要添加日志记录，比如用CloudWatch Logs记录RCU调整的时间、原始值、目标值，方便后续排查问题；
• 考虑成本：临时提升RCU会增加DynamoDB费用，务必确保作业完成后及时恢复，避免不必要的开销；
• 先在测试环境验证：生产部署前，先用测试表模拟整个流程，确保RCU调整和恢复逻辑正常，不会影响业务。

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