HBase的一些高级特性

---

HBase过滤器

1.基于行的过滤器

名称	说明
PrefixFilter	行的前缀匹配
PageFilter	基于行的分页

2.基于列的过滤器

名称	说明
ColumnPrefixFilter	列前缀匹配
FirstKeyOnlyFilter	只返回每一行的第一列

3.基于单元值的过滤器

名称	说明
KeyOnlyFilter	返回的过滤器不包含单元值，只包含行健与列
TimestampsFilter	根据数据的时间戳版本进行过滤

4.基于列和单元值的过滤器

名称	说明
SingleColumnValueFilter	对该列的单元值进行比较过滤
SingleColumnValueExcludeFilter	对该列的单元值进行比较过滤

HBase的优化策略

导致HBase性能下降的原因

1.Jvm的内存分配与GC的回收策略
2.与HBase的运行机制相关的部分配置不合理
3.表结构的设计和用户的使用方式不合理

在HBase的存储过程中，对HBase来说每一个MemStore仅包含一个HFile的时候查询的效率才是最大的，因为当存储的小文件过多的时候，查询的寻址时间就会更长，因此HBase会合并已有的HFile来减少每次读取时的寻址时间从而提高读取的速度，这个过程叫做compact操作。但是在执行这个的过程中会出现阻塞数据的读取和写入，那么什么时候去执行compact操作是一个相当复杂的决策，这个考虑因素有我们需要选择哪些文件，选择哪些合适的线程池才能达到最大的性能，需要考虑多方面的因素。
当一个region的大小达到一定的阈值的时候，会执行split操作，这也是一个很消耗资源的操作，期间的性能也不会太高，可能会导致当前的region不能读取和写入。

HBase的compact时机
1.MemStore被flush到磁盘的时候
2.用户执行shell命令compact、major_compact或者调用了相应的API
3.HBase后台线程周期性的触发检查

name	desc
minor compaction	选取一些小的，相邻的StoreFile并将它们合并成更大的StoreFile
major compaction	将所有的StoreFile合并成一个StoreFile，清理没有意义的数据（被删除的数据，TTL过期数据，版本号超过版本号的数据）
split	当一个region达到一定的大小的时候，就会自动split成2个region

优化策略

1.常见的服务端优化（hbase-site.xml的一些属性合理的配置）
2.常用的优化策略，以实际需求为主，表设计等等
3.HBase的读写性能的优化

常见的服务端优化

1.Jvm的内村设置，可将JVm的内存大小进行合理的设置
2.hbase-site.xml常用属性

名称	说明
hbase.regionserver.handler.count	rpc请求线程数量。默认是10，这个值不是越大越好，它取决于节点的配置，若设置的过大会占用过多的内存导致频繁的GC甚至是内村溢出
hbase.hregion.max.filesize	当region的大小大于设定的值以后hbase就会split，默认大小是10G，这个值需要根据存储的内容进行设置，比如存储文件的话应该设置的更大，因为region分裂的时候有短暂的region下线时间通常在5秒以内，为减少对业务端的影响建议手动执行
hbase.hregion.majorcompaction	major compact的执行周期，默认是一天建议将其设置为0，禁止自定majorcompact，因为在生产上执行majorcompaction的时间可能是数小时之久，为了减少对业务端的影响，建议在业务低峰的时候手动执行，或者通过脚本，java api定期的去执行
hbase.hstore.compaction.min	一个store里的storeFile总数超过该值，会触发默认的合并操作，默认值是3
hbase.hstore.compaction.max	一次最多合并多少个storeFile，如果合并的时候数量过大应该适当的减少合并数量避免内存溢出
hbase.hstore.blockingStoreFile	一个region中的store（Column Family）内有超过xx个StoreFile时，会阻塞掉所以的写请求来进行compaction，这个期间会阻塞写操作，知道compaction完成或者我们设定的超时默认是90秒，这个值可以设置的稍微大一点，其他相关的参数可以设置的短一点，来避免memstore不能进行及时的flush操作
hfile.block.cache.size	regionserver的block cache的内存大小限制，如果偏向读的业务这个值可以适当的设置大一点
hbase.hregion.memstore.flush.szie	memStore超过该值将被flush
hbase.hregion.memstore.block.multiplier	如果memstore的内存大小超过flush.size乘以multiplier,会阻塞该memstore的写操作

hbase详细的配置可参考这个博客：https://blog.csdn.net/ningxuezhu/article/details/50547970

HBase常用优化策略

