HBase row key hotspotting

在HBase中，RegionServer hotspotting现象是很常见的。hotspotting问题的描述是这样的：当使用一个连续的row keys（sequential row keys），以便于使用start key和stop key高效地读取数据时，此时将在写数据时，造成RegionServer hotspotting。下面将会介绍怎么避免这个问题。

Problem Description

HBase中的记录被row key是按照字典顺序排序的。这样可以通过row key快速地访问一条记录，或者通过start key和stop key快速的获取一个范围内的数据。一个典型的场景：你可能为了以后方便查询或者读取数据，而使用一个自然的顺序作为row key。但是，在写数据时，由于HBase向Region中写数据的机制，导致会产生hotspotting。

当一个拥有连续的row key的记录向HBase中写时，可能都写入到了一个Region。然后，如果一个Region服务于多个RegionServer，这将不会成为问题，但是，如果一个Region在一个RegionServer上时，这就会成为hotspotting。每一个Region有一个预定义的最大size，所以如果之后Region达到这个size，就将分成两个更小的Region。随后，新的Region之一将会获取所有新进来的记录，同时该Region和该RegionServer将会成为新的hotspotting的焦点。这种不均匀的分布式写，将会限制单个RegionServer的写数据能力，并且没有充分利用多个或者全部的节点。这种不均匀写的情况可能如下图：

我们不能发现，当一个Region很繁忙地写数据时，其他的Region却处于空闲状态。

Solution Approach

Pre-split Region（预设计Region）

随着HBase Table的size增长，可以预定义Region来避免Region hotspotting。如果某个Region有大量的读/写操作，那么HBase可能因为ZooKeeper连接超时或者“YouAreDeadException”被触发，而踢掉这个RegionServer 。因此，更好的方法是创建固定数量的Region，同时通过评估Table的大小和RegionServer的数量，在所有的RegionServer均匀地分布这些Region。当然，你必须确定你的row keys可能很好的分布在所有的Region上。

例如，你有16个RegionServer和一个1TB的Table。你可以设置每个Region的最大文件size是4GB（hbase.hregion.max.filesize = 4294967296），这意味着16个RegionServer中的每一个都有256个Region。

对于时序的数据，你还应该考虑使用自动地或者定时计划创建Tables。同时，如果需要，你将可能需要向Cluster添加更多的Server。

有一个事必须切记，如果你有大量的数据需要写入HBase，你可能想要增加hbase.regionserver.maxlogs的数量。这样做的缺陷是，如果Cluster宕了或者其他原因重启，将会需要更长的时间恢复。所以调整hbase.regionserver.global.memstore.upperLimit, hregion.max.filesize, hbase.hregion.memstore.flush.size是有有用的。

Row Key Design

最好的方式还是通过hash row key的方式，使之均匀的分布在Regions。本文讨论的场景是假设你不是一次性把所有数据灌入HBase，而是连续的到来的数据。Bulkload向HBase导入数据的方式是最好的解决方案，同时可以避免hotspotting。

最简单地避免hotspotting的方案是使用随机row keys（Random Row Key），但这是一个中折中的方案，它限制了使用start row key和stop row key快速范围扫描的能力。但是，如果你想要使用row key或者scan，你可以考虑hash row key的一部分作为prefix，或者垫一个随机的string。这样row keys就可以均匀的分布在Regions上了。

在你拥有row key prefix，你就需要追加一些你需要使用的suffix，以便scan。对于时序的数据，如果你想要做时间范围的查询，使用timestamp作为suffix是一个不错的选择。