Hbase记录第二篇

Hbase入门第一篇

优势

相比较于面向行存储的Mysql，hbase面向列存储
Mysql做数据聚合操作时，都是读取一行数据，一行中很多值并不需要，就造成了性能浪费。
而面向列存储，只读取需要的那个列的值，就更适合海量数据的读取统计分析

hbase高可靠，高性能，面向列，可伸缩的分布式存储系统

介绍

按照列簇存储，一个列簇包含很多列。并且稀疏存储，只存需要的列，不是每行所有列的值都必须存值
一个列簇一个store，相当于垂直拆分
Region相当于分区，水平拆分

查询方式 scan/get 写入方式 put
这里rowkey 1001的name，sex两列数据因为都属于1001 rowkey，算同一行数据。所以这里scan只有2行数据。
因为稀疏表，所以可以一行没有name的列值。另外当根据rowkey范围查询如1001-1003时左闭右开，不会显示1003
put时以时间戳版本形式加入数据。表象是相同覆盖，没有新增。但当通过版本号查询时，删除的数据依然可以读取

读取的三种方式

Hbase 协处理功能

类似Spring AOP，Hbase支持自定义的增强操作。
比如postPut可以实现执行完hbase插入操作后，自动另一个新表插入该数据的后置功能

Hbase优化

高可用配置

HA配置backup-masters

预分区

rowkey存储是根据字典顺序排序的，建议不要用数字日期来分区。
例如rowkey 1000，1001，1002。当触发分区时，会按照rowkey字典中间值来划分，1000，1001和1002两个分区
以后1002以后的数据都只会进入1002的分区，容易造成数据倾斜

为了避免频繁的自动分区，可以提前规划好分区，提高性能

Rowkey设计

尽量平均划分数据到分区中，避免数据倾斜

原则
	唯一性原则，类似mysql主键。rowkey根据字典排序，可以根据这个规则让经常查询的数据放一起
	长度原则，不能太长太短 60-80byte，最大值64k
	散列原则，随机均分分配

内存优化

Hbase常见问题

热点/数据倾斜问题

合并问题

小合并合并文件，大合并清除数据，提高读写效率
大合并/小合并具体内容看第一篇文章。大合并会阻塞写操作
合并时机：每次flush判断，也有专门checkFlush线程周期判断

宕机问题

Hbase region划分

rowkey根据字典排序的middleKey来划分分区，大小不一定一样