HBase生产环境已上线业务表修改rowkey设计的最优方案咨询

结合你的业务表体量（仅150万行、预估最大10GB，大概率不足2GB）、集群规模（40个容量节点）的前提，优先推荐行业通用的近零停机双写+快照切换方案，全程风险极低、几乎无业务感知：

• 首先升级所有接入该表的业务侧依赖，新增双写逻辑：新写入数据同时写入原表、和提前创建的同结构新表（新表采用新rowkey格式），该阶段读请求仍全部走原表，可观察1~2天确认双写逻辑无异常
• 运行离线迁移脚本，将原表存量数据按新rowkey规则转换后写入新表，你的数据量极小，全量迁移耗时不会超过30分钟，迁移时可加幂等校验避免双写阶段增量数据冲突
• 做数据一致性校验：全量比对新旧表rowkey数量+抽样校验单元格内容，确认新表数据完全正确后，将业务侧读请求切换到新表，再观察1~2天确认读写全链路稳定
• 选择业务低峰期做表名切换：先将原表重命名为[原表名]_obsolete，再将新表重命名为原表名，操作本身是HBase元数据变更，耗时仅毫秒级；新表的major compaction可提前在业务低峰期完成，你的数据量下compaction耗时最多10分钟，40节点集群完全不会产生明显性能波动
• 业务稳定运行7天以上后，再下线旧表和临时快照即可

如果不想额外开发双写逻辑，三个现有方案按优先级排序如下：

1. 首推方案2：你的数据量极小，compaction影响可以忽略，重命名操作几乎无停机时间，风险远低于另外两个方案
2. 次选方案3：如果能申请到30分钟以内的业务停机窗口，150万行数据的rowkey批量修改+compaction完全可以在窗口内完成，操作逻辑更简单
3. 不推荐方案1：双读逻辑会大幅提升业务代码复杂度，后续旧数据清理、兼容逻辑下线都容易出故障，回滚流程也十分繁琐，完全没必要为了这点数据量做业务层适配

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