活跃Region数对HBase运行集群的影响

举报
Lettle whale 发表于 2020/05/14 14:32:08 2020/05/14
【摘要】 活跃Region数过多会对HBase运行产生影响,合理设计Rowkey可以有效提升性能

HBase在设计上,遵循了LSM-Tree的原理:写数据阶段,尽最大努力先将每一个Region的数据保留在内存(MemStore)中,等达到一定的阈值(默认为64M)之后,再将这些数据固化(Flush)到文件(HFile)中。在这过程中,为了保证数据的安全性,通过将数据写入到一个日志文件(HLog):

1  HBaseLSM-Tree架构

在当前时间段可能被写入用户数据的Region,称作“活跃Region”。

举例:

如果一个用户表的Region是按天划分的,那么,第一天的用户数据,只会被写入到第一天的Region中,则这些Region就是活跃Region。此时,对于其它天的Region,都处于一种“空闲”的状态。

 

集群中每一个物理节点的内存资源都是有限的,在前面部分也提到了每一个Region的数据都是暂时先保留在内存中然后再固化到HFile文件中的。因此,我们需要控制每一个时间段的活跃Region数目如果活跃Region过多的话,会导致内存资源紧张,每一个Region在内存中的数据可能还没有达到预先设置阈值的大小就被提前触发Flush操作,这会导致Flush频率升高,产生大量的小HFile文件(小文件过多会导致读取性能的直线下降,也会加大Compaction的频率和压力)。相反,如果活跃Region过少的话,也会导致并发度提升不上去,读写性能偏低。

      

如何设置最合理的活跃Region数目?需要根据MemStore Flush的阈值大小,以及RegionServer堆内存的大小、预留BlockCache空间的大小进行合理的计算。如下例子可说明这种计算的方法。

举例:

假设分配给RegionServer堆内存的大小为8GBlockCache所占空间比例为25%MemStore Flush的阈值大小为128M,则合理的活跃Region数目约为8*1024*1-0.25/128 = 48(/节点)

 

       以用户交易记录表为例。每一条用户交易记录关联一个USER_ID,也关联一个确切的交易时间点。

       如果我们在设计Key值的时候,采用“USER_ID + TIME”的格式,则划分Region的时候,一定是按照USER_ID的范围划分的。对于任意一天的交易记录,可能涉及到各个范围内的USER_ID,即可能涉及到所有的Region,因此所有的Region都可能是活跃的,就会导致前面提到的那种活跃Region过多的问题,而且这种问题会随着时间的持续而不断恶化下去

    图2  直接将USER_ID放在前面导致所有的Region都成为活跃的Region

       如果RowKey采用格式“DAY + USER_ID + TIME”的话,Region一定是按天划分的。那么,第N天的用户交易记录数据只会涉及到第N天的Region,也只有这一天的Region是活跃的,这样就有力的控制了活跃Region的数目:

    

   图3  通过设定分区控制活跃Region数目


【版权声明】本文为华为云社区用户转载文章,如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

举报
请填写举报理由
0/200