python写入Hbase超时问题分析

Hbase是一个高可靠、高性能、面向列、可伸缩的分布式数据库。其底层的LSM数据结构和RowKey有序排列等架构上的独特设计,使得hbase具有非常高的写入性能。但是在实际使用中,由于对hbase的写入方面的机制没有深入的了解,无法有效发挥出hbase的写入性能。本文主要记录了在刚开始使用hbase时,对hbase没有太多的了解的基础上,在写入方面遇到的一个问题和解决方法。

Hbase原生支持java写入,但由于实际业务的需要和迁移的成本,要使用python来写入hbase。hbase中集成了thrift框架,支持使用python对hbase进行操作。happybase是 FaceBook 员工开发的操作HBase的 Python库,其基于 Thrift,封装了大多数hbase的操作方法,使得通过python也能对hbase进行操作。

问题描述

在初步安装好6个RS的Hbase集群上,新建一张测试表,使用200G的数据,进行写入性能的测试。
采用happybase写入hbase,下面是一段简化的代码:

1
2
3
4
5
6
7
(con, table) = get_hbase_con(table_name=table_name)
with table.batch(batch_size=200) as batch:
with open(filepath) as fp:
for line in fp:
records = line.strip().split(',')
cf={"cf:data":records}
batch.put(row=rowkey, data=cf)

Happybase的put方法原本就是采用batch批量提交数据,在代码中使用table.batch可以自己控制batch_size的大小。采用batch提交,减少rpc请求次数,提高写入的性能。

运行程序时,程序通过socket与hbase的thriftsever连接,将请求发给thriftsever,由thriftsever调用hbase的client端进行写入。使用单线程进行数据的写入一段时间之后,总会出现socket.timeout的问题。一旦出现该问题后,程序终止运行,如下图所示:

出现此问题时,写入的每秒请求数才5200多,并且是持续的向一个region中写入。

问题分析和解决

为了解决这个问题,我安装了ganglia监控工具。在写入的时候,查看集群上的指标,发现写入的节点上负载过重,cpu利用率飙升,其它节点基本处于休眠状态。由此现象可以初步断定是hbase写入的热点问题造成了timeout。解决hbase的热点问题,关键在于rowkey的设计和预分区上。

Hbase的RowKey是按字点排序由低到高进行存储的,在设计时需要遵循散列性,唯一性,同时也要兼顾实际业查询的需求,这样在写入的过程中不至于造成一台集群负载过重的情况。

现有的RowKey的设计规则如下:

很明显其是按时间有序排列的,不符合rowkey的散列性,原始数据是按时间顺序排列的,在插入时,就会一直向同一个region中插入,因此造成热点问题。通过改进,将后面的标示位放置rowkey的前缀,由于标示位是散列的,没有规律,RowKey的设计变成了:
RowKey = 标示位+预留10位+时间戳
清空测试表后,重新插入数据测试,发现插入时仍然会出现热点问题。继续进行分析,查到一段话:

默认情况下,当我们通过hbaseAdmin指定TableDescriptor来创建一张表时,只有一个region正处于混沌时期,start-end key无边界,可谓海纳百川。所有的rowkey都写入到这个region里,然后数据越来越多,region的size越来越大时,大到一定的阀值,hbase就会将region一分为二,成为2个region,这个过程称为分裂(region-split)。
如果我们就这样默认建表,表里不断的put数据,更严重的是我们的rowkey还是顺序增大的,是比较可怕的。存在的缺点比较明显:首先是热点写,我们总是向最大的start key所在的region写数据,因为我们的rowkey总是会比之前的大,并且hbase的是按升序方式排序的。所以写操作总是被定位到无上界的那个region中;其次,由于热点,我们总是往最大的start key的region写记录,之前分裂出来的region不会被写数据,有点打入冷宫的感觉,他们都处于半满状态,这样的分布也是不利的。
hbase热点问题(数据倾斜)解决方案—rowkey散列和预分区设计 - - ITeye技术网站

