特点
易扩展
hbase的扩展性展现在两个方面，一个是基于运算能力的扩展，通过增加HRegionServer节点的数量，提升hbase上层的处理能力；另一个是基于存储能力的扩展，通过增加DataNode节点数量对存储层的进行扩容，提升数据存储能力
容量大
habse单表可以有十亿行、百万列，数据矩阵横向和纵向两个维度所支持的数据量级都非常具有弹性。hbase的主要作用就是面向PB级别数据的实时入库和快速随机访问。这主要源于上述易扩展的特点，使得hbase通过扩展来存储海量的数据
面向列
habse是根据列族来存储数据的，列族下面可以有非常多的列。列式存储的最大好处就是，其数据在表中是按照某列存储的，这样在查询只需要少数几个字段时，能大大减少读取的数据量，还可以动态增加列，可单独对列进行各方面的操作。
多版本
hbase的每个列的数据存储支持多个version，比如住址列，可能有多个变更。
稀疏性
为空的列并不占用存储空间，表可以设计的非常稀疏。不必像关系型数据库那样需要预先知道所有列名然后再进行null填充
高可靠
WAL日志先行机制，保证数据写入的时候不会因为集群异常而导致写入数据丢失。replication机制，保证了集群再出现严重问题的时候，数据不会发生丢失或者损坏。hbase底层使用hdfs，本身也有备份。
高性能
底层的LSM树数据结构和RowKey有序排列等架构上的独特设计，使得hbase写入性能非常高。HRegion切分、主键索引、缓存机制使得hbase在海量数据下具备一定的随机读取性能，该性能针对RowKey的查询能够到达毫秒级别。LSM树属于树形结构，最末端的子节点是以内存的方式进行存储的，内存中的小树会flush到磁盘中（当子节点达到一定阈值以后，会放到磁盘中，且存入的过程会进行实时Merge成一个主节点，然后磁盘中的树定期会做Merge操作，合并成一棵大树，以优化读性能）
热点问题
原因
hbase中的行默认按行键的字典序进行排序，这种设计优化了扫描，允许将相关的行或彼此靠近的行一起读取。但是，设计不佳的行键时Hot-Spotting的常见来源<br>热点发生在大量client直接访问集群的一个或极少数各节点，大量访问会使热点hregion所在的单个机器超出自身承受能力，性能下降甚至hregion不可用。这也会对同一台区域服务器托管的其它区域产生不利影响，所以行键的设计以使集群得到充分和均匀的利用就变得非常重要
策略
反转策略
反转固定长度或者数字格式的rowkey，这样可以使得rowkey中经常改变的部分放在前面。这样可以有效的随机rowkey，但是牺牲了rowkey的有序性
加盐策略
在rowkey的前面增加随机数，具体就是给rowkey分配一个随机前缀以使得它和之前的rowkey的开头不同。分配的前缀种类数量应该和你想使用数据分散到不同的hregion的数量一直。加盐之后的rowkey就会根据不同的前缀分散到各个hregion上以避免热点
哈希策略
哈希也可以使负载分散到整个集群，但是读取却是可以预测的，使用确定的哈希可以让客户端重构完成的rowkey，并且可以使用get操作准确获取某一个行的数据
rowkey设计原则
唯一原则
必须在设计上保证其唯一性。其次，rowkey是按字典序排序存储的，设计rowkey时，要充分利用这个排序的特点，将经常一起读取的行存放到一起<br>如果无法确定唯一性，可以使用组合键，组合键是指拼接多个业务字段。使用组合键时需要注意字段组合的顺序。比如一对多的关系，那么一应该放在前面，以便能够scan得到结果。
长度原则
rowkey是一个二进制码流，最大长度是64kb，建议越短越好。10-100长度即可，不要超过16个字节。数据的持久化文件HFile中式按照key-value存储的，如果rowkey过长比如100个字节，1000万列数据光rowkey就要占用100*1000万=10亿个字节，将近1G数据，这会极大影响HFile的存储效率<br>MemStore 将缓存部分数据到内存，如果 RowKey 字段过长，内存的有效利用率会降低，系统将无法缓存更多的数据，这会降低检索效率。因此 RowKey 的字节长度越短越好。目前操作系统是都是 64 位系统，内存 8 字节对齐。控制在16 个字节，8 字节的整数倍利用操作系统的最佳特性。<br> 根据不同的场景，在有些情况下，还需要对齐 RowKey 的长度：因为 RowKey 是按字典序排列的，所以需要对齐长度，比如 ID 取 12 位，9 位 ID 前就需要齐 3 个 0，否则就会出现 123456789 比 654321 排在前面的问题。对齐长度后，000000654321 就会排在 000123456789 之前，符合预期。<br>
