如何将Google Firestore数据迁移至AWS DynamoDB

直接对应你的几个疑问：不需要从零开发独立API做迁移，有成熟的现成工具可用，也支持备份导出后导入的路径，以下是按落地成本从低到高整理的可选项，你可以根据自己的数据量、迁移时是否需要调整数据结构选择：

方案1：原生导出导入（零业务代码，适合GB级以上大数据量） #

• 第一步先在Firebase控制台触发Firestore全量导出，导出文件会存到Google Cloud Storage存储桶，你可以把导出的文件下载到本地，或者直接转到AWS S3存储桶备用
• 导出的Firestore原生备份文件不能直接导入DynamoDB，需要做一次格式转换：可以用AWS Glue托管ETL作业写几十行PySpark逻辑，读取备份文件，把Firestore的特殊数据类型（时间戳、地理点、文档引用、嵌套对象）转换成DynamoDB支持的格式，同时按你设计的DynamoDB表结构处理字段映射，比如把Firestore默认的文档ID设为DynamoDB的分区键
• 格式转换完成后，直接用DynamoDB自带的S3批量导入功能，指向存好转换后文件的S3路径，就能自动完成全量写入，这个功能自带流量控制，不会打满表配额，导入稳定性比自己写脚本高很多

注意：导出前建议给Firestore开1-2小时的只读维护窗口，避免导出过程中有新写入导致数据不一致，全量数据导完后再补一次增量同步就可以切流量。

方案2：托管/开源迁移工具（极少量配置，适合中小数据量） #

• 不用自己写读写逻辑，直接用现成工具即可：
  • 优先选AWS Database Migration Service（DMS），目前已经原生支持Firestore作为源端、DynamoDB作为目标端，你只要配置好两边的访问权限（给DMS授予Firebase服务账号读权限、DynamoDB写权限），设置好集合到表的映射规则、字段类型转换规则，就能一键启动迁移，支持全量迁移+后续增量实时同步，不用自己写变更监听逻辑
  • 如果不想开通云服务，也可以用轻量开源迁移CLI工具，本地安装后填好两边的配置参数，就能跑并行批量迁移，自带限流、失败重试、断点续传能力，适合几十GB以内的数据量
• 踩坑提醒：别用不带类型适配的工具直接导，Firestore的时间戳、数组、嵌套文档如果直接按普通字符串写入DynamoDB，后续业务适配要花大量时间改数据类型。

方案3：自定义脚本迁移（灵活度最高，适合需要重构数据结构的场景） #

• 如果你迁移过程中需要做数据清洗、字段拆分、多表映射（比如原来Firestore的一个集合要拆成DynamoDB里多张不同键设计的表），再考虑自己写迁移逻辑，完全不需要搭独立API：
  • 全量迁移逻辑很简单：用Firebase Admin SDK分页拉取集合数据，单批次拉取量控制在500条以内，完成你需要的字段转换、数据清洗后，用DynamoDB的batchWriteItem接口批量写入，单批次写入不超过25条，加上指数退避重试逻辑处理限流即可
  • 增量同步可以直接监听Firestore的文档变更流，把新增、修改、删除事件实时同步到DynamoDB，等两边数据追平、校验一致后，把业务流量切到AWS侧，再停掉同步任务就行

迁移脚本不用部署成长期运行的服务，本地或者临时开个AWS Lambda跑就行，跑完直接删除资源，额外成本几乎为零。

容易被忽略的简便路径 #

• 如果你用的是Firebase Blaze付费计划，可以直接开启Firestore到BigQuery的原生同步，等全量数据同步到BigQuery后，直接用SQL完成字段清洗、格式转换，再把结果导出到S3走DynamoDB批量导入，连ETL脚本都不用写
• 全量导入阶段记得把DynamoDB切成按需容量模式，不用提前计算读写CU，能省很多容量规划的功夫，导完稳定运行后再切回预置容量模式降本；导入完成后一定要做抽样校验，抽10%左右的文档对比两边核心字段、更新时间，避免漏写、错写。

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