14.大数据学习之旅——HBASE表设计&HBase优化

HBASE表设计

---

Rowkey设计

Rowkey是不可分割的字节数，按字典排序由低到高存储在表中。
在设计HBase表时，Rowkey设计是最重要的事情，应该基于预期的访问模式来为Rowkey建
模。Rowkey决定了访问HBase表时可以得到的性能，原因有两个：
1）Region基于Rowkey为一个区间的行提供服务，并且负责区间的每一行；
2）HFile在硬盘上存储有序的行。
这两个因素是相互关联的。当Region将内存中数据刷写为HFile时，这些行已经排过序，也会
有序地写到硬盘上。Rowkey的有序特性和底层存储格式可以保证HBase表在设计Rowkey之后
的良好性能。
关系型数据库可以在多列上建立索引，但是HBase只能在Rowkey上建立索引。（可以通过ES
为Hbase的列建立索引） 而设计Rowkey有各种技巧，而且可以针对不同访问模式进行优化，
我们接下来就研究一下。

1. 将Rowkey以字典顺序从大到小排序
原生HBase只支持从小到大的排序，但是现在有个需求想展现影片热度排行榜，这就要求实现
从大到小排列，针对这种情况可以采用Rowkey=Integer.MAX_VALUE-Rowkey的方式将
Rowkey进行转换，最大的变最小，最小的变最大，在应用层再转回来即可完成排序需求。

2.RowKey尽量散列设计
最重要的是要保证散列，这样就会保证所有的数据都不是在一个Region上，从而避免读写的时
候负载会集中在个别Region上。比如ROWKEY_Random

3.RowKey的长度尽量短

如果Rowkey太长，第一存储开销会增加，影响存储效率；第二内存中Rowkey字段过长，会导
致内存的利用率降低，进而降低索引命中率。
Rowkey是一个二进制码流，Rowkey的长度被很多开发者建议说设计在10~100个字节，不过
建议是越短越好，不要超过16个字节。

原因如下：
1）数据的持久化文件HFile中是按照KeyValue存储的，如果Rowkey过长比如100个字
节，1000万列数据光Rowkey就要占用100*1000万=10亿个字节，将近1G数据，这会极大影
响HFile的存储效率；
2）MemStore将缓存部分数据到内存，如果Rowkey字段过长内存的有效利用率会降低，系统
将无法缓存更多的数据，这会降低检索效率。因此Rowkey的字节长度越短越好。

4.RowKey唯一
5.RowKey建议用String类型
虽然行键在HBase中是以byte[]字节数组的形式存储的，但是建议在系统开发过程中将其数据类
型设置为String类型，保证通用性。
常用的行键字符串有以下几种：
1）纯数字字符串，譬如9559820140512；
2）数字+特殊分隔符，譬如95598-20140512;
3）数字+英文字母，譬如city20140512；
4）数字+英文字母+特殊分隔符，譬如city_20140512

6.RowKey设计得最好有意义
RowKey的主要作用是为了进行数据记录的唯一性标示，但是唯一性并不是其全部，具有明确
意义的行键对于应用开发、数据检索等都具有特殊意义。
譬如数字字符串：9559820140512，其实际意义是这样：95598（电网客服电话）+
20140512（日期）。
行键往往由多个值组合而成，而各个值的位置顺序将影响到数据存储和检索效率，所以在设计
行键时，需要对日后的业务应用开发有比较深入的了解和