Hbase+Spring boot实战分布式文件存储-第4章-HBase的优化策略

4-1 HBase优化策略一：服务端优化策略

什么会导致HBase的性能下降
1.JVM内存分配与GC回收策略
这个是大部分java应用程序都会遇到的问题，这里不再阐述
2.与HBase运行机制相关的部分配置不合理
HBase写入时当memstore达到一定的大小会flush到磁盘保存成HFile，当HFile小文件太多会执行compact操作进行合并，对HBase来说，当每一个store只包含一个HFile时，查询效率才是最大的。如果小文件太多的话，查询的时候需要的寻址时间就会越长，因此HBase会通过合并已有的HFile来减少每次磁盘读取数据的寻道时间，从而提高读写速度，这个合并的过程叫做compact，在执行过程compact的过程中，就会阻塞数据的写入和读取。所以进行compact的时机就会很重要，要选择哪些文件，选择哪种线程池才能达到最大的性能，是一个很重要的决策。
当Region的大小达到一定的阈值时会执行split操作，分配到不同的RegionServer进行管理，这个操作也非常消耗资源，可能会导致当前的Region不能读取也不能写入。
上述引出了compact的概念
minor compaction：选取一些小的、相邻的 StoreFile 各他们合并成一个更大的 StoreFile (这里的StoreFile就是HFile)，合并的关键是选择哪些StoreFile进行合并，一次合并几个文件。
major compaction：将所有的 StoreFile 合并成一个 StoreFile，清理无意义数据：被删除的数据、 TTL 过期数据、版本号超过设定版本号的数据。这个过程对资源的消耗更大，是调优的重点。
spilt：当一个region达到一定的大小就会自动split成两个region。
HBase Compact检查
MemStore被fluh到磁盘
用户至此那个shell命令conpact，major compact或者调用了相应的API
HBase后台线程周期性触发检查
Hbase优化策略
常见服务端配置优化
JVM设置和GC设置
适当的增加RegionServer的内存，可以避免full FC，对各种block cache 也会很好的支持
hbase-site.xml部分属性配置
重要的属性如下
常见优化策略
HBase读写性能优化

HBase properties	简介	说明
hbase.regionserver.handler.count	rpc请求的线程数，默认值是10	提升handler的数量，可以提高接收请求的能力。其数量也取决的节点的硬件配置。比如作为文件存储是，scan或者普通几M的数据，如果设置的过大，会占用过多的内存，导致频繁的GC
hbase.hregion.max.filesize	最大HStoreFile大小。若某个列族的HStoreFile增长达到这个值，这个Hegion会被切割成两个。 默认: 10G.	可以根据存储的内容适当调整，在存储文件的时候，可以适当大一些，以为region在spilt的时候，会出现短暂的region下线（5s以内），鉴于对业务的影响，建议手动执行该操作。
hbase.hregion.majorcompaction	一个Region中的所有HStoreFile的major compactions的时间间隔。默认是1天。 设置为0就是禁用这个功能。	0，禁用，在生产上该操作可能持续的时间会很长。为减少业务的影响，建议在低峰的时候进行手动合并或者脚本定期执行操作
hbase.hstore.compaction.min	一个store里的storefile总数超过该值，会触发默认的合并操作。默认是3
hbase.hstore.compaction.max	每个“小”合并的HStoreFiles最大数量。默认: 10
hbase.hstore.blockingStoreFiles	当一个HStore含有多于这个值的HStoreFiles(每一个memstore flush产生一个HStoreFile)的时候，会执行一个合并操作，update会阻塞直到合并完成，直到超过了hbase.hstore.blockingWaitTime的值默认: 7	配置适当的短一点，避免memstore不能及时flush
hfile.block.cache.size	分配给HFile/StoreFile的block cache占最大堆(-Xmx setting)的比例。默认0.25意思是分配25%，设置为0就是禁用，但不推荐。默认:0.25
hbase.hregion.memstore.flush.size	当memstore的大小超过这个值的时候，会flush到磁盘。这个值被一个线程每隔hbase.server.thread.wakefrequency检查一下。默认:134217728	根据机器内存的大小，适当的设置大一点
hbase.hregion.memstore.block.multiplier	如果memstore有hbase.hregion.memstore.block.multiplier倍数的hbase.hregion.flush.size的大小，就会阻塞update操作。这是为了预防在update高峰期会导致的失控。如果不设上界，flush的时候会花很长的时间来合并或者分割，最坏的情况就是引发out of memory异常。(译者注:内存操作的速度和磁盘不匹配，需要等一等。原文似乎有误)默认: 2

具体的配置，还是要看我们的应用场景。
3.表结构设计及用户使用方式不合理

4-2 HBase优化策略二：常用优化策略

