优势
相比较于面向行存储的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来划分分区，大小不一定一样