按照这个解释,即使对rowkey进行散列化设计,仍然不能解决热点问题,初始建表没有进行预分区时,只有一个region,其并没有一个上界,导致在插入时还是不断的向一个region中插入。因此接下的操作是进行表进行预分区。
由于RowKey的设计已经变成了散列性,导致预分区不好确定每个region的RowKey范围。针对此问题,在有限的数据中,采取了将所有的rowkey提取出来排序后,分段抽取的方式,确定了每个region的范围。

通过rowkey的散列化和预分区,每个节点上都启动ThrfftServer服务,将200G的大文件拆成了多个小文件,然后采用python的多进程再次进行测试。此时出现了可喜的结果,

从图可以看到,写入的请求分布的比较均匀,不再集中到一个region 上。从ganglia上的监控上看,单个节点的负载比之前有很大的下降。到此,hbase的写入热点问题基本上解决。

但是timeout的情况依然出现,出现时间较之前有延后,可见问题并没有彻底的解决。timeout出现时间延后,说明解决hbase写入的热点问题对timeout问题是有帮助的。

因此我对hbase的写入过程中进行了更加深入的分析,看看数据在写入的过程中究竟发生了什么。
Hbase写入过程包括了客户端和服务端,采用客户端批量写入数据,数据会现在本地的buffer中缓存,到达阈值后,客户端就会将数据推送到服务端,服务端收到数据后先写日志,然后在写入memstore中,memstore满后就会flush到storefiles,当storefiles 的数量增长到一定阈值后,就会进行compact成更大的storefile,当storefile达到阈值后就会split成两个region,被hmaster分配到其它的regionserver中。

由于写入过快,服务器端需要大量compact,split操作时,很容易阻塞数据的写入,会出现has too many store files; delaying flush up to 90000ms等问题。一旦出现服务端阻塞写入的问题,client端就会延迟收到响应结果。如果在规定的时间内,客户端仍未接收到服务器端的响应,socket就会出现timeout的情况,然后客户端和服务器端的连接就会断掉,写入过程终止。通过对日志的分析,也说明了出现timeout的问题时,hbase正在进行compact或split操作。

从上述的分析中,明确了解决timeout问题的下一步目标是优化hbase的写入性能。通过对hbase的region size、rpc超时时间、scanner超时时间、memstore fluse size、blockingStoreFiles等参数优化,降低compact和split的频率,延迟超时出现的时间,也降低了超时的频率。

除非全部手动进行,hbase进行compact和split是不可避免的,因此写入超时也是不可避免的。从happybase的githup上找到了解决timeout一劳永逸的方法,将客户端的timeout置为不限。thriftpy0.3.3设置了默认的超时时间为3s,要想永不超时,将timeout设置为None即可。

Since thriftpy 0.3.3, there has been a socket_timeout option to TSocket. The default is 3000 ms. Setting it to None means “never timeout”. Remove the if self.timeout is not None conditional so a value of None can also be set explicitly from happybase.
Set socket timeout unconditionally on TSocket by ecederstrand · Pull Request #146 · wbolster/happybase · GitHub

1
2
# timeout = None
con = happybase.Connection(host=host, autoconnect=False, timeout=None, transport='buffered')

网上有建议将timeout设置更长一点,但是由于网络以及服务端的问题不确定性,超时的风险很大。直接设置成None,客户端就会一直等待服务端的响应,再也不会出现超时的问题。

上述方法虽然一劳永逸,但是如果有潜在的风险就是一直阻塞。推荐采取手动的处理超时问题。在捕获到超时后,选择断开连接,暂停一小段时间写入,重新连接然后进行写入。

总结

初入Hbase,作为一个小白,耗费了较长的时间才解决写入超时的问题。一个问题牵涉了Hbase的方方面面,使我收获满满:
1、更了解hbase的特点,RowKey的设计,表的预分区。
2、从源码上了解Hbase的写入过程
4、如何优化hbase性能
5、分析和解决问题的思路

参考内容

hbase热点问题(数据倾斜)解决方案—rowkey散列和预分区设计 - - ITeye技术网站
《Hbase企业应用实际开发》马延辉