GCP跨账号用DataFlow迁移BigTable后新表大小异常问题咨询

核心原因 #

• 未触发全量合并（Major Compaction）：原表经过长期运行，后台已经自动完成过多次全量合并，重复的版本、删除标记、冗余数据都被清理，SSTable文件处于最优压缩状态。新导入的表数据全部写入L0层SSTable，还没有经过合并操作，冗余的版本信息、未清理的元数据都会占用额外空间，这是大小差异最常见的原因。
• 存储统计口径差异：BigTable控制台显示的存储容量包含预写日志（WAL）、临时合并文件的占用，新表刚完成写入时WAL还未被归档，临时文件也没有被后台清理，统计值会高于实际数据存储量。
• 配置规则差异：如果新表的压缩算法、版本保留数量、列族配置和原表不一致，也会产生空间占用差异。比如原表用高压缩比的Gzip压缩，新表默认用Snappy压缩，就会出现新表占用更大的情况。
• 导入过程冗余写入：如果导出Sequence File时包含了原表已经合并清理的删除标记、过期数据，导入时这些内容被写入新表，也会增加额外存储占用。

解决方法 #

• 手动触发全量合并：执行以下gcloud命令对新表触发全量合并，合并完成后再查看表大小，大部分情况下会恢复到和原表接近的水平：
  gcloud bigtable tables compact --instance=<目标实例ID> --table=<目标表名>
• 核对表配置一致性：对比原表和新表的列族配置、压缩算法、版本保留规则、TTL配置，确保两边完全一致，如有差异调整后重新执行迁移即可。
• 数据一致性校验：可以分别统计原表和新表的有效行数、抽样校验核心行的内容，排除迁移过程中重复写入、数据丢失的问题。
• 等待后台自动处理：如果不需要立刻对齐大小，可以等待24~72小时，BigTable后台会自动完成合并、WAL清理等操作，存储占用会逐步回落至正常水平。

内容的提问来源于stack exchange，提问作者Ritesh Kumar Singh