如何计算Google Cloud Bigtable中匹配行键正则的行的压缩存储大小？

针对你50+TB规模的Bigtable表，要统计匹配行键正则的子集压缩后实际存储量，以下是几个可行方案：

1. 利用Cloud Monitoring指标（适合行键可拆分为前缀的场景） #

如果你的行键正则可以转化为若干固定前缀（比如正则是^user_[0-9]{3}，可拆分为user_000到user_999的前缀），可以借助Bigtable的监控指标直接获取压缩后存储：

• 打开Cloud Monitoring，定位到目标Bigtable实例的server/storage_used指标，这个指标统计的就是服务器端压缩后的实际存储量。
• 通过添加row_key_prefix标签过滤器，分别统计每个前缀对应的存储量，最后求和得到总大小。
• 优点：无需写代码，直接用监控控制台就能完成；缺点：仅适用于正则可转化为明确前缀的场景，复杂正则无法覆盖。

2. 用Dataflow批量处理（通用方案） #

对于复杂行键正则，推荐用Dataflow编写批量任务来统计：

• 基于Bigtable的Dataflow连接器，编写代码过滤匹配正则的行，同时通过Bigtable客户端提供的Row.getApproximateSize()方法获取每行的近似压缩后存储大小（这个值是服务器端计算的近似值，足够满足存储规划需求）。
• 累加所有匹配行的近似大小，最终得到总存储量。
• 优点：支持任意复杂行键正则，处理大表效率远高于cbt（分布式处理）；缺点：需要编写少量代码（Java/Python都支持）。

3. 临时表备份统计（无代码方案） #

如果不想写代码，可以通过临时表+备份的方式获取准确的压缩后大小：

• 用Dataflow或Bigtable导出工具，将匹配正则的行导出到一个新的临时Bigtable表。
• 对这个临时表创建备份，Bigtable的备份本身是压缩存储的，备份的大小就是对应数据的实际压缩后存储量。
• 执行gcloud bigtable backups describe BACKUP_NAME --instance=INSTANCE_NAME --cluster=CLUSTER_NAME，查看输出中的size_bytes字段，就是你要的数值。
• 完成统计后删除临时表和备份即可。
• 优点：无需写代码，结果准确；缺点：需要额外的临时存储资源，耗时取决于数据量大小。

为什么cbt不适用？ #

cbt是单线程工具，遍历大表时性能极差，而且它返回的是未压缩的原始数据大小，和服务器端实际存储的压缩后数值差异很大，完全无法满足你的存储规划需求。

内容的提问来源于stack exchange，提问作者Daniel Hernández