HBase详解

1. 基本介绍

1.1 HBase概念

HBase是一种建立在Hadoop文件系统（利用HDFS）上的分布式面向列的数据库，是Hadoop生态系统中的一员。

1.2 HBase为什么出现

首先，大数据最常用的是Hadoop，它使用分布式文件系统（HDFS）存储大数据，并且通过自己的计算引擎（MapReduce）来处理数据，而MapReduce是函数式编程模型，它适用于处理各种庞大的数据。

而这种函数式编程的缺陷在于即使是最简单的搜索，它也会搜索整个数据集，所以为了解决这个缺陷，需要一个能实现快速随机单点访问的存取数据库。

1.3 HBase功能

它的出现是为了解决上述问题，所以它最主要的功能就是随机实时读写。

HBase是一个数据模型，我们可以通过HBase直接对HDFS的数据实现存取。

1.4 HBase和HDFS

• 联系：它们的联系一张图就可以概括
  
• 区别：

HDFS	Hbase
HDFS是Hadoop的底层的存储大容量文件的分布式文件存储系统	HBase是建立在HDFS上的数据库
HDFS适合处理庞大的数据集而不能快速单独查找	HBase提供在较大的表中快速查找
高延迟批量处理，没有批处理概念	数十亿条记录中可以低延迟访问单个记录
只能顺序访问	HBase内部使用哈希表以及存储索引，它可以将在HDFS文件中的数据快速访问。

2. HBase原理

2.1 表格式

HBase的一个重要概念就是面向列，也就是说我们在定义时只能定义列族，也就是键值对，用一张表来说明其中具体的概念。

• RowKey（行键）：类似于MySql的主键
• ColumnFamiu（列族）：任意个列聚合成一个列族，HBase引入的新概念，我们可以把一组相关的列定义成一个列族，HBase相信我们在实际使用中往往不会把所有的列数据查询出，这时候我们就可以查询相应的列族。
• Column（列）：类似于MySql的列，具体的数据。
• TimeStamp（时间戳）：更新数据的时候，标识同一行数据的不同版本，与列绑定。
• Cell(单元格)：单元格由行键、列族、时间戳唯一决定，可以理解为一条数据。

一张具体的数据表可以直观的标示列和列族的关系。

这里时间戳没有列出来，因为它是和单元格绑定的，由系统去决定（类似于Mysq的版本号），一个单元格会被修改而拥有不同的版本，版本就由时间戳去标识。

也正因为时间戳这个概念，HBase的插入（Input）也是更新（Update），我们对一个单元格去插入新的数据，这时候单元格中最新的记录就是这条新数据，由时间戳标识，我们查询查到的也是这条记录，一般来说HBase对于一个Cell会存储三个版本的数据，超过三个会删除最早的，如果插入的时候有相应列的数据为空，则按照稀疏的特点它就是空而不是上一条数据的值。

另外，我们说HBase是键值对的形式存在的，这里的键并不是行键，而是由行键+列族：列+TimeStamp共同组成一个key，而value就是相应的列的数据。

Key	Value
RowKey+CF：Col+Version	value

2.2 特点

• 无模式：每行都有一个可排序的主键和任意多的列，同一张表不同的行可以有不同的列。
• 面向列：面向列（族）的存储和权限控制，列（族）独立检索。
• 稀疏：空（null）列不占用存储控件，表可以设计的很稀疏，例如上述的表中行键为2的数据的personal data列族可以为空，或者具体的name列为空，这样不会占用多余的空间。

2.3 底层存储机制

HBase的通过对rowkey的排序分区等操作对数据进行管理。

• 排序：HBase对RowKey做了排序，这样可以保证类似的RowKey集中在一起，提高查询效率。
• 分区：HBase中每张表会通过行键按照一定的范围分割成多个子表（HRegion），默认的一个HRegion超过256M就会被分割成两个，HRegion由HRegionServer管理，每个HRegionServer管理那些HRegion由HMaster分配。

