4.1 HBase简介

4.1.1 逻辑模型

HBase以表的形式存储数据，每个表由行和列组成，每个列属于一个特定的列族（Column Family）。表中由行和列确定的存储单元称为一个元素（Cell），每个元素保存了同一份数据的多个版本，由时间戳（Time Stamp）来标识。表4-1给出了www.cnn.com网站的数据存放逻辑视图，表中仅有一行数据，行的唯一标识为com.cnn.www，对这行数据的每一次逻辑修改都有一个时间戳关联对应。表中共有四列：contents：html、anchor：cnnsi.com、anchor：my.look.ca、mime：type，每一列以前缀的方式给出其所属的列族。

表4-1 数据存储逻辑视图

行键是数据行在表中的唯一标识，并作为检索记录的主键。在HBase中访问表中的行只有三种方式：通过单个行键访问；给定行键的范围访问；全表扫描。行键可以是任意字符串（最大长度64KB），并按照字典序进行存储。对于那些经常一起读取的行，需要对key值精心设计，以便它们能放在一起存储。

表中的列定义为：＜family＞：＜qualifier＞（＜列族＞：＜限定符＞），如“contents：html”。通过列族和限定符两部分可以唯一地指定一个数据的存储列。HBase在磁盘上按照列族储存数据，所以一个列族里所有的项最好具备相同的读/写方式，以提高性能。

时间戳对应着每次数据操作所关联的时间，可以由系统自动生成，也可以由用户显式地赋值。注意，如果应用程序需要避免数据版本冲突，则必须显式地生成时间戳。HBase提供了两种数据版本的回收方式：一是对每个数据单元，只存储指定个数的最新版本；二是保存最近一段时间内的版本（如七天）。客户端可以查询“从某个时刻起的最新数据”，或者一次得到所有的数据版本。

元素由行键、列（＜列簇＞：＜限定符＞）和时间戳唯一确定，元素中的数据以字节码的形式存储，没有类型之分。

4.1.2 物理模型

HBase是按照列存储的稀疏行/列矩阵，物理模型实际上就是把概念模型中的一个行进行分割，并按照列族存储，如表4-2所示。从表中可以看出表中的空值是不被存储的，所以查询时间戳为t8的“contents：html”将返回null，同样查询时间戳为t9，“anchor：my.look.ca”的项也返回null。如果没有指明时间戳，那么应该返回指定列的最新数据值，并且最新的值在表格里也是最先找到的，因为它们是按照时间排序的。所以，如果查询“contents：”而不指明时间戳，将返回t6时刻的数据；查询“anchor：”的“my.look.ca”而不指明时间戳，将返回t8时刻的数据。这种存储结构还有一个优势，可以随时向表中的任何一个列族添加新列，而不需要事先声明。

表4-2 物理上的存储方式

4.1.3 Region服务器

HBase在行的方向上将表分成了多个Region，每个Region包含了一定范围内（根据行键进行划分）的数据。每个表最初只有一个Region，随着表中的记录数不断增加直到超过某个阈值时，Region就会被分割形成两个新的Region。所以一段时间后，一个表通常会含有多个Region。Region是HBase中分布式存储和负载均衡的最小单位，即一个表的所有Region会分布在不同的Region服务器上，但一个Region内的数据只会存储在一个服务器上。物理上所有数据都存储在HDFS上，并由Region服务器来提供数据服务，通常一台计算机只运行一个Region服务器程序（HRegionServer），每个HRegionServer管理多个Region的实例（HRegion），如图4-1所示。其中HLog是用来做灾难备份的，它使用的是预写式日志（WAL，Write-Ahead Log）。每个Region服务器只维护一个HLog，所以来自不同表的Region日志是混合在一起的，这样做的目的是不断追加单个文件，相对于同时写多个文件而言，可以减少磁盘寻址次数，因此可以提高对表的写性能。带来的麻烦是，如果一台Region服务器下线，为了恢复其上的Region，需要将Region服务器上的Log进行拆分，然后分发到其他Region服务器上进行恢复。

每个Region由一个或多个Store组成，每个Store保存一个列族的所有数据。每个Store又是由一个memStore和零个或多个StoreFile组成，StoreFile则是以HFile的格式存储在HDFS上的，如图4-2所示。

当客户端进行更新操作时，先连接有关的HRegionServer，然后向Region提交变更。提交的数据会首先写入WAL（Write-Ahead Log）和MemStore中，当MemStore中的数据累计到某个阈值时，HRegionServer就会启动一个单独的线程将MemStore中的内容刷新到磁盘，形成一个StoreFile。当StoreFile文件的数量增长到一定阈值后，就会将多个StoreFiles合并（Compact）成一个StoreFile，合并过程中会进行版本合并和数据删除，因此可以看出HBase其实只有增加数据，所有的更新和删除操作都是在后续的合并过程中进行的。StoreFiles在合并过程中会逐步形成更大的StoreFile，当单个StoreFile大小超过一定阈值后，会把当前的Region分割（Split）成两个Regions，并由HMaster分配到相应的Region服务器上，实现负载均衡。

4.1.4 主服务器

HBase每个时刻只有一个HMaster（主服务器程序）在运行，HMaster将Region分配给Region服务器，协调Region服务器的负载并维护集群的状态。HMaster不会对外（Region服务器和客户端）提供数据服务，而是由Region服务器负责所有Regions的读写请求及操作。如果HRegionServer发生故障终止后，HMaster会通过ZooKeeper感知到，并处理相应的Log文件，然后将失效的Regions进行重新分配。此外，HMaster还负责管理表的schema和对元数据的操作。

由于HMaster只维护表和Region的元数据，而不参与数据的输入输出过程，HMaster失效仅会导致所有的元数据无法被修改，但表的数据读写还是可以正常进行的。

4.1.5 元数据表

用户表的Regions元数据被存储在.META.表中，随着Region的增多，.META.表中的数据也会增大，并分裂成多个Regions。为了定位.META.表中各个Regions的位置，把.META.表中所有Regions的元数据保存在-ROOT-表中，最后由ZooKeeper记录-ROOT-表的位置信息。所以客户端访问用户数据前，需要首先访问ZooKeeper获得-ROOT-的位置，然后访问-ROOT-表获得.META.表的位置，最后根据.META.表中的信息确定用户数据存放的位置，如图4-3所示。

-ROOT-表永远不会被分割，它只有一个Region，这样可以保证最多需要三次跳转就可以定位任意一个Region。为了加快访问速度，.META表的Regions全都保存在内存中，如果.META.表中的每一行在内存中大约占1KB，且每个Region限制为128MB，那么图4-3所示的三层结构可以保存的Regions数目为：(128MB/1KB)*(128/1KB)=234个。客户端会将查询过的位置信息缓存起来，且缓存不会主动失效。如果客户端根据缓存信息还访问不到数据，则询问持有相关.META.表的Region服务器，试图获取数据的位置，如果还是失效，则询问-ROOT-表相关的.META.表在哪里。最后，如果前面的信息全部失效，则通过ZooKeeper重新定位Region的信息。所以如果客户端上的缓存全部是失效，则需要进行6次网络来回，才能定位到正确的Region。