HBase优化相关

1.HBase预分区

HBase在创建表时,默认会自动创建一个Region分区。在导入数据时,所有客户端都向这个Region写数据,直到这个Region足够大才进行切分。这样在大量数据并行写入时,容易引起单点负载过高,从而影响入库性能。一个好的方法是在建立HBase表时预先分配数个Region,这样写入数据时,会按照Region分区情况,在集群内做数据的负载均衡。常用命令:

--自定义预分区的RowKey
hbase> create 't1', 'f1', SPLITS => ['10', '20', '30']
--使用文件内容预分区
hbase> create 't1', 'f1', SPLITS_FILE => 'splits.txt', OWNER => 'johndoe'
--使用内置的分区算法HexStringSplit
hbase> create 't1', 'f1', {NUMREGIONS => 3, SPLITALGO => 'HexStringSplit'}
--指定列族'info'使用'GZ'压缩
hbase> create 'pre', { NAME => 'info', COMPRESSION => 'GZ'},  {NUMREGIONS =>3, SPLITS => ['10', '20']}

使用最后一个创建'pre'表,然后通过Web页面 http://ncst:60010/table.jsp?name=pre 或者通过HBase shell命令scan 'hbase:meta' 查看hbase命名空间下所有标的元数据信息。 

 pre,,1442404691018.d514 column=info:regioninfo, timestamp=1442404691255, value={ENCODED => d
 e0dcd3d83aa48704d7f9a64 514e0dcd3d83aa48704d7f9a64db575, NAME => 'pre,,1442404691018.d514e0d
 db575.                  cd3d83aa48704d7f9a64db575.', STARTKEY => '', ENDKEY => '10'}        
 pre,10,1442404691018.50 column=info:regioninfo, timestamp=1442404691255, value={ENCODED => 5
 42efafeac5c9b6adce9868a 042efafeac5c9b6adce9868a9d0f72e, NAME => 'pre,10,1442404691018.5042e
 9d0f72e.                fafeac5c9b6adce9868a9d0f72e.', STARTKEY => '10', ENDKEY => '20'}    
 pre,20,1442404691018.81 column=info:regioninfo, timestamp=1442404691255, value={ENCODED => 8
 77de50218057a033be26c93 177de50218057a033be26c937c07be5, NAME => 'pre,20,1442404691018.8177d
 7c07be5.                e50218057a033be26c937c07be5.', STARTKEY => '20', ENDKEY => ''}      

可以看到第一个Region的 STARTKEY => '', ENDKEY => '10',第二个Region的 STARTKEY => '10', ENDKEY => '20',第三个Region的 STARTKEY => '20', ENDKEY => ''

需要注意的是: 

hbase> create 'pre', { NAME => 'info', COMPRESSION => 'GZ'},  {NUMREGIONS =>3, SPLITS => ['10', '20']}
--上述命令不等同于下面这条命令,并且下面这条命令还是错误的.
--这是因为【预分区】是针对整个Table,而不是某个Column Family
hbase> create 'pre', { NAME => 'info', COMPRESSION => 'GZ', NUMREGIONS =>3, SPLITS => ['10', '20']} 

2.hbase merge regions

对一个表进行预分区后,导入数据发现很多预分的region都没有数据,预分的规则不太好,然后把那些没有数据的region合并,使用hbase 有个merge工具。
用法hbase org.apache.hadoop.hbase.util.Merge <table_name> <region1> <region2>
具体写法

//注意:执行该命令前需要停止hbase集群
hbase org.apache.hadoop.hbase.util.Merge pre pre,10,1442404691018.5042efafeac5c9b6adce9868a9d0f72e. pre,20,1442404691018.8177de50218057a033be26c937c07be5.

执行完后重新启动集群,master:60010查看一下该表的regions,可以看到已经合并了。 

3.HBase的Bloom Filter

最根本的解释:判断一个元素是否属于这个集合。Bloom Filter是一个很长的二进制向量和一系列随机映射函数

如果这个集合中的元素足够多,那么通过传统遍历的方法进行判断耗时会很多。Bloom Filter就是一种利用很少的空间换取时间的实用方法。但是要说明的是:Bloom Filter的这种高效是有一定代价的,在判断一个元素是否属于某个集合时,有可能会把不属于这个集合的元素误认为属于这个集合(误判存在 false positive)。因此,Bloom Filter不适合那些“零错误”的应用场合。而在能容忍低错误率的应用场合下,Bloom Filter通过极少的错误换取了存储空间的极大节省。

1.Bloom Filter的原理?

Bloom Filter是m位的数组,且这个数组的每一位都是零。

Step 1 映射:假如我们有A={x1,x2,x3….xn} n个元素,那么我们需要k个相互独立的哈希Hash函数,将其中每个元素进行k次哈希,他们分别将这个元素映射到m位的数组中,而其映射的位置就置为1,如果有重复的元素映射到这个数组的同一个元素,那么这个元素只会记录一次1,后续的映射将不会改变的这个元素的值。如图:

Step 2 判断:在判断B={y1,y2} 这两个元素是否属于A集合时,我们就将这两个元素分别进行上步映射中的k个哈希函数的哈希,如果结果全为1,那么就判断属于A集合,否则判断其不属于A集合。如下图 y2属于,y1则不属于。

2.Bloom filter在HBase中的作用?
HBase利用Bloom filter来提高随机读(Get&Scan)的性能

3.Bloom filter在HBase中的开销?
Bloom filter是一个列族(cf)级别的配置属性,如果你在表中设置了Bloom filter,那么HBase会在生成StoreFile时包含一份bloomfilter结构的数据,称其为MetaBlock;MetaBlock与DataBlock(真实的KeyValue数据)一起由LRUBlockCache维护。所以,开启bloomfilter会有一定的存储及内存cache开销。

4.Bloom filter如何提高随机读的性能?
对于某个region的随机读,HBase会按照一定的顺序遍历每个memstore及storefile,将结果合并返回给客户端。如果你设置了bloomfilter,那么在遍历读storefile时,就可以利用bloomfilter,忽略某些storefile。

5.HBase中的Bloom filter的类型及使用?
a). ROW行级过滤器, 根据KeyValue中的row来过滤storefile
  举例:假设有2个storefile文件sf1和sf2,
  sf1包含kv1(r1 cf:q1 v)、kv2(r2 cf:q1 v)
  sf2包含kv3(r3 cf:q1 v)、kv4(r4 cf:q1 v)
  如果设置了CF属性中的bloom filter为ROW,那么get(r1)时就会过滤sf1,get(r3)就会过滤sf2

b). ROWCOL行加列级过滤器,根据KeyValue中的row+qualifier来过滤storefile
  举例:假设有2个storefile文件sf1和sf2,
  sf1包含kv1(r1 cf:q1 v)、kv2(r2 cf:q1 v)
  sf2包含kv3(r1 cf:q2 v)、kv4(r2 cf:q2 v)
  如果设置了CF属性中的bloom filter为ROW,无论get(r1,q1)还是get(r1,q2),都会读取sf1+sf2;而如果设置了CF属性中的bloom filter为ROWCOL,那么get(r1,q1)就会过滤sf2,get(r1,q2)就会过滤sf1

6.ROWCOL一定比ROW效果好么?不一定
a). ROWCOL只对指定列(Qualifier)的随机读(Get)有效,如果应用中的随机读get,只含row,而没有指定读哪个qualifier,那么设置ROWCOL是没有效果的,这种场景就应该使用ROW
b). 如果随机读中指定的列(Qualifier)的数目大于等于2,在0.90版本中ROWCOL是无效的,而在0.92版本以后,HBASE-2794对这一情景作了优化,是有效的(通过KeyValueScanner#seekExactly)
c). 如果同一row多个列的数据在应用上是同一时间put的,那么ROW与ROWCOL的效果近似相同,而ROWCOL只对指定了列的随机读才会有效,所以设置为ROW更佳

