写在前面： 我是
「nicedays」，一枚喜爱做特效，听音乐，分享技术的大数据开发猿。这名字是来自world order乐队的一首HAVE A NICE DAY。如今，走到现在很多坎坷和不顺，如今终于明白nice day是需要自己赋予的。
白驹过隙，时光荏苒，珍惜当下~~
写博客一方面是对自己学习的一点点总结及记录，另一方面则是希望能够帮助更多对大数据感兴趣的朋友。如果你也对大数据与机器学习感兴趣，可以关注我的动态https://blog.csdn.net/qq_35050438，让我们一起挖掘数据与人工智能的价值~
文章目录
HBase调优：
Region管理：
Region拆分- 当一个Region大到一定程度，会进行（split）
- HBase可以通用Region Split 达到负载均衡
Region合并- 如果删除了大量数据，很多region变小，这个时候region多个就会很浪费
Region拆分：
自动拆分：
- constantSizeRegionSplitPolicy
- IncreasingToUpperBoundRegionSplitPolicy（默认）
Math.min(tableRegionCounts ^ 3 * initialSize,defaultRegionMaxFileSize)
tableRegionCounts 就是字面意思
initialSize 默认为memstore2倍
defaultRegionMaxFileSize ：region最大大小。默认10G
假设只有一个region，memstore是128M，10g
min(1 ^ 3 * 2 * 128, 10G) = 256M
也就是当达到256M时，就会拆分
同理2个region时，当每个region达到2G时会拆分
3个region时，当每个region达到6.75G时会拆分
4个region时，当每个region达到10G时会拆分
4个往上就都是10G
手动选择拆分算法预拆分：
# HexStringSpli 以16进制分割得算法
# -c是个数 -f为列簇名
hbase org.apache.hadoop.hbase.util.RegionSplitter my_split_table HexStringSplit -c 10 -f mycf
hbase shell查看或者网页查看
scan 'hbase:meta', {STARTROW=> 'my_split_table', LIMIT=>10}
192.168.56.101：60010
HexStringSpit拆分算法：
HexStringSplit 把数据从“00000000”到“FFFFFFFF”之间的数据长度按照 n 等分之后算出每一段的起始 rowkey 和结束 rowkey，以此作为拆分点。
UniformSplit拆分算法：
UniformSplit 有点像 HexStringSplit 的 byte 版，不管传参还是 n，唯一不一样
的 是 起 始 和 结 束 不 是 String ， 而 是 byte[] 。起始 rowkey 是ArrayUtils.EMPTY_BYTE_ARRAY。结束rowkey是new byte[] {xFF, xFF, xFF, xFF, xFF, xFF, xFF, xFF}。最后调用 Bytes.split 方法把起始 rowkey 到结束 rowkey 之间的长度 n 等分，然后取每一段的起始和结束作为拆分点。默认的拆分点算法就这两个。还可以通过实现 SplitAlgorithm 接口实现自己的拆分算法。或者干脆手动定出拆分点.
手动指定拆分点预拆分：
create 'test_split2' ,'mycf2',SPLITS=>['aaa','bbb','ccc','ddd']
# split_file文件里写aaa,bbb,ccc,ddd
create 'test_split2' ,'mycf2',SPLITS_FilE=>'/opt/xxx.txt'
对指定region进行强制拆分：
# 指定id进行拆分
split 'ac0b0532f5daedb5d021f0175be7c51f.'
Region合并：
Log-Structured Merge（LSM）
- 区别于传统·数据库得更新现有数据
- 使用类似日志结构合并LSM得方式
- 只需要将值写到log末尾然后进行排序
- 优点：插入和更新数据非常快
- 缺点：占用更多空间
| 传统数据库· | LSM系统 |
|---|---|
| 更新现有数据，随机读写 | 只需要将值写到log末尾然后进行排序 |
-
Compaction分为Minor和Major两种
MinorCompaction--事件触发- 将小文件合并成更少得大型文件–假删除
Major Compaction--时间触发- 将一个HStore中的所有文件合并成一个大文件–真正的删除
-
每次触发compact检查时，系统自动决定执行哪一种–3种
- 通过 CompactionChecker 线程来定时检查是否需要执行 compaction
（RegionServer 启动时在 initializeThreads() 中初始化），每隔 10000 秒
（可配置）检查一次。 - 每当 RegionServer 发生一次 Memstore flush 操作之后也会进行检查是
否需要进行 Compaction 操作。 - 手动触发，执行命令 major_compact 、 compact、
- 通过 CompactionChecker 线程来定时检查是否需要执行 compaction
Flush和Compact操作
-
flush操作
flush '表名' -
compact操作
#compact一个表的所有regions compact 't1' #compact某个空闲的region compact 'r1' #compact一个region的指定列簇 compact 'r1','c1' #compact一个表的指定列簇 compact 't1','c1'
为什么需要合并Region?
那为什么需要合并Region呢？这个需要从Region的Split来说。当一个Region被不断的写数据，达到Region的Split的阀值时（由属性hbase.hregion.max.filesize来决定，默认是10GB），该Region就会被Split成2个新的Region。随着业务数据量的不断增加，Region不断的执行Split，那么Region的个数也会越来越多。
一个业务表的Region越多，在进行读写操作时，或是对该表执行Compaction操作时，此时集群的压力是很大的。这里笔者做过一个线上统计，在一个业务表的Region个数达到9000+时，每次对该表进行Compaction操作时，集群的负载便会加重。而间接的也会影响应用程序的读写，一个表的Region过大，势必整个集群的Region个数也会增加，负载均衡后，每个RegionServer承担的Region个数也会增加。
因此，这种情况是很有必要的进行Region合并的。比如，当前Region进行Split的阀值设置为30GB，那么我们可以对小于等于10GB的Region进行一次合并，减少每个业务表的Region，从而降低整个集群的Region，减缓每个RegionServer上的Region压力。