预先分区
创建HBase表的时候会自动出创建一个Region分区
创建HBase表的时候会预先创建一些空的Regions，并且规定好每个region的存储范围，所以指定范围内的数据就会被写入指定的region中，可以减少很多IO的操作，通过预先分区，可以有效的解决HBase一些数据倾斜的问题。可以将频繁访问的数据放入到多个region中，将不常访问的数据，放到几个Region中，可以有效的缓解数据倾斜问题。
RowKey优化
RowKey可以唯一标识一条数据，在HBase查询有两种操作，get：通过rowkey获取到某条记录，scan：通过startrow和stoprow之间的范围查询。利用HBase默认排序的特点，将一起访问的数据放到一起。防止热点问题，避免使用时序或者单调的递增递减等，设计rowkey的时候一般会通过加盐，hash，反转等方式避免热点问题。rowkey也尽量要太长。
Column优化
列族的名称和列的描述命名尽量短，同一张表中的ColumnFamily的数据量不要超过三个
Schema优化
高表：一种行多列少的设计
宽表：一种列多行少的设计
就查询性能来说，高表的性能更好，查询的条件可以防止rowkey中，一行的数据少可以缓存更多的行，以行数为单位的吞吐量，高表要比宽表高得多。对于元数据的开销，高表的开销更大，因为高表的行比较多，rowkey比较多，region也会比较多，对于事务性来说，宽表的事务性更好，因为HBase的事务是建立在行的基础上，宽表是行少列多，对于宽表的插入，可以有效的保证事务性，高表是多个行，更新的时候，没有事务性的保障。
在设计表的时候，根据场景灵活选择。

4-3 HBase优化策略三：读写优化策略

HBase写优化策略
同步批量提交或者异步批量提交，默认是同步提交，异步提交可能会丢失部分数据，在业务允许的情况下，是可以开启异步提交提高写的性能。
WAL（集群默认开启）优化，是否必须，持久化等级。Hbase写入是写入Memstore和HLog，两者都写入成功数据才算写入成功，写入memstore的延迟是很低的，如果想提高性能，只能从WAL入手，WAL一方面是为了确保写入过程中缓存丢失也可以进行数据恢复，另一方面是为了集群之间的异步复制，集群默认开启WAL，如果允许的部分异常情况下数据丢失，更关心写入的吞吐量，可以考虑关闭WAL或者采用WAL的异步写入。这些操作都可以提高HBase的写入能力，但是会影响数据的完整性。
HBase读优化策略
客户端：Scan缓存设置，批量获取
通常来讲，一次scan会返回大量的数据，客户端去发起scan请求的时候，实际上并不会一次就将所有的数据返回，而是分多次RPC请求加载，这样设计，一方面是因为大量的数据请求造成网络带宽严重消耗，影响到其他的业务，另一方面，也可能是数据量太大，造成客户端OOM。所以客户端会先加载一部分数据到本地，遍历出需要的，然后再加载一部分到本地处理，如此循环，直到所有的数据都加载完成。数据加载到本地就会存储到scan的缓存中，默认是100条的大小，如果数据量比较大，可以将cache设置的大一点，减少RPC的请求。
HBase只支持rowkey的索引，如果一个表有多个列族，那么这些列族是存在不同的range中，如果不去指定列族去检索，那么性能就会比较低。
服务端：BloxkCache配置是否合理，HFile是否过多。如果查询的时候，服务端的blockcache都不能有效的命中，那么对读性能的影响还是很大的。假如blockcache不能全部命中，就要从HFile中获取，这时候HFile的数据量，对于读性能的影响也是比较大的，要进行compact操作，合并数据。
表结构的设计：根据具体的业务场景，对表结构进行优化。

4-4 HBase协处理器简介

HBase 协处理器受 Bigtable 协处理器的启发，为用户提供类库和运行时环境，使得代码能够在 HBase Regionserver 和 Master上处理。由于协处理器直接作用在RegionServer上，直接接触数据，所以使用上会带来一定的风险，轻则会影响集群的性能，重则会破坏数据。
协处理器分为：系统协处理器和表处理器
协处理器：全局加载到 Regionserver 托管的所有表和 Region 上
表协处理器：用户可以指定一张表使用协处理器
系统处理器分为：Observer 和Endpoint
观察者（ Observer ) ：类似于关系数据库的触发器
       Regionobserver ：提供客户端的数据操纵事件钩子： Get 、 Put 、 Delete 、 Scan 等。
       Masterobserver ：提供 DDL 类型的操作钩子。如创建、删除、修改数据表等 。
       WAL0bserver ：提供 WAL 相关操作钩子
observer 应用场景
安全性：例如执行 Get 或 Put 操作前，通过 preGet 或 prePut 方法检查是否允许该操作．
引用完整性约束：HBase 并不支持关系型数据库中的引用完整性约束概念，即通常所说的外键。我们可以使用协处理器增强这种约束
终端（ Endpoint ) ：动态的终端有点像存储过程
Endpoint 是动态 RPC 插件的接口，它的实现代码被安装在服务器端，从而能够通过 HBase RPC 唤醒
调用接口，它们的实现代码会被目标 RegionServer 远程执行
典型的案例：一个大 Table 有几百个 Region ，需要计算某列的平均值或者总和

4-5 开发RegionObserver协处理器