HBase学习之路(四):理解HBase的基本架构

一、HBase表结构剖析

HBase是面向列的非关系型数据库，可以简单地总结，列是HBase最基本的单位，一行由多列组成。具体组成结构如下：

1. 行健

行健(RowKey)的作用是在HBase表中唯一标识一行，与关系型数据库中的主键很类似，在同一张表中唯一。行健会按字典序排序，如何保证行健的有序性呢？与关系型数据库不同，在HBase中行健最终会转化为字节数组存储的，所以无论你的行健输入是什么类型，最终统一会转化为字节数组存储，从而保证了可排序性。

图中为一张表的数据，可以发现row-2比row-10大这是因为，转化为字节数组时从高位比起，“row-”大家都相等，“2”比“1”要大，因此row-2比row-10大，和我们正常的想法是不一样的。行健不需要在建立表的时候就定义好，等到插入数据时才随着数据一同插入。

2. 列族

列族(Column Family)包含若干列，列族名必须是可见字符，可以由任意二进制字符组成，列族有助于构建数据语义边界或局部边界，同一个列族的所有列存储在同一个底层存储文件中，这个文件是HFile。列族必须在健表时就要定义好，数量不宜过多一般不超过2个，并且不宜频繁修改。

3. 列

列必须属于某一个列族下，列与列族不同，在创建表时不需要先在表中定义列，而是等到往表中插入数据时随着数据一同插入，列名可以由任意二进制字符组成。

4. 单元格

可以把单元格理解为最终你要存储的内容，在HBase中，一切皆为字节数组，没有数据类型可言，这一点与关系型数据库差别非常大，因此你存贮的内容也将变成字节数组存储在HBase中。

5. 时间戳

每一个存入的值都具有时间戳，默认由系统指定，也可以由用户显式指定。时间戳会被使用，例如通过不同的时间戳区分不同版本的值，同一个单元格的值按照时间戳降序排序，访问时优先读取最新版本的值。

综上，对于HBase表结构可以得出如下结论：

• 一张表由若干行组成，行健唯一标识每一行，一行有一个或多个列族，每个列族有若干列，每一个列为一个单元格存储着用户的值，每个值可以存在多个时间版本，优先读取最新时间版本的值。
• 在创建表时只需要简单指定表名和列族即可创建一张表，无需指定其他信息。
• 通过一张图大致了解一张HBase表的布局：
  

二、HBase表数据模型

传统的关系型数据库面向行设计，采用二维表的电子表格模型存储数据，表中的各个字段必须在定义表时给出且必须先定义类型，由主键确定一行，假设某一行的某个字段没有值，必须要用null占位，表示该个字段为空，以下是一张典型的二维表：

而HBase则是面向列设计的，行和列没有向关系型数据库的二维表那样排列，而是采用了标签描述，每一个值都存储在一个标签下，且很重要的一点事是HBase采用稀疏存储，对于每一行如果某个列缺失，则不存储内容，不需要使用null来占位，所以你可能会看到一些奇怪的现象，有的行有很多值，有的行只有一个值，这就是稀疏存储，它不像二维表那么规整，会不规则，以下便是一张典型的HBase表：

可以看到该表有两个列族Family1和Family2，对于第一行而言，行健是RowA，它在Family1下有一列A，存有值，在Family2上有一列B存有值；对于第二行仅仅在列族Family1上有一列B，且列名与第一行不一样，印证上文所说的，列名是随着数据插入而决定的；第三行也是类似的，仅仅在列族Family2有列C。
进一步探讨，不难发现HBase实际上是一个Key-Value数据库，所谓的Key其实是行健，列族和列，时间戳，因此可以下一个结论在给定一张表中，HBase依靠三级坐标唯一定位数据，第一级坐标是行健，第二级坐标是列族和列，第三极坐标是时间戳，因此有了如下的数据存储模式：
(RowKey,Family,Column,TimeStamp) --> Value
我们从HBase里读取数据的过程就是输入对应的坐标，然后获取Value的过程，以下一张图可以直观地看到这三个坐标在HBase表中的分布：

