HBase常见问题答疑解惑【持续更新中】

本文对HBase开发及使用过程中遇到过的常见问题进行梳理总结,希望能解答新加入的HBaser们的一些疑惑。

1. HTable线程安全吗?

HTable不是线程安全的,使用过程中建议一个线程中使用一个HTable对象,不同线程间不要共享HTable对象。

同时,为了提高客户端的效率,不同的HTable对象公用同一个Configuration对象,共享HBase服务端的元数据信息,详见HBase权威指南中有关HTable部分的介绍。

2. HTablePool该如何使用?

HBase 0.90 版本以前,使用HTablePool时通过getTable方法获取HTable对象,使用完成后调用putTable方法将HTable对象放回到池中。

而HBase 0.90 以后的新版本中,使用完成后不再调用putTable方法,而是调用HTable的close方法将HTable对象放回到池中。

3. Scanner的Caching与Batch有什么区别?

caching是一次从服务端取到客户端的记录条数;而batch则是一次返回给客户端(一个Result对象中)的KeyValue的个数。

举个例子:如果每行记录有5个KeyValue,而仅仅设置caching=10,假设scan表过程中表中匹配到的记录数大于10条,那么一次next()操作从服务端返回的是10个Result,每个Result含有5个KeyValue:

* * * * *

* * * * *

* * * * *

* * * * *

* * * * *

* * * * *

* * * * *

* * * * *

* * * * *

* * * * *

而如果同时设置batch=2,那么一次next()操作将返回17个KeyValue:

* *

* *

*

* *

* *

*

* *

* *

*

* *

4. Put(List<Put> puts)效率一定更高吗?

put(list)是用于提高吞吐量的。首先在不同region server之间是并行的;在同一个region server上的同一个region上也是并行的,而在不同region上则是串行的。

因为在同一个region server上,如果put(list)在一个region上执行,那么它是打包写一条日志的,相当于并行写入;而在不同region上执行话,它是一个for循环,而不是走线程池,所以是串行的。

5. Increment的正确性和性能靠谱吗?

目前Increment还无法做到完全的正确性,在网络出现timeout和region server发生failover的时候可能不正确,使用时需要根据应用场景慎重选择。

至于Increment的性能,性能还不错,尤其是在HBase 0.94和普通的Put写操作差别不大,能达到每台region server 7000+。

6. Region个数越多越好吗?

Region过多则影响flush效率和region server failover效率,还有就是对HDFS的压力比较大;Region过少则对读有影响,因为StoreFile数量比较多了,如果每个Region的StoreFile数量很少(线上集群一般维持在1.x~2.x个StoreFile),那么对读操作无明显影响。

写入的话,Region多少影响不大,除非Region特别少并且写压力特别大,比如一个region server只有一个Region的特殊情况。

现在HBase 0.90版本每个region server建议3000个以内Region;而HBase 0.94版本则建议在1000个以内,几百个就算很多了。

7. WAL操作日志的开销有多大?

一般情况下,向region server服务端put数据时,如果开启写WAL日志的话,服务端大概会需要1ms~2ms的开销。而如果不开启WAL日志的话,服务端只有大概0.xms的开销,基本上都是MemStore的内存操作。

另外,不管哪种情况下,对于一次put操作,都还需要加上网络传输延迟RTT开销(一般在0.5ms~1ms以内)。

8. 单表单Region的写入性能有多高?

不考虑任何优化的前提下,Java API在WAL开启的情况下每秒能达到800左右 tps,关闭WAL则能达到1000+ tps,基本上就是网络速度的上限;而Thrift接口大概有10~20%的性能损失,实际测试显示在网络RTT=0.7ms的环境下,能达到每秒550左右tps;在网络RTT=2.0ms的情况下,则只能达到350左右tps。

以上的写入性能数据,与HBase的实际写入性能相差甚远,因为没有考虑进行优化,实际应用中可以从预分region、多客户端、多线程、批量写入等方式使每个region server达到性能极限。

注意:单表单region的情况下,短时间内如果低并发写入没有问题,而如果高并发写入,则写一会之后可能会由于发生region split而导致请求被block住。

9. 单Region Server的写入性能有多高?

如果要压测单个region server的写入能力,那么可以新建一张测试表,同时预先创建多个region(例如:10~50个),然后随机生成rowkey和value写入到HBase集群进行压力测试,最终测试结果除以HBase集群内region server的个数,就可以大概得到单个region server的写入性能值了。

从HBase集群测试团队得到的结果,对于16核CPU,24GB内存的region server机器(DataNode进程分配1GB内存,HBase RegionServer进程分配16GB内存),不开WAL的话,单region server可以达到3w以上tps;开启WAL的话,一般单region server能达到9k~2w tps。而HBase的Thrift接口,可以达到Native Java API 80%~90%左右的性能。

10. Rowkey中包含时间戳导致空Region有什么问题?

假设rowkey中包含时间戳,同时设置了TTL,自动删除过期数据,那么随着时间戳值的增长,会导致过期数据已经被删除,但是空的region还存在,过多的region会影响flush效率和region server failover效率,还有就是对HDFS的压力比较大;同时由于过多空region也会占用一些元数据信息。

解决这个问题,一般有两个方法:

1)按时间周期新建不同的表:例如按天建不同的表,跨天时切换表进行读写,该方法的缺点是每天都需要建表,由于DDL事务都是master做的,只要master出问题就容易影响事务,一般来说为了防止受master影响,需要提前几天把表建好。

2)将时间戳字段进行处理:rowkey中不直接存储当前的时间戳timestamp,而改为存储自当周周一凌晨00:00:00开始累计的时间戳值(秒或毫秒等均可),这样表中最多存储一周数据对应的region数,当下周开始后就开始复用之前的region,从而避免了region的膨胀。相应地,查询端也需要对时间戳timestamp进行响应的处理。考虑到扩展性,假设要保存的数据超过一周时间,那么该方法也可以从1周扩展到1个月进行适应。

 {{持续更新中}}

posted on 2012-09-08 11:51  大圆那些事  阅读(7737)  评论(3编辑  收藏

导航