深入理解HBASE(2)列簇与Qualifier

什么是列簇(Family)?

列簇是基础信息或公司域名或水果类。列是基础信息:面貌、基础信息:年龄、公司域名:org、公司域名:edu、水果类:苹果、水果类:香蕉。
qualifier是列的名字。

image.png

[图片上传中...(image.png-371d2f-1553349122734-0)]

所以可以简单的理解为,HBase中的列是二级列,
也就是说Family是第一级列,Qualifier是第二级列。两个是父子关系。

cell

由{row key,column(=<family> +<qualifier>),version}
唯一确定的单元。
一般get出来的为最新版本,也可以指定
get 'me','weihongrao',{COLUMNS=>['f1:age','f1:home'],VERSIONS=>2}

列簇的特点:

1、一张表通常有一单独的列簇,而且一张表中的列簇不会超过5个。
2、列簇必须在创建表的时候定义。
3、表的列簇无法改变。
4、每个列簇中的列数是没有限制的。
5、同一列簇下的所有列会保存在一起。
6、列在列簇中是有序的。
7、列在运行时创建。
8、列只有插入后才会存在,空值并不保存。

列簇的作用

权限控制、存储以及调优都是在列族层面进行的
实际应用中,列族上的控制权限能 帮助我们管理不同类型的应用:我们允许一些应用可以添加新的基本数据、一些应用可以读取基本数据并创建继承的列族、一些应用则只允许浏览数据(甚至可能因 为隐私的原因不能浏览所有数据)。

重点:列簇与数据存储

对同一个行键的访问都会落在同样的物理节点上。如果表包含2个列簇,属于两个列簇的文件还是保存在相同的节点上。因此,行键和节点存在一一对应的关系。
每一列簇都会保存在自己的文件集合中。在列簇中检索某列是顺序的I/O。从2个列簇中读取数据表示需要读取HDFS中2个不同的文件和块。所有的存储设置都需要在列簇级别指定。

Region虽然是分布式操作的最小单元,但并不是存储的最小单元,在region里面,又划分了很多更小的单位进行存储,如下所示


image.png
  1. Region由一个或者多个Store组成,每个Store保存一个ColumnFamily
  2. 每个Store又由一个memStore和多个storefile组成
  3. memstore存储在内存中,storefile存储的HDFS上

RegionServer打开一个region的时候,会创建一个相应的HRegion对象。当这个HRegion被打开,他会为每一个表中的每一个列簇创建一个Store实例,就像用户之前创建的那样。每一个Store实例相应地有一个或者多个StoreFile实例,StoreFile是真正存储数据的文件(HFile)的(hdfs系统中对应的目录)
一个Store还会有一个Memstore。
每一个HRegionServer中的所有东西会共享一个HLog实例。(WAL实例)

hbase table中每个列簇都对应着region中的一个store,在hdfs系统中则对应着一个目录,如果列簇中尚无数据,怎该目录为空,也就是该store下还没有storefile。

关于列簇的数量

如果只有一个family,那么每一次读都会读取当前rowkey的所有数据,网络和io上会有一些损失。

如果family设置的很多那么获取每一个cell数据的优势越明显,因为io和网络都减少了
当然如果要获取的是固定的几列数据,那么把这几列写到一个family中比分别设置family要更好,因为只需一次请求就能拿回所有数据。

每一个family都会分配一个memstore,所以更多的family会消耗更多的内存。
其次,目前版本的hbase,在flush和compaction都是以region为单位的,也就是说当一个family达到flush条件时,该region的所有family所属的memstore都会flush一次,即使memstore中只有很少的数据也会触发flush而生成小文件。
--->小的文件多了就会增加compaction的几率(合并小文件)
– 目前为止HBase的列族能能够很好处理最多不超过3个列族。

对于传统关系型数据库中的一张table,在业务转换到hbase上建模时,从性能的角度应该如何设置family和qualifier呢?
最极端的,可以每一列都设置成一个family,也可以只有一个family,但所有列都是其中的一个qualifier,那么有什么区别呢?
family越多,那么获取每一个cell数据的优势越明显,因为io和网络都减少了,而如果只有一个family,那么每一次读都会读取当前rowkey的所有数据,网络和io上会有一些损失。
当然如果要获取的是固定的几列数据,那么把这几列写到一个family中比分别设置family要更好,因为只需一次请求就能拿回所有数据。
以上是从读的方面来考虑的,那么写呢?可以参考一下这篇文章:
http://hbase.apache.org/book/number.of.cfs.html
首先,不同的family是在同一个region下面。而每一个family都会分配一个memstore,所以更多的family会消耗更多的内存。
其次,目前版本的hbase,在flush和compaction都是以region为单位的,也就是说当一个family达到flush条件时,该region的所有family所属的memstore都会flush一次,即使memstore中只有很少的数据也会触发flush而生成小文件。这样就增加了compaction发生的机率,而compaction也是以region为单位的,这样就很容易发生compaction风暴从而降低系统的整体吞吐量。
第三,由于hfile是以family为单位的,因此对于多个family来说,数据被分散到了更多的hfile中,减小了split发生的机率。这是把双刃剑。更少的split会导致该region的体积比较大,由于balance是以region的数目而不是大小为单位来进行的,因此可能会导致balance失效。而从好的方面来说,更少的split会让系统提供更加稳定的在线服务。
上述第三点的好处对于在线应用来说是明显的,而坏处我们可以通过在请求的低谷时间进行人工的split和balance来避免掉。
因此对于写比较多的系统,如果是离线应该,我们尽量只用一个family好了,但如果是在线应用,那还是应该根据应用的情况合理地分配family。

推荐阅读更多精彩内容