文档中心

典型场景说明

通过实例说明，我们可以初步掌握HBase的开发过程，对关键的接口函数和指令有所了解。
假定用户开发一个应用程序，用于网址管理上网用户的用户信息，如下表所
示，业务流程如下：

• 创建用户信息表。

• 在用户信息中新增用户的邮箱、账号、工作等信息。

• 根据用户编号查询用户账号和邮箱。

• 根据用户账号进行查询。

• 查询年龄段在[16–40]之间的用户信息。

• 数据统计，统计用户信息表的人员数、年龄最大值、年龄最小值、平均年龄。

• 用户销户，删除用户信息表中该用户的数据。

• 删除用户信息表。

用户信息
主键 账号 邮箱 年龄 工作
1000101 molika tt@hotmail.cn 29 IT
1000102 kouda kouda@126.com 24 销售
1000103 liusha liusha@173.com 36 经理
1000104 baifei  baifei@189. 16 学生
合理地设计表结构、行键、列名能充分利用HBase的优势。本样例工程以唯一主键作为
RowKey，列都存储在info列族中。
HBase是以RowKey为字典排序的分布式数据库系统，RowKey的设计对性能影响很大，
具体的RowKey设计参考4.7 rowkey设计原则。

序号	步骤	代码实现
1	创建用户信息表	请参考5.3创建表代码示例
2	用户信息中新增用户的邮箱、账号、工作等信息	请参考5.6插入数据代码示例
3	根据用户编号查询用户账号和邮箱	请参考5.8使用Get读取数据代码示例
4	根据用户账号进行查询	请参考4.8使用过滤器Filter代码示例
5	查询年龄段在[16–40]之间的用户信息	请参考4.8二级索引代码示例
6	用户销户，删除用户信息表中该用户的数据	请参考4.8删除数据代码示例
7	删除用户信息表	请参考4.8删除表代码示例

数据压缩与编码

天翼云支持LZO  GZ LZ4 SNAPPY ZSTD NONE，其中NONE就代表不开启压缩。系统默认开启LZ4.
云HBASE支持编码方式有Prefix | Diff | Fast_Diff | Prefix_Tree。DIFF encoding对小kv
场景使用效果较好，可以减少2-5倍的数据量。我们推荐DATA_BLOCK_ENCODING使用diff

读写取优化

BlockSize设置用户平均读取数据的大小。理论上讲，如果用户平均读取数据的大小较小，
建议将块大小设置较小，这样可以使得内存可以缓存更多block，读性能自然会更好。
相反，建议将块大小设置较大。随着BlockSize的增大，系统随机读的吞吐量不断降低，
延迟不断增大。随着BlockSize增大，scan的吞吐量逐渐增大，延迟不断降低。可见，
如果业务请求以Get请求为主，可以考虑将块大小设置较小；如果以Scan请求为主，
可以将块大小调大；默认的64M块大小是在Scan和Get之间取得的一个平衡。

预分区

当hbase的region分区过多，数据分布不均衡，或者有热点。我们就可以对该表进行预分区
来避免以上问题。减少由于region split带来的资源消耗。从而提高HBase的性能。

如何预分区

===方法1===
通过可视化shell来创建。命令样例如下：
create 't1', 'f1', SPLITS => ['10', '20', '30', '40']
create 't1', {NAME =>'f1', TTL => 180}, SPLITS => ['10', '20', '30', '40']
create 't1', {NAME =>'f1', TTL => 180}, {NAME => 'f2', TTL => 240}, SPLITS => ['10', '20', '30', '40']

===方法2===
仍然是通过可视化shell来创建，不过是通过读取文件
1、在任意路径下创建一个保存分区key的文件，我这里如下
路径：/home/hadmin/hbase-2.0.3/txt/splits.txt

2、通过可视化shell创建表
命令样例：
create 't1', 'f1', SPLITS_FILE => '/home/hadmin/hbase-1.3.1/txt/splits.txt'
create 't1', {NAME =>'f1', TTL => 180}, SPLITS_FILE => '/home/hadmin/hbase-2.0.3/txt/splits.txt'
create 't1', {NAME =>'f1', TTL => 180}, {NAME => 'f2', TTL => 240}, SPLITS_FILE => '/home/hadmin/hbase-2.0.3/txt/splits.txt'

columnFamily设计原则

列族column family：它是column的集合，在创建表的时候就指定，不能频繁修改。值得注意的是，列族的数量越少越好，因为过多的列族意味着数据库存放需要更多单独的storefile文件来存放，文件越多，数据库读写的性能就会越差。一般设置一个到两个列族。

rowkey设计原则

HBase的数据是按照RowKey的字典顺序进行全局排序的，所有的查询都只能依赖于这一个排序维度。
RowKey设计的好坏直接决定了数据库读写的性能和数据保存的均衡性。数据库数据不均衡，虽然数据库本身可以开启自动均衡功能，但其均衡过程会间接影响数据库的读写，从而导致了数据库使用的稳定性体验。
Rowkey是一个二进制码流，长度建议按照8字节倍数进行设计，一般控制在16字节。
Rowkey 高位建议进行散列，低位按照rowkey的规律进行处理。假如低位是按照时间规律生成，那么低位可以在regionserver内部达到顺序化的目的。
Rowkey避免热点的常用方式有：
加盐
在rowkey的前面增加一个前缀，一般是随机数，使得它和之前的rowkey的开头不同。分配的前缀种类数量应该和你想使用数据分散到不同的region的数量一致。加盐之后的rowkey就会根据随机生成的前缀分散到各个region上，从而达到Region负载均衡的目标。
例如：有4个Region(注：以 [ ,f1)、[f1,f2)、[f3,f4)、[f4, )为Region起至
加Salt前的Rowkey：a001、a002、a003
f1、f2、f3、f4为前缀，加Salt后Rowkey为：f1-a001、f2-a002、f3-a003 、f4-a004
实验可以看到，加盐后的Rowkey数据会分布在4个region中，理论上处理后的吞吐量应是之前的4倍。由于前缀是随机的，读这些数据时需要耗费更多的时间，所以Salt增加了写操作的吞吐量，不过缺点是同时增加了读操作的开销。

哈希
哈希会使同一行永远用一个前缀加盐。哈希也可以使负载分散到整个集群，但是读却是可以预测的。使用确定的哈希可以让客户端重构完整的rowkey，可以使用get操作准确获取某一个行数据
反转
第三种防止热点的方法时反转固定长度或者数字格式的rowkey。这样可以使得rowkey中经常改变的部分（最没有意义的部分）放在前面。这样可以有效的随机rowkey，但是牺牲了rowkey的有序性。
常用的类似工号，电话号码前段部分比较固定这类容易引起数据热点。