大数据培训学习过程中，常常会应用到HBase高级个性，在论述HBase高级个性和热点问题解决前，首先回顾一下HBase的特点：分布式、列存储、反对实时读写、存储的数据类型都是字节数组byte[]，次要用来解决结构化和半结构化数据，底层数据存储基于hdfs。
同时，HBase和传统数据库一样提供了事务的概念，然而HBase的事务是行级事务，能够保障行级数据的原子性、一致性、隔离性以及持久性。
布隆过滤器在HBase中的利用
布隆过滤器（Bloom Filter）是空间利用效率很高的数据结构，利用位数组示意一个汇合，判断一个元素是否属于该汇合。但存在肯定的错误率，在判断一个元素是否属于某个汇合时，有可能会把不属于这个汇合的元素误认为属于这个汇合，所以实用于能容忍肯定错误率的场景下。
布隆过滤器是HBase的高级功能属性，它可能升高特定拜访模式下的查问工夫，然而会减少内存和存储的累赘，是一种以空间换工夫的典型利用，默认为敞开状态。
能够独自为每个列族独自启用布隆过滤器，能够在建表时间接指定，也能够通过应用HColumnDescriptor.setBloomFilterType对某个列族指定布隆过滤器。
目前HBase反对以下3种布隆过滤器类型：
NONE：不应用布隆过滤器（默认）
ROW：行键应用布隆过滤器过滤
ROWCOL；列键（row key + column family + qualifier）应用布隆过滤器过滤
下图展现了何种状况下应用布隆过滤器，个别倡议应用ROW模式，它在额定的存储空间开销和利用抉择过滤存储文件晋升性能方面做了很好的衡量，具体应用哪一种，要看具体的应用场景：

协处理器
HBase协处理器目前分为两种observer和endpoint，二者能够联合应用，都是运行在HBase服务端的。
1.observer
与RDBMS的触发器相似，运行客户端在操作HBase集群数据过程中，通过钩子函数在特定的事件（包含一些用户产生和服务期外部主动产生的事件）产生时做一些预处理（如插入之前做一些业务解决）和后处理（如插入之后做出响应等）的操作。
observer提供的几个典型的接口：
RegionObserver：解决数据批改事件。典型的利用场景就是用作解决HBase二级索引，如在put前在针对解决的数据生成二级索引，解决引擎能够通过MapReduce做，也能够将生成的二级索引存储在solr或者es中
MasterObserver：治理或DDL类型的操作，针对集群级的事件
WALObserver：提供针对WAL的钩子函数
2.endpoint
相似于RDBMS中的存储过程，能够通过增加一些近程过程调用来动静扩大RPC协定。容许扩大集群的能力，对客户端利用自定义开发新的运算命令，用户代码能够被部署到服务端
列族设计
一个列族在数据底层是一个文件，所以将常常一起查问的列放到一个列族中，同时尽可能创立较少数量的列族，且不要频繁批改，这样能够缩小文件的IO、寻址工夫，从而进步性能。
row key设计
HBase中rowkey能够惟一标识一行数据，在HBase查问的时候，次要以下两种形式：
get：指定rowkey获取惟一一条记录
scan：设置startRow和stopRow参数进行范畴匹配
在设计row key时，首先要保障row key惟一，其次要思考以下几个方面：
1.地位相关性
存储时，数据依照row key的字典程序排序存储。设计row key时，要充分考虑排序存储这个个性，将常常一起读取的行存储放到一起。
2.row key长度
row key是一个二进制码流，能够是任意字符串，最大长度 64kb ，个别为10-100bytes，起因如下：
1）HBase数据的长久化文件hfile是依照Key Value存储的，如果row key过长，当存储的数量很大时，仅row key就会占据很大空间，会极大影响hfile存储效率
2）row key设计过长，memstore缓存到内存的数据就会绝对缩小，检索效率低
3.row key散列性
row key是依照字典顺序存储的，如果row key依照递增或者工夫戳递增生成，那么数据可能集中存储在某几台甚至某一台region server上，导致某些region server的负载十分高，影响查问效率，重大了可能导致region server宕机。
因而，能够将row key的一部分由程序生成散列数字，将row key打散，均匀分布在HBase集群中的region server上，具体分为以下几种解决形式：
1）反转
通过反转固定长度或数字格局的row key，将row key中常常变动的局部（即绝对比拟随机的局部）放在后面，这种形式的弊病就是失去了rowkey的有序性。
最罕用的就是，用户的订单数据存储在HBase中，利用手机号后4位通常是随机的的个性，以用户的手机号反转再依据业务场景加上一些其余数据拼成row key或者是仅仅应用反转后的手机号作为row key，从而防止以手机号固定结尾导致的热点问题。
2）加盐
并非密码学中的加盐，而是通过在row key加随机数前缀，前缀品种数应和你想使数据扩散到不同的region的数量保持一致。
3）哈希散列形式
利用一些哈希算法如MD5，生成哈希散列值作为row key的前缀，确保region所治理的start-end rowkeys范畴尽可能随机。
HBase热点问题及解决
HBase中热点问题其实就是数据歪斜问题，因为数据的调配不平均，如row key设计的不合理导致数据过多集中于某一个或某几个region server上，会导致这些region server的拜访压力，造成性能降落甚至不可能提供对外服务。
还有就是，在默认一个region的状况下，如果写操作比拟频繁，数据增长太快，region 决裂的次数会增多，比拟耗费资源。
次要通过两种形式相结合，row key设计（具体参考上文）和预分区。
这里次要说一下预分区，个别两种形式：
1.建表时，指定分区形式。如create 't1', 'f1', SPLITS => ['10', '20', '30', '40']
2.通过程序生成splitKeys，程序中建表时指定splitKeys
但这两种形式也并非一劳永逸，因为数据是一直地增长的，曾经划分好的分区可能承载不了更多的数据，就须要进一步split，但随之带来的是性能损耗。所以咱们还要布局好数据增长速率，定期察看保护数据，依据理论业务场景剖析是否要进一步分区，或者极其状况下，可能要重建表做更大的预分区而后进行数据迁徙。
作者：大数据学习与分享