我来逐个拆解你的问题，结合我在DynamoDB和Data Pipeline导出方面的实战经验来解答：

核心是基于有效读取吞吐量和总数据量做理论估算，但实际耗时会受多种瓶颈影响，先看理论公式：

• 首先算出导出作业能用到的最大RCU：你的表配置了10k RCUs，Read Throughput Ratio设为0.9，所以有效RCU = 10000 * 0.9 = 9000 RCU
• 每个RCU的读取能力：DynamoDB中，1个RCU支持每秒最终一致读4KB（Data Pipeline导出默认用这种模式，比强一致读效率高1倍），所以每秒可读取的数据量 = 9000 * 4KB = 36,000 KB/s ≈ 35 MB/s
• 总数据量30GB换算成KB是 30 * 1024 * 1024 = 31,457,280 KB

理论导出时长 = 总数据量 / 每秒读取量 ≈ 31,457,280 / 36,000 ≈ 874秒 ≈ 14.5分钟

但你实际用了超过4小时，说明存在明显瓶颈，常见原因包括：

• 分区热点：单个分区的RCU上限（默认3000 RCU）限制了整体读取速度，哪怕总RCU够，热点分区会拖慢全局
• 线上业务抢占：期间有大量业务请求占用了部分RCU，导致导出实际可用的RCU远低于90%
• Data Pipeline资源不足：默认的EC2实例性能差，无法及时处理读取到的数据，形成处理瓶颈
• 数据碎片化：表中存在大量已删除的 tombstone 条目，增加了读取的额外开销

按优先级从高到低推荐：

• 改用DynamoDB原生导出到S3：这是当前最省心高效的方案，它基于表的快照导出，完全不占用表的RCU，速度是Data Pipeline的数倍，控制台点几下就能配置，不用维护复杂的Pipeline流程，适合1亿条这种大数据量。
• 临时扩容RCU：如果必须用Data Pipeline，可以临时把表的RCU调高（比如加到20k甚至更高），导出完成后再降回10k。DynamoDB按需扩容即时生效，成本会临时增加，但能直接提升读取速率。
• 调整Read Throughput Ratio：如果线上业务平时RCU使用率很低（比如低于50%），可以把比例调到0.95甚至1.0，让导出尽可能利用闲置的RCU。但要实时监控线上业务的延迟，避免导出导致业务请求被限流。
• 升级Data Pipeline的EC2实例：默认的小实例可能成为数据处理的瓶颈，换成m5.xlarge或更大的实例，提升数据解析和写入S3的速度，同时调整并发配置，让实例能充分利用读取到的数据。
• 解决分区热点问题：如果表存在热点分区，可以临时申请提高单个分区的RCU上限（通过AWS控制台提交申请，一般几小时内批准）；或者按主键范围拆分导出任务，并行读取不同分区，避免单点瓶颈。
• 分批并行导出：把数据按Hash键前缀、Range键时间范围拆分成多个小任务，用多个Data Pipeline作业同时导出，充分利用多分区的RCU资源。

这个参数是Data Pipeline专门用来平衡导出速度和线上业务可用性的控制开关，核心逻辑：

• 取值范围0到1.0，代表导出作业最多能使用表配置RCU的百分比（不是实际使用的RCU）。比如你设0.9，就是导出每秒最多用9000 RCU，剩下1000 RCU留作业务请求用。
• Data Pipeline会实时拉取DynamoDB的RCU监控数据，动态调整导出的读取速率，确保不超过设定的比例阈值。如果线上业务突然占用大量RCU，Pipeline会自动降速，避免触发DynamoDB的限流报错。
• 比例设置过低会刻意限制导出速度，导致耗时变长；设置过高则可能抢占业务RCU，引发线上延迟或请求失败。所以要根据业务平时的RCU使用率来调，比如业务只用30%的话，设0.7-0.8是安全又高效的选择。

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