活跃Region数对HBase运行集群的影响

HBase在设计上，遵循了LSM-Tree的原理：写数据阶段，尽最大努力先将每一个Region的数据保留在内存(MemStore)中，等达到一定的阈值（默认为64M）之后，再将这些数据固化（Flush）到文件(HFile)中。在这过程中，为了保证数据的安全性，通过将数据写入到一个日志文件(HLog)中:

图1  HBase的LSM-Tree架构

在当前时间段可能被写入用户数据的Region,称作“活跃Region”。

举例：

如果一个用户表的Region是按天划分的，那么，第一天的用户数据，只会被写入到第一天的Region中，则这些Region就是活跃Region。此时，对于其它天的Region，都处于一种“空闲”的状态。

集群中每一个物理节点的内存资源都是有限的，在前面部分也提到了每一个Region的数据都是暂时先保留在内存中然后再固化到HFile文件中的。因此，我们需要控制每一个时间段的活跃Region数目。如果活跃Region过多的话，会导致内存资源紧张，每一个Region在内存中的数据可能还没有达到预先设置阈值的大小就被提前触发Flush操作，这会导致Flush频率升高，产生大量的小HFile文件（小文件过多会导致读取性能的直线下降，也会加大Compaction的频率和压力）。相反，如果活跃Region过少的话，也会导致并发度提升不上去，读写性能偏低。

如何设置最合理的活跃Region数目？需要根据MemStore Flush的阈值大小，以及RegionServer堆内存的大小、预留BlockCache空间的大小进行合理的计算。如下例子可说明这种计算的方法。

举例：

假设分配给RegionServer堆内存的大小为8G，BlockCache所占空间比例为25%，MemStore Flush的阈值大小为128M，则合理的活跃Region数目约为8*1024*（1-0.25）/128 = 48(个/节点)。

       以用户交易记录表为例。每一条用户交易记录关联一个USER_ID，也关联一个确切的交易时间点。

       如果我们在设计Key值的时候，采用“USER_ID + TIME”的格式，则划分Region的时候，一定是按照USER_ID的范围划分的。对于任意一天的交易记录，可能涉及到各个范围内的USER_ID，即可能涉及到所有的Region，因此所有的Region都可能是活跃的，就会导致前面提到的那种活跃Region过多的问题，而且这种问题会随着时间的持续而不断恶化下去。

    图2  直接将USER_ID放在前面导致所有的Region都成为活跃的Region

       如果RowKey采用格式“DAY + USER_ID + TIME”的话，Region一定是按天划分的。那么，第N天的用户交易记录数据只会涉及到第N天的Region，也只有这一天的Region是活跃的，这样就有力的控制了活跃Region的数目：

   图3  通过设定分区控制活跃Region数目