HBase流量限制和表负载均衡剖析

本文涉及的产品
应用型负载均衡 ALB,每月750个小时 15LCU
网络型负载均衡 NLB,每月750个小时 15LCU
简介:

1.概述

  在HBase-1.1.0之前,HBase集群中资源都是全量的。用户、表这些都是没有限制的,看似完美实则隐患较大。今天,笔者就给大家剖析一下HBase的流量限制和表的负载均衡。

2.内容

  也许有同学有疑问,为啥要做流量限制,无限制全量跑不是更好吗?举个例子,比如今天的双十一日,数据流量是非常大的。如果不限制用户和表的流量,某些重要的核心业务,需要在资源有限的情况下优先保证正常运行。如果非核心业务在此期间其QPS一直降不下来,严重消耗系统资源,影响核心业务的正常运作。

  针对上述问题,可以采取以下方案来解决:

  • 资源限制:针对用户、命名空间及表的请求大小和QPS进行限制。
  • 资源隔离:将不同表中的数据通过物理隔离,均衡到不同的RegionServer上。

3.资源限制

  开启HBase资源限制是有条件,其中包含以下两个条件:

  • 版本必须在1.1.0以上,或者在低版本中打上了HBase对应的Patch(HBASE-11598
  • HBase的资源限制开关默认是关闭的,需要在HBase的配置文件中进行开启。添加内容如下所示:
复制代码
# 编辑HBase配置文件
vi $HBASE_HONE/conf/hbase-site.xml

# 添加如下内容
 <property>
   <name>hbase.quota.enabled</name>
   <value>true</value>
 </property>

# 退出编辑并保存
复制代码

  如果不是在首次启动时配置的,需要额外重启HMaster服务进程才能使之生效。

3.1 Quota语句

  HBase中限流是通过Quota语句来操作的,限流的方式有两种,一种是针对用户进行限流;另一种是针对表来进行限流。操作命令如下所示:

复制代码
# 限制用户u1每秒请求10次
hbase> set_quota TYPE => THROTTLE, USER => 'u1', LIMIT => '10req/sec'

# 限制用户u1每秒的读请求为10次
hbase> set_quota TYPE => THROTTLE, THROTTLE_TYPE => READ, USER => 'u1', LIMIT => '10req/sec'

# 限制用户u1每天的请求量为10M
hbase> set_quota TYPE => THROTTLE, USER => 'u1', LIMIT => '10M/day'

# 限制用户u1的写请求量每秒为10M
hbase> set_quota TYPE => THROTTLE, THROTTLE_TYPE => WRITE, USER => 'u1', LIMIT => '10M/sec'

# 限制用户u1在操作表t2时,每分钟的请求量为5K
hbase> set_quota TYPE => THROTTLE, USER => 'u1', TABLE => 't2', LIMIT => '5K/min'

# 限制用户u1在操作表t2时,每秒的读请求为10次
hbase> set_quota TYPE => THROTTLE, THROTTLE_TYPE => READ, USER => 'u1', TABLE => 't2', LIMIT => '10req/sec'

# 删除用户u1在命令空间ns2的请求限制
hbase> set_quota TYPE => THROTTLE, USER => 'u1', NAMESPACE => 'ns2', LIMIT => NONE

# 限制在命名空间ns1中每小时的请求为10次
hbase> set_quota TYPE => THROTTLE, NAMESPACE => 'ns1', LIMIT => '10req/hour'

# 限制表t1每小时的请求为10T
hbase> set_quota TYPE => THROTTLE, TABLE => 't1', LIMIT => '10T/hour'

# 删除用户u1的所有请求限制
hbase> set_quota TYPE => THROTTLE, USER => 'u1', LIMIT => NONE

# 显示用户u1在命名空间ns2中的所有限制详情
hbase> list_quotas USER => 'u1, NAMESPACE => 'ns2'

# 显示命令空间ns2的所有限制详情
hbase> list_quotas NAMESPACE => 'ns2'

# 显示表t1的所有限制详情
hbase> list_quotas TABLE => 't1'

# 显示所有限制详情
hbase> list_quotas
复制代码

  从操作的命令中可以看出,HBase限制流量支持表和用户。可以通过THROTTLE_TYPE来控制READ(读)、WRITE(写)操作,这类操作在HBase中是随机进行限制的。而LIMIT关键字,可以从两个维度进行资源限制,分别是req/time和size/time。

  • req/time:这种表示限制单位时间内的请求次数,time可以是秒、分、时、天,req表示次数。
  • size/time:这种表示单位时间内请求数据的量,time可以是秒、分、时、天,size可以时B (bytes), K (kilobytes), M (megabytes), G (gigabytes), T (terabytes), P (petabytes)。

  LIMIT限制默认大小是:10req/day 或 100P/hour。对于命令set_quota来说,执行这条命令仅仅是限制单个RegionServer上的流量,并不是整个集群的限制总量(集群限制总量=每个RegionServer的限制量*RegionNum)。另外,执行set_quota命令后,默认是需要等待300000秒(5分钟)才会生效。如果觉得时间太长,可以将生效时间缩短,通过hbase-site.xml文件中的参数hbase.quota.refresh.period来设置时间,比如:

# 一分钟后生效
hbase.quota.refresh.period=60000

3.2 限制命名空间中的表个数

  在创建命名空间中的表个数,可以在创建命名空间时指定,也可以在创建之后在此修改表个数,同样也可以删除表限制。通过设置hbase.namespace.quota.maxtables属性值来改变。操作内容如下所示:

复制代码
# 创建一个命令空间最大包含5个表
hbase> create_namespace 'ns1', {'hbase.namespace.quota.maxtables'=>'5'}

# 修改一个已存在的命令空间所允许的表数量大小为8个
hbase> alter_namespace 'ns2', {METHOD => 'set', 'hbase.namespace.quota.maxtables'=>'8'}

# 显示命令空间下的所有详情
hbase> describe_namespace 'ns2'

# 删除命令空间中表个数的限制
hbase> alter_namespace 'ns2', {METHOD => 'unset', NAME=>'hbase.namespace.quota.maxtables'}
复制代码

3.3 限制命名空间的Region

  在创建命名空间时 ,可以限制Region的个数。在创建之后也可以通过命令来修改个数的上限值。具体操作如下所示:

复制代码
# 创建一个命名空间最大包含10个Region
hbase> create_namespace 'ns1', {'hbase.namespace.quota.maxregions'=>'10'

# 显示命令空间中详情
hbase> describe_namespace 'ns1'

# 修改命名空间中最大Region个数为20个
hbase> alter_namespace 'ns2', {METHOD => 'set', 'hbase.namespace.quota.maxregions'=>'20'}

# 删除命名空间中Region个数的限制
hbase> alter_namespace 'ns2', {METHOD => 'unset', NAME=> 'hbase.namespace.quota.maxregions'}
复制代码

  这里也许有些同学在操作的过程当中遇到过,在请求操作限制阀值时,日志没有打印出错误信息,这是由于默认日志输出时INFO级别,不会打印这类异常,如果要查看,可以通过修改log4j的日志级别为DEBUG,这样就可以查看到对应的异常信息了。

 4.资源隔离

  在HBase中可以通过资源隔离的方式来间接的限流。将请求均衡到多个RegionServer中去。通过balance_switch命令来实现自动均衡操作。命令如下:

复制代码
# 查看自动均衡状态
balance_switch status

# 停止自动均衡
balance_switch stop

# 开启自动均衡
balance_switch start
复制代码

  在实际业务中,如果HBase某个表的RegionServer全部集中在一个上,这时候可以考虑使用move命令手动均衡操作,具体操作语法如下:

# move手动操作语法
move [region id] [ServerName]

  如下图所示:

  从图中一个Table Region来说,”t2,,1510401809742.bd015fc10e75b70a52adc0c32a2321c2.“其中region id为”bd015fc10e75b70a52adc0c32a2321c2“。我们可以在HBase集群客户端执行以下命令来手动指定region。命令如下所示:

# 将该Region(dn3)移动到Region(dn1)
echo "move 'bd015fc10e75b70a52adc0c32a2321c2','dn1,16020,1510401268652'"|hbase shell

  在往HBase表中写数据的时候,默认是往一个Region中写数据,当数据量很大时,才会自动拆分成多个Region,拆分的规则和RowKey设计有关。为了防止出现这种情况,我们可以在创建表的时候进行预分区操作。命令如下所示:

# 创建表的预分区(6个Region),RegionTotals = SPLITS.length + 1
create 't2', 'cf', SPLITS => ['0001','0002','0003','0004','0005']

  这样我们可以拆分成6个Region,这里也许有同学要问,为什么是6个Region。其实,从上图中就可以看出,表分区中第一个Region是没有StartKey,最后一个Region是没有EndKey的。为什么会出现这种情况,下面就给大家来剖析这个原因。如下图所示:

  从图中可知,在第一个Region中只有EndKey,没有StartKey。第一个Region中的EndKey(0001),就是第二个Region的StartKey,以此类推,到最后一个Region就只有StartKey(0005)了。这就是为什么第一个Region没有StartKey,最后一个Region没有EndKey的原因。

  其实,我们在使用HBase的Java API获取Region的StartKey和EndKey的时候,有时会出现Null,也就是这个原因。

5.总结

  在使用Quota命令进行限流时,需要确保hbase-site.xml文件中的限流属性开启。另外,在对表做手动均衡操作时,使用move命令即可。HBase是有自动均衡的策略的,均衡的Region取决于设计分割的Key,Key的产生又和HBase中中Rowkey的设计息息相关。所以,HBase中表的RowKey设计的是否优秀,决定了Region均衡时,分割Key的选取。

6.结束语

  这篇博客就和大家分享到这里,如果大家在研究学习的过程当中有什么问题,可以加群进行讨论或发送邮件给我,我会尽我所能为您解答,与君共勉。

联系方式: 
邮箱:smartloli.org@gmail.com 
Twitter: https://twitter.com/smartloli 
QQ群(Hadoop - 交流社区1): 424769183 
温馨提示:请大家加群的时候写上加群理由(姓名+公司/学校),方便管理员审核,谢谢! 

热爱生活,享受编程,与君共勉!



本文转自哥不是小萝莉博客园博客,原文链接:http://www.cnblogs.com/smartloli/,如需转载请自行联系原作者

相关实践学习
lindorm多模间数据无缝流转
展现了Lindorm多模融合能力——用kafka API写入,无缝流转在各引擎内进行数据存储和计算的实验。
云数据库HBase版使用教程
&nbsp; 相关的阿里云产品:云数据库 HBase 版 面向大数据领域的一站式NoSQL服务,100%兼容开源HBase并深度扩展,支持海量数据下的实时存储、高并发吞吐、轻SQL分析、全文检索、时序时空查询等能力,是风控、推荐、广告、物联网、车联网、Feeds流、数据大屏等场景首选数据库,是为淘宝、支付宝、菜鸟等众多阿里核心业务提供关键支撑的数据库。 了解产品详情:&nbsp;https://cn.aliyun.com/product/hbase &nbsp; ------------------------------------------------------------------------- 阿里云数据库体验:数据库上云实战 开发者云会免费提供一台带自建MySQL的源数据库&nbsp;ECS 实例和一台目标数据库&nbsp;RDS实例。跟着指引,您可以一步步实现将ECS自建数据库迁移到目标数据库RDS。 点击下方链接,领取免费ECS&amp;RDS资源,30分钟完成数据库上云实战!https://developer.aliyun.com/adc/scenario/51eefbd1894e42f6bb9acacadd3f9121?spm=a2c6h.13788135.J_3257954370.9.4ba85f24utseFl
相关文章
|
19天前
|
弹性计算 负载均衡 网络安全
slb使用中流量转发不均
【10月更文挑战第23天】
35 8
|
6月前
|
Kubernetes 负载均衡 应用服务中间件
深入理解 Kubernetes Ingress:路由流量、负载均衡和安全性配置
深入理解 Kubernetes Ingress:路由流量、负载均衡和安全性配置
1136 1
|
2月前
|
弹性计算 负载均衡 监控
slb分发流量到ecs一般是如何判断?
【9月更文挑战第1天】
60 1
|
3月前
|
负载均衡 监控 算法
揭秘负载均衡的五大算法秘籍:让你的服务器轻松应对亿万流量,不再崩溃!
【8月更文挑战第31天】在互联网快速发展的今天,高可用性和可扩展性成为企业关注的重点。负载均衡作为关键技术,通过高效分配网络流量提升系统处理能力。本文介绍了轮询、加权轮询、最少连接及IP哈希等常见负载均衡算法及其应用场景,并提供Nginx配置示例。此外,还探讨了如何根据业务需求选择合适算法、配置服务器权重、实现高可用方案、监控性能及定期维护等最佳实践,助力系统优化与用户体验提升。
74 2
|
3月前
|
域名解析 负载均衡 网络协议
双重神器合璧,流量洪流中的稳如磐石:揭秘Bind+Nginx负载均衡的超级力量!
【8月更文挑战第9天】在现代网站架构中,负载均衡至关重要,它通过分散客户端请求至多台服务器,确保了系统的高可用性和稳定性。本文介绍如何结合Bind与Nginx实现高效负载均衡。Bind作为DNS服务器,可为单一域名解析出多个IP地址;Nginx作为高性能HTTP服务器,则在这些IP对应的服务器间智能分配流量。通过配置Bind的A记录与Nginx的`upstream`和`proxy_pass`指令,我们能够构建一个既稳定又易扩展的负载均衡系统,显著提升用户体验与系统可靠性。
71 11
|
5月前
|
负载均衡 算法 应用服务中间件
解密Nginx负载均衡:实现流量分发与故障转移
解密Nginx负载均衡:实现流量分发与故障转移
172 0
|
6月前
|
负载均衡 算法 应用服务中间件
解密Nginx负载均衡:实现流量分发与故障转移
解密Nginx负载均衡:实现流量分发与故障转移
289 1
|
6月前
|
负载均衡 监控 应用服务中间件
Nginx负载均衡:你的网站流量翻倍利器
Nginx负载均衡:你的网站流量翻倍利器
100 0
|
6月前
|
域名解析 弹性计算 负载均衡
阿里云——超大流量网站的负载均衡
阿里云——超大流量网站的负载均衡
189 0
|
域名解析 弹性计算 负载均衡
下一篇
无影云桌面