在 HBase 中，RowKey（行键）的设计直接决定了数据的存储分布和查询性能。因为 HBase 实际上只有一个针对 RowKey 的主键索引，且数据是严格按照 RowKey 的字典序（Lexicographical Order）排序并划分到不同的 Region 中存储的。

设计 HBase RowKey 时，通常需要遵循以下三大核心原则以及一些针对业务的进阶设计技巧：

---

一、 三大核心原则

1. 长度原则 (Length Principle)

RowKey 的长度应该尽可能短，通常建议在 10 ~ 100 字节之间，最好不要超过 16 字节，且最好是 8 的倍数（为了 64 位操作系统的内存对齐）。

• 原因：HBase 的数据是按 Key-Value（Cell）存储的，RowKey 会冗余存储在每一个 Cell 中。如果 RowKey 过长（最大允许 64KB），包含成百上千列的表会产生巨大的空间浪费。这不仅会迅速耗尽 MemStore 的内存导致频繁 Flush，还会大大降低 HFile 缓存（BlockCache）的效率。

2. 唯一性原则 (Uniqueness Principle)

RowKey 必须能够全局唯一地标识一条记录。

• 原因：RowKey 就相当于关系型数据库中的主键。如果插入数据时 RowKey 已经存在，HBase 会认为这是一次更新（Update）操作，从而覆盖原有的数据（或增加一个新的版本）。

3. 散列性原则 (Hashing/Distribution Principle) —— 最重要

RowKey 应当均匀分布，避免将连续递增的数据（如时间戳、自增 ID）直接放在 RowKey 的开头。

• 原因：HBase 是按 RowKey 范围分区的。如果 RowKey 开头是连续递增的，那么所有新写入的数据都会集中落入同一个 Region（即一台 RegionServer 上），导致“热点问题”（Hotspotting）。这台机器的负载会极高，而集群中的其他机器却处于闲置状态，完全丧失了分布式集群的优势。

---

二、 业务设计原则（读写权衡）

除了上述物理层面的原则，RowKey 的设计还必须高度契合业务查询场景。

4. 排序/前缀原则 (Sorting/Prefix Principle)

HBase 的查询只有三种方式：基于 RowKey 的 Get（单行查询）、基于 RowKey Range 的 Scan（范围扫描）、全表 Scan。

• 设计思路：必须将最常作为查询条件的业务字段放在 RowKey 的最前面。由于 HBase 按照字典序排序，具有相同前缀的 RowKey 会在物理上相邻存储。
• 示例：如果经常按用户查询某段时间的流水，RowKey 应设计为 [UserID]_[Timestamp]。这样同一个用户的数据是连续存放的，Scan 时效率极高。

5. 时间倒序原则 (Reverse Timestamp Principle)

在很多日志、监控或消息系统中，业务最常查询的是最新产生的数据。

• 设计思路：利用 Long.MAX_VALUE - timestamp 替换原本的时间戳。
• 效果：原本随着时间递增的数据，相减后变成了递减。这样最新的数据 RowKey 较小，会排在最前面，用户在 Scan 查询时就能瞬间获取最新的记录。

---

三、 解决“热点问题”的常见 RowKey 改造技巧

为了满足“散列性原则”，我们经常需要对原本带有明显规律的业务 Key 进行加工。常用的手段有三种：

1. 反转 (Reversing)

将具有规律的前缀反转，让随机性强的尾部跑到前面。

• 适用场景：手机号、身份证号。例如手机号 138xxxxxx 开头大量重复，但尾号是随机的。反转后变成 xxxxxx831，能很好地打散到不同的 Region。
• 缺点：牺牲了按原前缀进行 Range Scan 的能力。

2. 加盐 (Salting)

在 RowKey 的最前面加上一段随机数或 Hash 值的截取部分（如分配 000~999 的前缀）。

• 公式：NewRowKey = (hash(BusinessKey) % N) + BusinessKey （N 通常为 Region 的数量）
• 优点：写入时能达到极其完美的负载均衡。
• 缺点：读取时变得非常麻烦。如果要读取某个范围的数据，必须构造 N 个 Scan 请求，分别去 N 个带有不同盐值前缀的区间读取，然后在客户端进行结果合并。

3. 哈希 (Hashing)

使用 MD5、SHA-1 或 MurmurHash 对原 RowKey 或部分业务字段进行哈希，将哈希值作为 RowKey 的前缀。

• 适用场景：已知完整的查询条件，主要进行 Get 查询，不进行范围 Scan。哈希不仅能打散数据，还能固定 RowKey 的长度。
• 示例：MD5(UserID).substring(0,8) + _ + UserID + _ + Timestamp。

---

总结：一个优秀 RowKey 的诞生公式

在实际企业开发中，一个兼顾读写性能的典型 RowKey 结构往往是组合而成的：

RowKey = Hash前缀/盐 (防热点) + 核心业务维度 (用于过滤/聚集) + 时间维度(倒排) + 唯一性标识 (防重复)

举个例子：设计一个存储用户浏览记录的表。

• 错误设计：Timestamp + UserID （严重写热点）
• 一般设计：UserID + Timestamp （如果某些大 V 用户数据极多，依然会造成单 Region 读写热点）
• 优秀设计：Reverse(UserID.substring(0,4)) + UserID + (Long.MAX_VALUE - Timestamp) （既打散了数据，又保证了同用户数据连续，且最新数据在前）。