HBase的设计优化

HBase是一个分布式数据库，其性能的好坏主要取决于内部表的设计和资源的分配是否合理。

（1）Rowkey设计。

Rowkey设计决定了数据在HBase的分布和查询的效率。数据的分布式存储，要求数据均匀分布，不存在热点现象，而HBase中region的划分依赖于rowkey的取值范围，所以要求rowkey设计的是均匀分布的。

（2）列簇设计。

HBase的表设计时，根据不同需求有不同选择，需要做在线查询的数据表，尽量不要设计多个列簇，我们知道，不同的列簇在存储上是被分开的，多列簇设计会造成在数据查询的时候读取更多的文件，从而消耗更多的I/O。

（3）TTL设计。(www.xing528.com)

选择合适的数据过期时间也是表设计中需要注意的一点，HBase中允许列簇定义数据过期时间，数据一旦超过过期时间，可以被major compact进行清理。大量无用历史数据的残余，会造成region体积增大，影响查询效率。

（4）Region设计。

一般地，region不宜设计成很大，除非应用对阶段性性能要求很多，但是在将来运行一段时间可以接受停服处理。region过大会导致major compact调用的周期变长，而单次major compact的时间也相应变长。major compact对底层I/O会造成压力，长时间的compact操作可能会影响数据的flush，compact的周期变长会导致许多删除或者过期的数据不能被及时清理，对数据的读取速度等都有影响。

相反，小的region意味着major compact会相对频繁，但是由于region比较小，major compact的相对时间较快，而且相对较多的major compact操作，会加速过期数据的清理。当然，小region的设计意味着更多的region split风险，region容量过小，在数据量达到上限后，region需要进行split来拆分，其实split操作在整个HBase运行过程中，是被不怎么希望出现的，因为一旦发生split，涉及数据的重组，region的再分配等一系列问题。所以我们在设计之初就需要考虑到这些问题，尽量避免region的运行过程中发生split。

HBase可以通过在表创建的时候进行region的预分配来解决运行过程中region的split产生，在表设计的时候，预先分配足够多的region数，在region达到上限前，至少有部分数据会过期，通过major compact进行清理后，region的数据量始终维持在一个平衡状态。region数量的设计还需要考虑内存上的限制，每个region都有memstore，memstore的数量与region数量和region下列簇的数量成正比，一个RS下memstore内存消耗为：Memory=memstore大小∗region数量∗列簇数量。如果不进行前期数据量估算和region的预分配，通过不断的split产生新的region，容易导致因为内存不足而出现OOM现象。