hbase中删除表中的行键_Hbase运维实践分享

主要内容:

HBASE介绍

HBASE数据热点

HBASE常见故障处理

HBASE压缩

[ 1、HBASE介绍 ]

1.1关系型数据库和非关系型数据库

89daae5153b32fab26ba84d3db4ee06b.png

1.2关系型数据库和hbase的区别

1、数据类型:关系数据库采用关系模型,具有丰富的数据类型和存储方式,HBase则采用了更加简单的数据模型,它把数据存储为未经解释的字符串。

2、数据操作:关系数据库中包含了丰富的操作,其中会涉及复杂的多表连接。HBase操作则不存在复杂的表与表之间的关系,只有简单的插入、查询、删除、清空等,因为HBase在设计上就避免了复杂的表和表之间的关系。

3、存储模式:关系数据库是基于行模式存储的。HBase是基于列存储的。

4、数据索引:关系数据库通常可以针对不同列构建复杂的多个索引,以提高数据访问性能。HBase只有一个索引——Rowkey。

5、数据维护:在关系数据库中,更新操作会用最新的当前值去替换记录中原来的旧值,旧值被覆盖后就不会存在。而在HBase中执行更新操作时,并不会删除数据旧的版本,而是生成一个新的版本,旧有的版本仍然保留。

6、可伸缩性:关系数据库很难实现横向扩展,纵向扩展的空间也比较有限。相反,HBase和BigTable这些分布式数据库就是为了实现灵活的水平扩展而开发的,能够轻易地通过在集群中增加或者减少硬件数量来实现性能的伸缩

1.3 HABSE架构变化

d6386292adefea108ac6ea3e29b7e794.png

HBASE 1.0以前

06ea16a907ef420d6b6432838dba8fed.png

HBASE1.0以后

[ 2.HBASE数据热点 ]

2.1 HABSE Rowkey

HBase 表的数据是按照Rowkey来分散到不同Region,不合理的Rowkey设计会导致热点问题。热点问题是大量的Client直接访问集群的一个或极少数个节点,而集群中的其他节点却处于相对空闲状态。

Hbase是根据Rowkey来进行检索的,检索支持3种方式:

1、通过单Rowkey访问,即按照某个Rowkey键值进行get操作,获取唯一记录。

2、通过Rowkey的range进行scan,即通过是指startRowkey和endRowkey,在这个范围进行扫描。这样可以指定条件获取一批记录。

3、全表扫描,即直接扫描整张表中所有的记录。(该方法效率特别低)

2.2 Hbase如何避免数据热点

1、salting(加盐)

在Rowkey前面加入随机数,具体就是给Rowkey前面分配一个随机前缀,以使得它和之前的排序不同。但是会对写造成了一定的负面影响,会增加写时的吞吐量。

2、加入Hashing

Hashing的原理就是计算Rowkey的hash值,然后取hash的部分字符和原来的Rowkey进行拼接。这里的hash包含比如MD5这种类似的算法。

3、Reversing(反转)    

Reversing的原理是反转一段固定长度或者全部的键。

4、Rowkey的长度。

Rowkey可以是任意字符,越短越好,但是不要超过16个字节,存为byte[]字节数组,一般设计成定长。

[ 3.HBASE常见故障及处理 ]

3.1RegionServer异常下线

regionserver进程时常出现异常下线的情况

检查分析:

(1)检查日志

18af6583374705faf79e03eeb888164e.png

(2)该主机收到的告警短信

c625282dea470c3bb8351331ad85c188.png

该主机出现某个磁盘写数据繁忙的情况,出现这类情况就要从datanode入手(因为该磁盘sdg为datanode数据盘)。

(3)检查对比nmon日志

d37e7cc7f3564daac0714a64eb871b8c.png

7f2887a04b0140d76354a1bd318518b8.png

图一为问题主机DISKBUYS报表图,由图一wavg偏高,说明磁盘的繁忙程度相比于同一集群的其他主机更高。

(4)根据nmon图分析为主机磁盘问题

83c8b4bf0c0d6c35ddcd56f21019e59f.png

通知主机方检查主机,最终检查出其中一个hadoop数据盘有问题,更换完后问题解决,如上图可以看出之前坏的主机nmon的DISKBUYS无异常。

3.2 Hbase请求异常

1、查看Hbaseui

通过hbaseui界面查看hbase请求量大部分时间处于10000以下,甚至还在几百(此集群平时正常时候请求量大部分在7w-12w左右)

2、日志信息

Numberof regions in transition: 0...ERROR: RegionServer:xxx主机,2302,1546020590497Unable to fetch region information.org.apache.hadoop.net.ConnectTimeoutException: 20000 millis timeoutwhile waiting for channel to be ready for connect. ch :java.nio.channels.SocketChannel[connection-pendingremote=主机名/ip:2302]

(体现为regionserver无法提供handler为master提供信息。导致同步meta表出错。)

3、通过netstat-anp|grep 2302 命令查看链接状况出现SYN_RECV(半连接)

f4a05aa81ba177a1d2325b508ee40128.png

4、问题处理过程

登录堡垒机,执行 hbase hbck,查看有无 ConnectTimeoutException 报错,如发现相关报错,保留页面信息,访问问题主机ip:2301页面,右键另存为当前网页,点击界面Debugdump和MetricsDump链接分别保存信息,登录故障主机,保留信息,通过netstat-anp|grep2302查看连接状态,通过jps查看regionserver进程,jstack -l rsPID >/tmp/jstack.${time},如果发现报错,登录rstimeout主机通过hbase-daemon.shstopregionserver停止regionserver,观察请求量是否恢复,待集群恢复正常后,讨论是否重新拉起故障regionserver。

[ 4.Hbase压缩 ]

1、情景再现  

采用压缩优化解决方案,用最少的投资承载更多的数据存储,实现降本增效的目标,适用于类似此种一次写入、少量查询的温冷数据场景。入库时采用SNAPPY压缩,不影响数据入库效率,在业务闲时,修改数据压缩方式为GZ,降低存储资源消耗。

2、具体实现步骤

(1)disable'snappy_test'

(2)alter'snappy_test' ,NAME=>'cf',COMPRESSION => 'GZ'

(3)enable'snappy_test'

(4)major_compact'snappy_test'

3、测试结果

表名

压缩前大小(snappy)

压缩后大小(GZ)

压缩比

压缩时间

snappy_test

380.9G

207.5G

大约35%

大约1小时15分钟major完全执行完

b1d540256c575b579608eda60d9ee13d.png

a02fb7d6fd17812d049cbf781f1ad36c.png

2a87224e53c0d56ad7486d4374705090.png

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值