HBase 的“热点问题（Hotspotting）”是如何产生的？

在 HBase 中，“热点问题”（Hotspotting）是指在集群运行过程中，大量的客户端读写请求被集中打到一个或极少数几个 RegionServer 节点上，而集群中的其他节点却处于闲置或负载极低的状态。

这种现象会导致被集中的节点资源（CPU、内存、网络 IO、磁盘 IO）耗尽，出现高延迟、请求超时甚至节点宕机，从而拖垮整个集群的性能。

热点问题产生的根本原因在于 HBase 的数据存储机制：HBase 是按照 RowKey 的字典序（Lexicographical Order）来排序和存储数据的。

具体来说，热点问题通常由以下几种设计不当的场景引起：

如果你在设计 RowKey 时，使用了时间戳（Timestamp）、自增序列号（Auto-increment ID）或者连续的业务 ID 作为 RowKey 的前缀或全部，就会产生极其严重的写热点。

产生过程： 因为 RowKey 是连续递增的，按照字典序排列，所有新写入的数据都会被分配到 HBase 表的最后一个 Region 中。
后果： 整个集群可能只有这一个 Region 所在的 RegionServer 在疯狂处理写请求（被称为“尾部热点”）。当这个 Region 写满触发 Split（分裂）后，新的数据又会全部集中到分裂出来的新 Region 上，热点永远在不断后移，集群的分布式并发写能力完全失效。

即使 RowKey 不是连续递增的，如果 RowKey 的前缀存在严重的数据倾斜，也会产生热点。

产生过程： 假设 RowKey 的设计是 UserID_Timestamp。如果系统中存在几个“超级大V”或者爬虫账号（即某些特定 UserID 产生的数据量是普通用户的成百上千倍），那么带有这些特定 UserID 前缀的数据会按照字典序被集中路由到同一个 Region 中。
后果： 存放这些“大V”数据的 Region 会承受远超其他 Region 的读写压力，形成单点瓶颈。

在 HBase 中新建一张表时，默认情况下只会分配一个 Region。

产生过程： 如果建表时没有进行预分区（Pre-splitting），那么在数据量达到 Region 分裂阈值之前，所有的读写请求都会集中在这唯一的 Region 上，由单一的 RegionServer 处理。
后果： 即使你的 RowKey 散列设计得很好，在初期也会因为只有一个 Region 而产生热点。此外，数据快速写入会导致该 Region 频繁触发 Split，Split 过程中该 Region 会短暂不可用，影响性能。

写热点很常见，但有时也会产生读热点。

产生过程： 比如 RowKey 设计为逆序时间戳（Long.MAX_VALUE - timestamp），使得最新产生的数据排在最前面。如果业务场景是大量用户在同一时间疯狂刷新并读取“最新的 N 条记录”。
后果： 虽然写入可能分散了，但大量的读取请求都会瞬间指向存放最新数据的那个 Region，造成读热点。

为了打破 RowKey 字典序带来的集中效应，通常采用以下几种策略：

加盐（Salting）：
- 在原 RowKey 的最前面加上一个随机数或随机字母（通常是集群 Region 数量的模）。
- 优点： 能够将写请求绝对均匀地打散到所有 Region。
- 缺点： 读数据变得困难。因为同一个实体的数据被打散了，扫描（Scan）时需要并行扫描所有的 Region 然后在客户端进行合并。
哈希（Hashing）：
- 计算原 RowKey（或特定字段如 UserID）的 Hash 值，将 Hash 值的前几位作为 RowKey 的前缀。
- 优点： 相同的 UserID 会生成相同的 Hash 前缀，始终落在同一个 Region，方便单用户的范围扫描（Scan）；不同的 UserID 会被均匀分散到不同 Region，解决热点。
- 适用场景： 读写兼顾，是最推荐的通用做法。
反转（Reversing）：
- 将递增的数据（如时间戳、手机号、连续 ID）进行字符串反转后作为 RowKey。例如，手机号后 4 位通常是随机的，反转后前缀就变随机了。
- 优点： 打散了连续递增的趋势。
- 缺点： 破坏了数据的有序性，无法进行基于原顺序的范围扫描（Scan）。
建表时预分区（Pre-splitting）：
- 结合上述的哈希或加盐策略，在创建表的时候提前划分好 Region（例如提前划分为 16 个或 64 个 Region），让数据从一开始就能并发写入多个节点。

播面