AWS环境下DynamoDB备份至S3的低成本无代码落地方案咨询

核心落地方案（兼顾成本、效率，无代码优先） #

你调研的两个方向就是当前最高性价比的选择，全程无代码、几小时就能完成部署上线：

• 全量导出：直接用DynamoDB原生PITR导出功能
  这是3TB规模表的最优选择，无需消耗表的读容量单元（RCU），完全不影响线上业务性能，3TB数据通常30-90分钟就能完成导出。仅需提前开启表的PITR功能，待备份可用后在控制台直接选择导出到目标S3桶即可，支持导出为JSON、Parquet、ION格式，优先选Parquet格式，后续多团队查询的存储、计算成本都会低很多。
• 增量同步：DynamoDB Streams + Kinesis Firehose 无代码方案
  全程不需要写任何业务代码：先开启DynamoDB Streams，选择保留新旧数据镜像（覆盖新增、修改、删除场景）；再创建Kinesis Firehose传输流，源端直接选择DynamoDB Streams，目标端选择你的S3桶，按需配置批处理间隔（1-15分钟）、目标存储格式、分区规则即可。成本仅按实际处理的数据量收费，没有服务器运维开销。
• 全量增量衔接方案：先开启DynamoDB Streams，再启动全量PITR导出，全量导出完成后再启动Firehose消费流即可，只要保证全量导出的总时长不超过Streams的保留时长，就不会出现数据缺口或重复。

EMR/Glue适用性说明 #

• Glue：仅适用有额外数据处理需求的场景，比如同步过程中需要做字段清洗、多表关联、自定义格式转换才需要用到Glue ETL或Glue流式处理。如果只是纯同步需求，用Glue会比原生导出+Firehose的方案成本高30%以上，配置流程也更复杂，没必要使用。
• EMR：完全不推荐3TB规模的纯同步场景使用，属于典型的资源浪费，不仅要自行维护集群、配置作业，成本是原生方案的数倍，落地效率也低很多，只有当你有几十TB以上的超大规模数据、同时配套复杂的批量预处理需求时才需要考虑。

关键注意事项 #

• DynamoDB Streams默认保留时长是24小时，如果你的全量导出预估时长超过24小时，可以手动把Streams保留时长调整到最长7天，额外成本极低，能有效避免增量数据丢失。
• 配置Streams镜像的时候记得勾选包含删除事件，Firehose会自动把删除标记同步到S3，下游团队查询时自行过滤已删除数据即可满足需求。
• 推荐开启Firehose的动态分区功能，按日期/小时分区存储数据，后续多团队用Athena等工具查询时能降低70%以上的查询成本。
• 存储层优先开启S3智能分层，同步超过30天的冷数据会自动降级存储，进一步降低长期存储成本。

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