HBase相关概念

1.Row Key 

基本原则是:(1).由于读取数据只能依靠RowKey,所以应把经常使用到的字段作为行键{如手机号+时间戳拼接的字符串} (2).RowKey长度越短越好,最好不要超过16个字节
从表的形式看,主要有列少行多的高表和行多列少的宽表,一般情况高表更有优势,因为HBase只能按行拆分。
防止数据过热:当行健为时间戳时,写入数据集中在其中一个Region很容易产生单点过热。
解决办法:(1)添加hash前缀. (2)字段交换或提升权重:即在行键中添加另外一个字段或交换行建中多个字段的位置. (3)随机化,比如对整个行健取MD5,作为新的行健。
以上方法顺序度的性能由高到低,而写入的速度由低到高 

行健决定数据的读取维度或模式,数据行RowKey有序。但如果需要额外的读取顺序,则可以给表添加格外的列族,用于存储其他读取顺序的索引比如:对于收件箱应用,行健为userID,data列族存消息数据(列名为messageID,值为消息内容),而idx列族存索引(列为标示+消息主题,值为附加信息)。这样就可以在读取索引列族时,得到按主题有序的数据。

2.Column Family

在一张表里不要定义太多的column family。目前Hbase并不能很好的处理超过2~3个column family的表。因为某个column family在flush的时候,它邻近的column family也会因关联效应被触发flush,最终导致系统产生更多的I/O。

3.In Memory

创建表的时候,可以通过HColumnDescriptor.setInMemory(true)将表放到RegionServer的缓存中,保证在读取的时候被cache命中。

4.Max Version

创建表的时候,可以通过HColumnDescriptor.setMaxVersions(intmaxVersions)设置表中数据的最大版本,如果只需要保存最新版本的数据,那么可以设置setMaxVersions(1)

5.Time to Live(设置数据存储的生命周期)

创建表的时候,可以通过HColumnDescriptor.setTimeToLive(inttimeToLive)设置表中数据的存储生命期,过期数据将自动被删除,例如如果只需要存储最近两天的数据,那么可以设置setTimeToLive(2 * 24 * 60 * 60)

6.Compact & Split

HBase的Compact分为两类:一类叫Minor Compact(部分文件合并), 一类叫Major Compact(全部文件合并). 

两者区别在于Minor Compact是在Store内StoreFile数量达到阈值(hbase.hstore.blockingStoreFiles, 默认是7)时触发,将Store内的多个小StoreFile合并成一个大的StoreFile.

Major Compact除了将给定Region中一个列族的所有StoreFile合并成一个大的StoreFile外,还会将其中的Delete标记项进行删除。Major Compact是HBase清理被删除记录的唯一机会,因为我们不能保证被删除的记录和墓碑标记记录在同一个Store内。----一个Region只保存一个Table的数据,一张Table的所有数据分布在多个Region上。一个Region包含多个Store。一个Store只保存一个Column Family的数据,一个Column Family的所有数据分布在多个Store内。

由于Major Compact非常消耗资源,实际应用中,可以考虑必要时手动进行。当Region内StoreFile的大小达到一定阈值后,等分Split为两个StoreFile。

7.Pre-Creating Regions

默认情况下,在创建HBase表的时候会自动创建一个Region分区,当导入数据的时候,所有的HBase客户端都向这一个Region写数据,直到这个Region足够大了才进行切分。一种可以加快批量写入速度的方法是通过预先创建一些空的Regions,这样当数据写入HBase时,会按照Region分区情况,在集群内做数据的负载均衡。 具体详见HBase优化相关

 

8.HBase模式设计之ID顺序增长(rowkey顺序增长)
在设计RowKey的时候,常常有应用的RowKey必须包含ID部分,这样才可以支持查询访问。但ID自增长,会导致写入数据的时候压力集中在某一个或少数几个Region上,这是HBase设计的大忌。
经过多个应用的实践,使用ID的二进制反转的方式来避免。
简单说明: 比如ID是Byte型(一般为int或者long,此处为方便解释),RowKey=ID+timestamp,1,2,3,4……这样增长,对应二进制为0000 0001,0000 0010,0000 0011,0000 0100……,因为前面的bit是不会变化的,所以以ID为RowKey(或者ID打头)的数据写入的时候会集中在一个region上,然后又集中在下一个region上。为此将变化的部分放到RowKey的前面,来分散写入的压力。前面的增长在RowKey的ID上就变成1000 0000, 0100 0000, 1100 0000,0010 0000……我们预分区,假如需要16-1个分区,就可以分为[,0x01),[0x01,0x02),[0x02,0x03)……[0xFE,0xFF), [0xFF,),注意算一下,这样,1,2,3,4……就会写到不同的区间上,从而分散到不同的region了。(提醒:为什么只拿ID说事,不考虑timestamp呢,因为HBase的RowKey时字节码比较的,先从高位开始,高位分出胜负,后面就不care了~)

 

优点:转顺序为分散,均衡集群压力;可以做到预分区;不用hash,不用考虑ID的hash碰撞,从而节约存储空间;
限制:scan只能在同一ID打头的rowkey内进行,连续ID的scan不能直接支持,需要程序逻辑处理。

 

posted @ 2015-09-11 20:22  skyl夜  阅读(347)  评论(0编辑  收藏