向DynamoDB导入1亿条CSV数据遇性能瓶颈，求优化方案

从你的描述来看，当前的导入效率和表配置的10000 WCU差距明显，下面结合DynamoDB的特性和批量导入的最佳实践，给你几个针对性的优化方向：

一、优先尝试DynamoDB原生导入服务（最省心高效） #

AWS提供的DynamoDB Import from S3是专门为海量数据批量导入设计的托管服务，完全不需要自己维护脚本或EMR集群，能最大化利用表的写入吞吐量：

• 操作流程简单：把CSV文件上传到同区域的S3桶，然后在DynamoDB控制台/CLI启动导入任务，服务会自动处理数据解析、并行写入、节流重试等所有逻辑。
• 关键配置要点：确保CSV格式和表字段严格匹配（比如BIGINT字段是纯数字，无格式错误）；如果10000 WCU不够支撑需求，可以临时申请表的WCU提额（导入完成后再调回原配置），能大幅缩短导入时间。
• 核心优势：原生服务会自动规避热点、优化写入分布，效率比自定义脚本/EMR高几个量级，而且几乎不需要开发成本。

二、优化boto3 batch_write脚本 #

如果坚持用自定义脚本，当前2分钟导入1万条的效率远未发挥出batch_write的潜力，可从以下几点调整：

• 替换为boto3内置的table.batch_writer()：这个类会自动打包最大25条/批次的请求，并且处理UnprocessedItems的指数退避重试——很多手动实现的脚本会漏掉重试逻辑，导致大量请求被节流后丢弃，直接拉低效率。
• 合理设置并行度：根据表的WCU计算最优并发数。假设每条记录约300字节（3个string+1个BIGINT），加上2个LSI的写入消耗，每条写入约占0.7 WCU，那么10000 WCU支持的并发批次约为10000/(0.7*25)≈571个。可以用线程池/进程池设置这个量级的并发，同时注意不要超过账户级的并发请求限制。
• 避免批次资源浪费：确保每个批次都填满25条记录（不要零散的小批次），并且只包含PutRequest（不要混写DeleteRequest），减少无效的请求开销。

三、优化EMR+Hive导入方案 #

如果继续使用EMR，当前3小时20分钟导入2600万条的效率还有很大提升空间：

• 调整Hive-DynamoDB连接器参数：
  • 设置dynamodb.write.capacity.unit=10000，让连接器充分利用表的WCU配额；
  • 把dynamodb.batch.write.size设为25（最大批次大小）；
  • 提高重试参数：dynamodb.max.retries=10，dynamodb.retry.delay=100（启用指数退避），避免节流导致的任务失败。
• 优化EMR集群配置：15个并行进程太少，建议选用高CPU实例（比如c5.4xlarge），每个节点根据核心数开启多个进程，同时调整YARN资源分配规则，确保进程能充分利用节点硬件资源。
• 预处理CSV文件：将大CSV拆分为多个1GB左右的小文件，Hive会自动并行处理这些文件，避免单个进程处理超大文件导致的瓶颈；也可以先把CSV转成Parquet格式（列式存储），再导入DynamoDB，减少IO和序列化开销。

四、表结构与索引的优化 #

你的表配置了2个LSI，这会增加写入的WCU消耗（每个主表写入会触发2个LSI的写入），同时需要注意：

• 检查分区键的分布：如果分区键的基数低（比如只有几百个不同值），会导致单个分区的吞吐量被限制（每个分区最多1000 WCU），即使表总WCU设为10000，实际也无法达到预期吞吐量。务必确保分区键的取值足够分散，避免写入热点。
• 由于LSI只能在表创建时添加，无法事后删除，若导入期间不需要查询LSI，可以考虑先导入到无LSI的临时表，再通过DynamoDB Streams或AWS Data Pipeline将数据同步到带LSI的目标表，这样导入阶段可以节省LSI的WCU消耗。

五、监控与调优辅助 #

• 用CloudWatch监控表的WriteCapacityUtilization和ThrottledRequests指标：如果ThrottledRequests持续很高，说明要么WCU配额不足（临时提额），要么导入工具的重试策略不合理（调整指数退避参数）；如果WriteCapacityUtilization很低，说明导入工具的并行度不够，没有充分利用表的吞吐量。
• 临时关闭表的自动缩放：自动缩放可能在导入时响应不及时，手动设置固定的高WCU能更稳定地支撑导入需求。

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