三、HBase核心架构

1. HMaster

HMaster没有单点问题，HBase中可以启动多个HMaster，通过Zookeeper的Master Election机制保证总有一个Master运行，HMaster在功能上主要负责Table和Region的管理工作：

1. 管理用户对表的增、删、改、查操作
2. 管理HRegionServer的负载均衡，调整Region分布
3. 在Region Split后，负责新Region的分配
4. 在HRegionServer停机后，负责失效HRegionServer 上的Regions迁移

2. HRegionServer

HRegionServer主要负责响应用户I/O请求，向HDFS文件系统中读写数据，是HBase中最核心的模块。HRegionServer内部管理了一系列HRegion对象，每个HRegion对应了Table中的一个Region，HRegion中由多个HStore组成。每个HStore对应了Table中的一个列族(Column Family)的存储，可以看出每个列族其实就是一个集中的存储单元，因此最好将具备共同IO特性的列放在一个列族中，这样最高效。

HStore存储是HBase存储的核心了，其中由两部分组成，一部分是MemStore，一部分是StoreFiles。MemStore是Sorted Memory Buffer，用户写入的数据首先会放入MemStore，当MemStore满了以后会Flush成一个StoreFile（底层实现是HFile），当StoreFile文件数量增长到一定阈值，会触发Compact合并操作，将多个StoreFiles合并成一个StoreFile，合并过程中会进行版本合并和数据删除，因此可以看出HBase其实只有增加数据，所有的更新和删除操作都是在后续的compact过程中进行的，这使得用户的写操作只要进入内存中就可以立即返回，保证了HBase I/O的高性能。当StoreFiles Compact后，会逐步形成越来越大的StoreFile，当单个StoreFile大小超过一定阈值后，会触发Split操作，同时把当前Region Split成2个Region，父Region会下线，新Split出的2个孩子Region会被HMaster分配到相应的HRegionServer上，使得原先1个Region的压力得以分流到2个Region上。

3. ZooKeeper

Zookeeper Quorum中除了存储了-ROOT-表的地址和HMaster的地址，HRegionServer也会把自己以Ephemeral方式注册到Zookeeper中，使得HMaster可以随时感知到各个HRegionServer的健康状态。此外，Zookeeper也避免了HMaster的单点问题。

四、HBase读写流程

1. 读流程

HBase把各个region的位置信息存储在一个特殊的表中，这个表叫Meta table。Zookeeper里面存储了这个Meta table的位置信息。HBase的读流程如下：

• 客户端访问ZooKeeper，得到具体Meta table的位置。
• 客户端再访问Meta table所在的RegionServer，从Meta table中获得RowKey所在的RegionServer。
• 访问得RowKey所在的RegionServer，先从MemStore读取数据，如未找到，再从StoreFile中读取。

2. 写流程

• 客户端访问ZooKeeper，得到具体Meta table的位置。
• 客户端再访问Meta table所在的RegionServer，从Meta table中获得待写入RowKey所在的RegionServer的信息。
• 在该RegionServer上先把要修改的操作记录追加在预写日志(WAL)的末尾，预写日志在RegionServer奔溃时恢复MemStore中的数据。
• 写完预写日志后，再将数据写入MemStore，并保持有序。当MemStore满了以后会Flush成一个StoreFile，当StoreFile文件数量增长到一定阈值，会触发Compact合并操作，将多个StoreFiles合并成一个StoreFile，合并过程中会进行版本合并和数据删除。

五、总结

本文先剖析HBase的表结构，彻底了解HBase的表结构后进一步深入，将探讨HBase的数据模型，与关系型数据库的二维表相比，HBase是稀疏存储的，从而得出了HBase本质上是Key-Value数据库，由三个坐标作为Key，映射出唯一个Value。最后简单了解了HBase的核心架构及读写流程。感谢您的阅读，如有错误请不吝赐教！