当HRegionServer存取一个子表时，会创建一个HRegion对象，然后表的每个列族（ColumnFamily）创建一个Store实例，一个Store由多个StoreFile与之对应，每个StoreFile会对应一个HFile，HFile就是实际的存储文件，HFile就存储在HDFS的DataNode上，每个Store还会有一个memStor，它是用于写缓存的，存储在内存中。

这里HBase存在HDFS上主要的是HFile，另外还有一种HLogFile，它实际上就是WAL（Write Ahead Log）文件，用来存储未写入永久性存储区中的新数据，下面是HFile的文件结构。

HFile是HBase中KeyValue数据的存储格式，HFile是Hadoop的二进制格式文件，StoreFile就是对HFile做了轻量级包装，实际上底层就是HFile。

• Data Block：保存表中数据，这部分可以被压缩
• Meta Block：（可选）保存用户自定义的kv对，可以被压缩。
• File Info：Hfile的meta元信息，不被压缩，定长。
• Data Index：Data Block的索引。每个Data块的起始点。
• Meta Index：Meta Block块的索引，Meta块的起始点。
• Trailer：定长。保存了每一段的偏移量，读取一个HFile时，会首先读取Trailer，Trailer有指针指向其他数据块的起始点，保存了每个段的其实位置，然后Data Index被读取到内存中，再找到需要的key。
• KeyValue：KeyValue就是一个简单的byte数组，有固定的结构，固定的位置上是固定的信息。

3. HBase的读写

3.1 读

HBase中有一个特殊的表格起到目录作用，称为META table，META table中保存集群region的地址信息。ZooKeeper中会保存META table的位置。

当用户第一次向HBase进行读写操作时

1. 客户从ZooKeeper得到META table的Region Server 的信息
2. 客户向该Region Server查询负责管理自己想要访问的row key所在的region的Region server的地址（通过table的Region server找到需要的Region Server）
3. 客户与负责其row所在的Region的Region Server通信，实现读写操作。客户会缓存这一信息。

当再次读写时，会先查找缓存，如果没有则执行上述流程。

当客户与RegionServer通信时，上文提到过，RegionServer会创建一个Region实例，在RegionServer中，多个Region之上有一个共同的BlockCache，这是一个读缓存，它将经常被读的数据存储在内存中提高读取数据的效率，如果它被占满，则读取频率低的数据会被杀出。

如果BlockCache中没有相应的数据，就去相应的StoreFile中读取Block的数据，如果还没有就把这个Block的数据写入Cache中，接着找下一块直到找到，如果整个Region都没有就返回null，其中Block使用LRU算法管理它的内存。

3.2 写

1. Client发起一个Put请求给HBase，跟上面一样，HBase先找到对应的RegionServer，由RegionServer将请求匹配到对应的Region上。
2. 写之前RegionServer先将数据写入HBase的WAL文件中（HLogFile），WAL文件是顺序写入的，保存在硬盘，所以如果Server出现问题可以用它来恢复。
3. 然后将数据保存到具体的Region的MemStore中，同时检查MemStore的状态，如果满了就触发Flush to Disk请求。
4. RegionServer处理Flush to Disk请求，将数据写成HFile文件存到HDFS上，存储最后写入的数据序列号，这样可以知道哪些数据已经存入了永久存储的HDFS。

其他一些需要注意的点

• HBase尽量定义少的列族：因为不同的列族会共享Region，有可能出现一个列族已经有1000万行，另一个列族才100行，当一个Region被分割时，100行的列族依然会被分布到多个region中。
• Minor Compaction：HBase会自动选取一些小的HFile进行合并，这个过程是Minor Compaction，通过这个减少文件数量来提升性能。
• Major Compaction：HBase将对应于某一个Column Family的所有HFile重新整理合并为一个HFile，并在这一过程中删除已经删除或过期的cell，更新现有cell的值，这个操作会提升读的效率。这个过程包含大量的硬盘IO和网络通信，所以过程中Region基本不可访问。因此Major Compaction建议安排在夜间或周末执行。