7.ROWCOL与ROW只在名称上有联系,ROWCOL并不是ROW的扩展,不能取代ROW

8.region下的storefile数目越多,bloom filter的效果越好

9.region下的storefile数目越少,HBase读性能越好 

4.hbaseadmin.balancer()
用hbaseadmin.split()手动对region进行拆分,拆分完之后,每个子region并没有均衡分布到3个regionserver上去。于是手工执行了一下hbaseadmin.balancer(),还是没效果。
查看源码发现原因:banancer()是针对整个集群的region分布,而不是针对某个表的region分布。它只保证每个regionserver上分布的regions在平均regions的0.8到1.2倍之间。

avg = 整个集群的总region数/regionserver个数
min = floor(avg*(1-0.2))
max=ceiling(avg*(1+0.2))

即所有regionserver上的regions个数都在min和max之间的话,就不会执行balancer。

补充说明:默认情况下是针对整个集群的region分布来均衡的,也可以针对表的region来均衡,需要配置:

<property>
<name>hbase.master.loadbalance.bytable</name>
<value>true</value>
</property>

然后重启集群。再执行hbaseadmin.balancer()。可以发现分布在一个regionserver上的一个表的regions被均匀的分布在所有的regionserver上了。

5.hbase宕机处理 

HBase的RegionServer宕机超过一定时间后,HMaster会将其所管理的region重新分布到其他活动的RegionServer上,由于数据Store日志HLog都持久在HDFS中,该操作不会导致数据丢失。所以数据的一致性和安全性是有保障的。
但是重新分配的region需要根据日志HLog恢复原RegionServer中的内存MemoryStore表,这会导致宕机的region在这段时间内无法对外提供服务。
而一旦重分布,宕机的节点重新启动后就相当于一个新的RegionServer加入集群,为了平衡,需要再次将某些Region分布到该server。  

posted @ 2015-09-16 20:07  skyl夜  阅读(2697)  评论(0编辑  收藏  举报