共计 2670 个字符，预计需要花费 7 分钟才能阅读完成。
大数据培训 学习过程中，常常会应用到 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，但随之带来的是性能损耗。所以咱们还要布局好数据增长速率，定期察看保护数据，依据理论业务场景剖析是否要进一步分区，或者极其状况下，可能要重建表做更大的预分区而后进行数据迁徙。
作者：大数据学习与分享
