如何重新创建现有HBase表以添加加盐行键？低停机时间下为存在热点问题的HBase/Phoenix表添加加盐行键的方案

我来帮你梳理下解决HBase热点问题的加盐表重建和高效迁移方案——毕竟几十万行数据的迁移效率确实是个核心痛点，Phoenix那种单条UPSERT的方式肯定扛不住。

一、怎么创建带加盐行键的HBase表 #

加盐的核心逻辑很简单：给原行键加一个固定长度的盐前缀（比如0-9的数字或a-f的十六进制字符），让原本扎堆的行键分散到不同Region，从根源上避免热点。具体步骤如下：

1. 确定盐前缀范围：根据你想要分散的Region数量来定，比如要分到10个Region就用0-9，16个的话用0-f。前缀推荐1位就行，太长会浪费行键存储空间。
2. 预分区建表（关键！）：一定要在创建表时指定预分区，不然加盐后数据可能先集中到一个Region再自动分裂，还是会有短暂热点。比如用HBase Shell建表：

   create 'TABLE_SALTED', 
   {NAME => 'cf1', VERSIONS => 1}, 
   {SPLITS => ['0', '1', '2', '3', '4', '5', '6', '7', '8', '9']}
   

   这里的SPLITS参数就是按盐前缀拆分Region，每个前缀对应一个独立的Region，数据写入时会直接路由到对应Region，完美分散负载。

二、高效迁移数据：换掉Phoenix UPSERT的方案 #

Phoenix的UPSERT INTO效率低是因为它是单条SQL执行，完全没用到批量处理的优势。推荐用MapReduce或Spark批量作业来实现行键加盐并迁移，这是处理大数据量最靠谱的方式：

方案1：自定义MapReduce作业 #

你可以基于HBase的MapReduce API写个简单作业，核心逻辑就是读取原表数据、给行键加盐、写入新表：

• Mapper阶段：读取原表每一行，拿到原行键，用哈希取模的方式生成盐前缀（比如Math.abs(原行键.hashCode()) % 10得到0-9的前缀），拼接成新行键。
• Reducer阶段：把处理后的数据批量写入新表。
  给你个Java核心代码片段参考：

@Override
protected void map(ImmutableBytesWritable key, Result value, Context context) throws IOException, InterruptedException {
    String originalRowKey = Bytes.toString(key.get());
    // 生成盐前缀：原行键哈希取模10，得到0-9的数字
    int salt = Math.abs(originalRowKey.hashCode()) % 10;
    String newRowKey = salt + "_" + originalRowKey; // 前缀+分隔符+原行键，分隔符可选，方便后续识别
    context.write(new ImmutableBytesWritable(Bytes.toBytes(newRowKey)), value);
}

写完后用hbase jar命令提交作业，速度比Phoenix快N倍。

方案2：Spark批量迁移（更简洁） #

如果你的集群有Spark环境，用Spark处理会更省心，代码量少很多：

import org.apache.hadoop.hbase.{HBaseConfiguration, TableName}
import org.apache.hadoop.hbase.client.{ConnectionFactory, Put}
import org.apache.hadoop.hbase.io.ImmutableBytesWritable
import org.apache.hadoop.hbase.mapreduce.TableInputFormat
import org.apache.hadoop.hbase.util.Bytes
import org.apache.spark.SparkContext

val conf = HBaseConfiguration.create()
conf.set(TableInputFormat.INPUT_TABLE, "TABLE")
val sc = new SparkContext(conf)

// 读取原表全量数据
val hbaseRDD = sc.newAPIHadoopRDD(conf, classOf[TableInputFormat], classOf[ImmutableBytesWritable], classOf[Result])

// 处理行键并批量写入新表
hbaseRDD.foreachPartition { iter =>
    val conn = ConnectionFactory.createConnection(conf)
    val table = conn.getTable(TableName.valueOf("TABLE_SALTED"))
    iter.foreach { case (key, result) =>
        val originalRowKey = Bytes.toString(key.get())
        val salt = Math.abs(originalRowKey.hashCode()) % 10
        val newRowKey = Bytes.toBytes(s"$salt-$originalRowKey")
        val put = new Put(newRowKey)
        // 复制原行的所有列族和列数据
        result.listCells().forEach(cell => {
            put.addColumn(cell.getFamilyArray, cell.getQualifierArray, cell.getTimestamp, cell.getValueArray)
        })
        table.put(put)
    }
    table.close()
    conn.close()
}

Spark的分布式处理能力能快速搞定几十万行数据的迁移，跑起来比MapReduce还省心。

三、最短停机时间的迁移方案（在线迁移） #

如果你的业务不能长时间停机，那就得用全量迁移+增量同步+平滑切换的流程，把停机时间压缩到几分钟：

1. 提前准备：先建好加盐的新表（记得预分区），写好全量迁移的作业。
2. 全量迁移历史数据：选业务低峰期启动全量迁移，这时候原表正常对外提供读写服务，不影响业务。
3. 增量数据同步：
   • 方式一：自定义HBase Replication Endpoint。HBase默认的Replication会直接复制行键，你需要自定义一个Endpoint，在复制时给行键加上盐前缀，这样原表的新增/修改数据会自动同步到新表。
   • 方式二：用CDC工具（比如Debezium）捕获HBase的变更日志，转换行键后写入新表，适合复杂的场景。
4. 数据一致性校验：全量迁移完成后，对比原表和新表的行数，再随机抽一些数据验证，确保增量同步已经追上原表的最新数据。
5. 业务切换：
   • 短暂停机（几分钟）：先暂停业务写入，等最后一批增量数据同步完成。
   • 修改应用配置，把读写都切换到新的加盐表。
   • 恢复业务写入，验证新表的读写正常。
6. 收尾：观察新表运行几天，确认没有热点问题后，再删除原表。

关键注意事项 #

• 加盐规则必须统一：不管是迁移时还是后续应用写入，都要用相同的加盐逻辑（比如哈希取模），不然会导致数据找不到。
• 预分区要和盐前缀匹配：比如用0-9的前缀，就要对应10个预分区，这样每个前缀的数据会精准落到对应的Region，不会出现跨Region的热点。
• 增量同步要监控延迟：确保全量迁移完成后，增量数据能实时同步，避免切换时丢失数据。

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