500TB本地HBase表迁移至Google Bigtable方案咨询

首先做前置可行性评估：10Gbps公网带宽实际有效传输速率约为8Gbps（扣除TCP协议、网络波动损耗），满速跑满带宽的情况下，500TB数据纯传输耗时约6天，加上导出、导入耗时，总迁移窗口预留7~10天是合理区间，可根据业务能接受的停机/增量同步窗口选择对应方案。

方案1：在线全量+增量同步迁移（适合可接受短时间业务切流的场景） #

• 第一步：本地全量快照导出
  先给待迁移表打离线快照，用hbase snapshot命令直接导出为原生HFile格式，避免扫描在线表影响业务读写性能，导出的快照临时存储在本地HDFS即可。迁移前建议先执行一次major_compact，清理过期版本、墓碑标记等无效数据，通常可以减少20%~30%的待迁移数据量。
• 第二步：全量数据上云
  用支持多线程、断点续传的传输工具，开启snappy压缩后将HFile文件传到谷歌云存储（GCS），压缩后实际传输量仅为原始容量的30%~50%，能大幅缩短传输耗时。传输过程中可以动态限速，避免占满带宽影响其他业务运行。
• 第三步：全量数据导入Bigtable
  用cbt import命令直接从GCS导入HFile到Bigtable，导入速度和Bigtable节点数正相关，500TB数据建议临时扩容到100个以上节点做导入，导入完成后再缩容到业务需要的规格，不会产生额外的计算成本。导入阶段可以临时关闭Bigtable的自动备份、多区域同步等附加功能，能提升导入速度30%以上。
• 第四步：增量同步追平数据
  全量导入完成后，开启HBase的Replication功能，将快照生成之后的增量WAL日志实时同步到Bigtable，定期跑一致性校验脚本对比两边同rowkey范围的数据哈希值，确认数据一致后选低峰期把业务流量切到Bigtable，停掉旧集群写入即可。

注意：如果业务允许停机迁移，可以跳过增量同步步骤，打快照后直接停写，后续走全量导出、传输、导入流程即可，总耗时更短。

方案2：离线物理介质迁移（适合带宽资源紧张、停机窗口极短的场景） #

如果公网带宽有其他优先级更高的业务占用，无法拿出7天以上的带宽配额做迁移，可以直接走物理介质迁移：

• 把本地HBase快照导出到高密度移动存储设备，500TB容量用8TB硬盘的话大概需要65块左右，打包后寄到谷歌云物理迁移服务节点，谷歌云会负责把硬盘数据直接导入到GCS，后续导入Bigtable的流程和方案1一致。
• 该方案总耗时主要为快递运输时间，完全不占用公网带宽，适合带宽资源紧张的场景。

通用优化建议 #

• 正式迁移前先拿1TB左右的测试表跑一次完整流程，统计实际导出、传输、导入耗时，再确定最终的迁移窗口，避免上线出问题。
• 传输、导入阶段开启数据校验，避免出现静默数据错误。

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