HBase集群优化篇
作者：尹正杰
版权声明：原创作品，谢绝转载！否则将追究法律责任。
一.HBase的高可用实战案例
博主推荐阅读: https://www.cnblogs.com/yinzhengjie2020/p/12274860.html
二.HBase预分区
博主推荐阅读: https://www.cnblogs.com/yinzhengjie2020/p/12914075.html
三.rowkey设计原则
一条数据的唯一标识就是rowkey，那么这条数据存储于哪个分区，取决于rowkey处于哪个一个预分区的区间内，设计rowkey的主要目的 ，就是让数据均匀的分布于所有的region中，在一定程度上防止数据倾斜。
接下来我们就谈一谈rowkey的设计原则及常用的设计方案。
1>.rowkey的三大设计原则
(1)唯一性原则: 这个很好理解，RowKey的角色类似于关系型数据库当中的主键，因此Rowkey不能重复。 举个例子,使用用户姓名作为RowKey就很不适合，究其原因是因为姓名太容易重复了,如果非要用姓名作为RowKey就得考虑加一些后缀来做区分。 rowkey在设计上保证其唯一性。rowkey是按照字典顺序排序存储的，因此，设计rowkey的时候，要充分利用这个排序的特点，将经常读取的数据存储到一块，将最近可能会被访问的数据放到一块。
(2)长度原则: 而设计太长会导致占用更多的存储空间影响查询效率，设计的太短对业务要求查询也不是特方便。因此在能满足查询条件的情况下，RowKey设计的越短越好。 虽然RowKey最大长度是64KB，实际应用中长度一般为10-100bytes。以byte[] 形式保存，一般设计成定长。
建议越短越好，不要超过16个字节，原因如下：
(a)数据的持久化文件HFile中是按照KeyValue存储的，如果rowkey过长，比如超过100字节，1000w行数据，光rowkey就要占用100*1000w=10亿个字节，将近1G数据，这样会极大影响HFile的存储效率；
(b)MemStore将缓存部分数据到内存，如果rowkey字段过长，内存的有效利用率就会降低，系统不能缓存更多的数据，这样会降低检索效率。
(c)目前操作系统都是64位系统，内存8字节对齐，控制在16个字节，8字节的整数倍利用了操作系统的最佳特性。 (3)散列原则: 让RowKey没有规律，可以实现均匀分配。 如果rowkey按照时间戳的方式递增，不要将时间放在二进制码的前面，建议将rowkey的高位作为散列字段，由程序随机生成，低位放时间字段，这样将提高数据均衡分布在每个RegionServer，以实现负载均衡的几率。
如果没有散列字段，首字段直接是时间信息，所有的数据都会集中在一个RegionServer上，这样在数据检索的时候负载会集中在个别的RegionServer上，造成热点问题，会降低查询效率. 常见的散列手段如下:
(a)加盐：
这里所说的加盐不是密码学中的加盐，而是在rowkey的前面增加随机数，具体就是给rowkey分配一个随机前缀以使得它和之前的rowkey的开头不同。
分配的前缀种类数量应该和你想使用数据分散到不同的region的数量一致。加盐之后的rowkey就会根据随机生成的前缀分散到各个region上，以避免热点. (b)哈希：
哈希会使同一行永远用一个前缀加盐。哈希也可以使负载分散到整个集群，但是读却是可以预测的。使用确定的哈希可以让客户端重构完整的rowkey，可以使用get操作准确获取某一个行数据。 (c)反转：
第三种防止热点的方法时反转固定长度或者数字格式的rowkey。这样可以使得rowkey中经常改变的部分(最没有意义的部分)放在前面。这样可以有效的随机rowkey，但是牺牲了rowkey的有序性。
反转rowkey的例子以手机号为rowkey，可以将手机号反转后的字符串作为rowkey，这样的就避免了以手机号那样比较固定开头导致热点问题。 (d)时间戳反转：
一个常见的数据处理问题是快速获取数据的最近版本，使用反转的时间戳作为rowkey的一部分对这个问题十分有用，可以用Long.Max_Value - timestamp追加到key的末尾。
例如[key][reverse_timestamp] ,[key]的最新值可以通过scan [key]获得[key]的第一条记录，因为HBase中rowkey是有序的，第一条记录是最后录入的数据。比如需要保存一个用户的操作记录，按照操作时间倒序排序，在设计rowkey的时候，可以这样设计[userId反转][Long.Max_Value - timestamp]，在查询用户的所有操作记录数据的时候，直接指定反转后的userId，startRow是[userId反转][000000000000],stopRow是[userId反转][Long.Max_Value - timestamp]如果需要查询某段时间的操作记录，startRow是[user反转][Long.Max_Value - 起始时间]，stopRow是[userId反转][Long.Max_Value - 结束时间]
2>.生成随机数，hash，散列值
举个例子:
原本rowKey为1001的，SHA1后变成：dd01903921ea24941c26a48f2cec24e0bb0e8cc7
原本rowKey为3001的，SHA1后变成：49042c54de64a1e9bf0b33e00245660ef92dc7bd
原本rowKey为5001的，SHA1后变成：7b61dec07e02c188790670af43e717f0f46e8913
在做此操作之前，一般我们会选择从数据集中抽取样本，来决定什么样的rowKey来Hash后作为每个分区的临界值。
3>.字符串反转
假设有以下3个订单编号: 20200531000001 20200531000002 20200531000003 反转后: 10000013500202 20000013500202 30000013500202 如果按照上面的字符串作为RowKey则很有可能这3个订单被写入到同一个Region中，但是如果我们做一个反转操作后，很可能这3条订单数据被写入到3个不同的Region中。
4>.字符串拼接
举个例子:
20200531000001_a1b2c3
20200531000001_abcdef
四.内存优化
HBase操作过程中需要大量的内存开销，毕竟Table是可以缓存在内存中的，一般会分配整个可用内存的70%给HBase的Java堆。 但是不建议分配非常大的堆内存，因为GC过程持续太久会导致RegionServer处于长期不可用状态，一般16~48G内存就可以了，如果因为框架占用内存过高导致系统内存不足，框架一样会被系统服务拖死。 博主推荐阅读: https://www.cnblogs.com/yinzhengjie/tag/JVM/
五.HBase配置基础优化
1>.允许在HDFS的文件中追加内容
配置文件:
hdfs-site.xml、hbase-site.xml
相关参数:
dfs.support.append
参数说明:
开启HDFS追加同步，可以优秀的配合HBase的数据同步和持久化。默认值为true。
2>.优化DataNode允许的最大文件打开数
配置文件:
hdfs-site.xml
相关参数:
dfs.datanode.max.transfer.threads
参数说明:
HBase一般都会同一时间操作大量的文件，根据集群的数量和规模以及数据动作，设置为8192或者更高。默认值：4096。
3>.优化延迟高的数据操作的等待时间
配置文件:
hdfs-site.xml
相关参数:
dfs.image.transfer.timeout
参数说明:
如果对于某一次数据操作来讲，延迟非常高，socket需要等待更长的时间，建议把该值设置为更大的值（默认60000毫秒），以确保socket不会被timeout掉。
4>.优化数据的写入效率
配置文件:
mapred-site.xml
相关参数: mapreduce.map.output.compress mapreduce.map.output.compress.codec
参数说明:
开启这两个数据可以大大提高文件的写入效率，减少写入时间。第一个属性值修改为true，第二个属性值修改为：org.apache.hadoop.io.compress.GzipCodec或者其他压缩方式。
5>.设置RPC监听数量
配置文件:
hbase-site.xml
相关参数:
hbase.regionserver.handler.count
参数说明:
默认值为30，用于指定RPC监听的数量，可以根据客户端的请求数进行调整，读写请求较多时，增加此值。
6>.优化HStore文件大小
配置文件:
hbase-site.xml
相关参数:
hbase.hregion.max.filesize
参数说明:
默认值10737418240（10GB），如果需要运行HBase的MR任务，可以减小此值，因为一个region对应一个map任务，如果单个region过大，会导致map任务执行时间过长。
该值的意思就是，如果HFile的大小达到这个数值，则这个region会被切分为两个Hfile。
7>.优化hbase客户端缓存
配置文件:
hbase-site.xml
相关参数:
hbase.client.write.buffer
参数说明:
用于指定HBase客户端缓存，增大该值可以减少RPC调用次数，但是会消耗更多内存。一般我们需要设定一定的缓存大小，以达到减少RPC次数的目的。
8>.指定scan.next扫描HBase所获取的行数
配置文件: hbase-site.xml
相关参数: hbase.client.scanner.caching
参数说明: 用于指定scan.next方法获取的默认行数，值越大，消耗内存越大。
9>.协处理器(coprocessor)配置
配置文件: hbase-site.xml 相关参数: hbase.coprocessor.abortonerror 参数说明: 如果设置为true，则当协处理器加载失败、初始化失败或抛出意外的可丢弃对象时，将导致宿主服务器（主服务器或区域服务器）中止。
将此设置为false将允许服务器继续执行，但相关协处理器的系统范围状态将变得不一致，因为它将仅在服务器的子集中正确执行，因此这对于仅调试非常有用。
生产环境建议设置成false以增强HRegionServer的可用性。
10>.Flush、Compact、Split机制
Flush机制: 当MemStore达到阈值，将Memstore中的数据Flush进Storefile,128M就是Memstore的默认阈值。 Compact机制: compact机制则是把Flush出来的小文件合并成大的Storefile文件。 Spilt机制: split则是当Region达到阈值，会把过大的Region一分为二。 相关参数说明： hbase.hregion.memstore.flush.size：134217728 这个参数的作用是当单个HRegion内所有的Memstore大小总和超过指定值时，flush该HRegion的所有memstore。RegionServer的flush是通过将请求添加一个队列，模拟生产消费模型来异步处理的。 那这里就有一个问题，当队列来不及消费，产生大量积压请求时，可能会导致内存陡增，最坏的情况是触发OOM。 hbase.regionserver.global.memstore.upperLimit：0.4 hbase.regionserver.global.memstore.lowerLimit：0.38 当MemStore使用内存总量达到hbase.regionserver.global.memstore.upperLimit指定值时，将会有多个MemStores flush到文件中； MemStore flush 顺序是按照大小降序执行的，直到刷新到MemStore使用内存略小于hbase.regionserver.global.memstore.lowerLimit(该值默认值大小是"hbase.regionserver.global.memstore.upperLimit"的95%)。
hbase.regionserver.optionalcacheflushinterval:3600000
内存中的文件在自动刷新之前能够存活的最长时间，默认是1H.
hbase.regionserver.region.split.policy:org.apache.hadoop.hbase.regionserver.IncreasingToUpperBoundRegionSplitPolicy
region在切分的时候的默认切分策略,不同版本的切分策略是不一样的，org.apache.hadoop.hbase.regionserver.IncreasingToUpperBoundRegionSplitPolicy是1.3.1版本的默认切分策略。
hbase.regionserver.regionSplitLimit:1000
当某个HRegionServer上的region到达这个限制时，不会在进行region切分，也就是一个HRegionServer默认最大允许有1000个region。
hbase.hregion.memstore.block.multiplier:4
当一个HRegion上的memstore的大小满足hbase.hregion.memstore.block.multiplier * hbase.hregion.memstore.flush.size, 这个HRegion会执行flush操作并阻塞对该HRegion的写入。
hbase.hregion.majorcompaction:604800000
一个region进行 major compaction合并的周期,在这个点的时候， 这个region下的所有hfile会进行合并,默认是7天,major compaction非常耗资源,建议生产关闭(设置为0)，在应用空闲时间手动触发。
hbase.hstore.compaction.max:
每个minor compaction操作的 允许的最大hfile文件上限。