后果

• 我们知道一个RegionServer上有n个region,每个region会根据不同的col family数拥有不同的store,每个store有一块自己的memstore内存区和多个HFile文件,所以在region很多的情况下,平均RegionServer分担的Region就会多了,那么一台RegionServer上资源是优先的,并且多个region都有自己的memstore,所以就会争抢资源,一直与memstore比较小了,所以在memstore很小的时候,就会频繁的刷HFile,那么memstore刷出来的HFile也就相应的变小了,所以为了保证HFile的数量合理,就会发生大规模的合并,那么合并就会拖慢性能,甚至导致Full GC的发生.这就会造成RegionServer与ZK可能发生失联,那么就会造成一系列的错误

主要的问题可能会有

• 合并风暴,因为HFile文件多
• 客户端超时,因为合并可能会涉及集群中网络的IO风暴
• 批量加载超时,因为RegionServer太忙了无法反应,可能会报出RegionTooBusyException异常

原因

• Region最大值设置的太小
• 新HBase版本用了旧版本配置了,比如之前的HBase拆分上限是1G.现在是10G
• 预分区不合理
• 等等等...

解决参考

• Region 过多的问题的最终目的是使Region总数降低,也就是说进行合并Region
• 在0.98之前只支持离线的合并,这个过程需要暂时数据写入,并且需要先关闭集群然后执行合并操作,然后再启动集群.这样柑橘已经没有了学习价值了就不做笔记了
• 0.98之前还有一个CopyTable工具可以使用,将一个表拷贝到另一个新的预分裂的表,但是这需要有个问题,就是如果你之前put或者修改数据的时候是自己定义的时间戳,那么Copy到新表的时候,如果新表与旧表中有重复列,并且自定义的时间戳比当前重复列的时间戳小,那么就会造成数据的永久丢失,并且Copy一个大表的话会相当耗费时间
• 0.98之后加入了在线合并,合并的时候将不需要关闭集群了,将表禁用disable即可,在线合并可以通过hbase shell 或者 javaapi来操作,合并完成后,可以从HBase的web页面看到结果

防范

• 列族不易太多,400个拥有两个列族的region,不如800个拥有一个列族的region
• 保证最大的文件大小设置为至少10G,有些region小于10G没问题,但是要确保在必要的情况下,region能达到10GB,推荐使用可视化工具监控region大小,留意增长速度快的region,在非高峰情况下将他们拆分
• 有时候在负载比较小的情况下,可能会创建很多小region,为了确保region能增长到正常大小,要确保hbase.hregion.max.filesize siz的属性设置为至少10GB,也可以将最大文件大小设置更大,比如100GB,当使用较大的region大小的时候,我们就可以手动拆分,确保split时间合适,这是对集群的影响最小的操作

行键和表设计

• 这我总感觉有很多需要注意的地方,我会在之后学习并总结成学习笔记的

自己的总结

• 看到这总的来说,除了行键和表设计自己没有学,本文主要学习到了Region的大小不能设置太小,列族不能太多,也可以在设置split规则的情况下把大小设置的大一点以便自己在集群非高峰的情况下进行拆分,而预设split而并非禁用split是因为防止忘记region需要需要拆分了,而导致region增长的非常大以至于速度变慢,其实结合之前学习还要相当注意Full GC的回收策略的使用等一些需要注意的事项