什么是列簇（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

Region由一个或者多个Store组成，每个Store保存一个ColumnFamily
每个Store又由一个memStore和多个storefile组成
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。