1.预先分区
HBase在建表的时候默认只会在regionserver上建立一个region分区，写数据的时候全部写到region上，当这个region达到一定大小的时候再进行split操作，将其进行分割成2个region以后再进行负载均衡。而HBase在进行split的时候是非常耗时并且会造成region暂时无法访问的情况，所以我们可以在建表的时候预先的去创建一些空的regions，并且规定region存储的rowkey的范围，这样指定范围的数据就会存储到指定的region上 ，这样减少了很多的IO操作，并且预先分区还可以有效的解决HBase中数据倾斜的问题：可以将经常访问的数据放入指定的一个或者多个region上，不常访问的数据放到另外指定的region上。

2.rowkey优化
rowkey是三维有序的，通过rowkey，column key（column family和column qualifier）、时间戳这三个维度对hbase中的数据进行快速定位，查询的方式有2种，一种是get，通过rowkey获取某条记录，一种是scan加上startrow和stoprow这个范围进行查询，所以rowkey的设计直接影查询效率。

热点问题：
在分布式的系统中大量的client集中的去访问集群中一个或者极少数的节点，大量的访问会超出节点的承受能力，从而影响整个集群的性能，这就要求我们在设计rowkey的时候避免使用时序或者单调递增/递减的方式设计rowkey，一般会通过加盐（在rowkey前面添加随机数）或者hash、反转等方式来解决rowkey的热点问题。
rowkey符合唯一原则，并且要尽可能的简短，减少对内存的占用

3.Column优化
列簇的名称和列的描述要尽可能的简短，减少对内存的占用，建议列簇不超过三个

4.Schema优化
宽表：一种 “列多行少” 的设计
高表：一种 “列少行多” 的设计
就查询来说，高表较好，因为查询的条件我们可以放在rowkey中一行的数据也更少缓存也可以缓存更多的行，所以以行数为单位的吞吐量高表比宽表要高的多，对于原数据来说，高表的开销就要比宽表的开销大了，因为它的行比较多，rowkey就比较多，region也比较多。
就事物来说，宽表的事物就比高表的好，因为hbase的事物是建立在行上的,宽表一个行有多个列，在插入的时候一行多列的事物性就要比插入多行好，高表是多行的，这样在进行事物更新的时候事物性的保障就没有这么好了。

HBase写优化

HBase默认提供同步提交，要么全部成功，要么失败报错，当然数据也可以异步提交，而异步提交可能会丢失部分数据，在业务允许的情况下我们是可以开启异步提交的来提高写的性能。数据写入的过程中我们可以理解成为写入memstore和HLog，也就是WAL预写日志，二者都必须都成功。WAL一方面是为了确保数据写入过程当中缓存丢失了也可以进行数据恢复，另一方面是为了集群之间的异步复制，HBase集群默认WAL集群是开启的，如果说我们的业务允许，对于异常情况下的部分数据丢失可以忍受，更关心写入的吞吐量，这个时候我们就可以考虑到关闭WAL，或者是采用WAL的异步操作，这些都可以对HBase的写入性能带来提升，但是对于数据的完整性都有一定的损失

HBase读优化策略

客户端设置scan缓存设置，批量获取

服务端的缓存：
如果每次查询的时候服务端的缓存都不能有效的命中，这个对于读的
性能还是比较大的，这个时候就要考虑BLockCache配置是否合理

表结构的设计问题优化

HBase备份与恢复

1.CopyTable
2.Export/Imoport
3.Snapshot
4.Replication

CopyTable

支持时间区间、row区间，改变表名称，改变列簇名称，指定是否copy已经被删除的数据的功能，CopyTable工具采用scan查询，写入新表时采用put和delete API，全是基于hbase的Client API进行读写

Export/Import

Export可导出数据到目标集群，然后可在目标集群上Import导入数据，Export支持指定开始时间和结束时间，因此可以做增量备份，Export导出工具与CopyTable一样是依赖HBase的scan读取数据

Snapshot

通过配置实现：
hbase.snapshot.enabled的值为true即可
Snapshot即快照的意思，作用于表上，通过配置hbase-site.xml开启该功能，可以快速的恢复表至快照指定的状态从而迅速的恢复数据（会丢失快照之后的数据）

Replication

hbase.replication设置为true即开启功能
可以通过replication机制实现hbase集群的主从模式
replication是依赖于WAL日志进行同步的

总结四种备份方式

CopyTable和Export/Import本身是基于MapReduce的，性能不太高，比较常用的是replication和snapshot，replication本质是利用一个协处理器去对WAL进行顺序读取达到备份的目的，snapshot作用于表上，实际上是针对元数据的快照并不直接备份HFile，所以说它可以快速的将表恢复到快照的状态，从而迅速的进行数据的修复