HBase是一个分布式开源数据库，基于Hadoop分布式文件系统，它的原型是google的BigTable分布式数据库。HBase是apache Hadoop生态圈中的重要子项目之一。
HBase的设计目标是处理非常庞大的表，可以使用普通的计算机处理超过10亿行数据，并且有百万列元素组成的数据表。因此在文件在几百万行或者上千万行时不需要使用HBase[9]。
图2-1表示了在Hadoop生态圈中各个子项目之间的关系[10]。
HDFS为HBase提供了高可用性的底层存储支持，MapReduce为其提供了高可用性的计算能力，Hive和Pig提供了操作数据库的语言，zookeeper保证了分布式数据库的一致性要求，Sqoop提供了传统关系数据库的导入功能[11]。它们都使得HBase的使用越来越广泛、越来越简单。
由于HBase是一个稀疏的、长期存储的、多维度的、排序的映射表。简单来说，应用程序是以表的方式在HBase存储数据的。表是由行和列构成的，所有的列式从属于某一个列族的。行和列的交叉点成为cell，cell是版本化的。Cell的内容是不可分割的字节数组。表的行键也是一段字节数组，所有任何东西都可以保存进去，不论是字符串还是数字。HBase的表是按key排序的，排序方式是针对字节的。所有的表都必须要有主键key[13]。
下面我们根据一个实例来讲解一下HBase的逻辑模型。表2-1是一个数据表的逻辑模型的逻辑视图[14]。它表示的含义是，在一个网站中，每个网页的内容和锚点。
表2-1 逻辑视图
| Row Key | Time Stamp | ColumnFamily contents | ColumnFamily anchor |
| "com.cnn.www" | t9 |
| anchor:cnnsi.com = "CNN" |
| "com.cnn.www" | t8 |
| anchor:my.look.ca="CNN.com" |
| "com.cnn.www" | t6 | contents:html=”<html>..." |
|
| "com.cnn.www" | t5 | contents:html="<html>..." |
|
| "com.cnn.www" | t3 | contents:html ="<html>..." |
|
行键(RowKey)是数据行在表中的唯一标识，是该记录的主键，相当于是关系数据库的主键。行键可以是任意字符串，最大长度为64KB，在HBase内部，行键保存为字节数组。存储时，数据按照行键的字典序（byteorder）排序存储。设计key时，要注意排序存储这个特性，将经常一起读取的行存储放在一起。比如在电商中，行键设计为userId+url，这样的话，某个用户的访问路径就放在了一起，在推荐系统中可以方便的读取这些信息。在关系数据库中，主键是唯一标识的，不能重复的，在HBase中是否也是如此？访问HBasetable中的行时，通过行键访问或全表扫描[15]。
HBase表中的每个列都归属于某个列族。列名是由它的列族前缀额修饰符连接而成的。例如列contents:html是列族 contents加冒号（：）加修饰符html组成的。
时间戳是HBase区别与传统关系数据库的重要特点。我们HDFS和HBase存储的都是流式数据。在HBase中进行update和delete操作时，实际上并没有将原来的数据进行更新和删除，而是插入新的数据，只是时间戳不同而已。HBase根据时间戳来判断哪个数据是最新的版本[16]。时间戳的类型是64位的整型，默认情况下，它由系统根据当前时间自动生成，用户也可以设置时间戳。我们知道HBase是基于HDFS设计的，因此HBase的很多特性跟HDFS有密切的关系。
一个个的单元格就是一个cell。HBase中的元素由行键、列和时间戳唯一确定，元素中的数据以字节码形式存储，没有特定的类型。cell是一个完整的部分，不能被分割。
HBase的逻辑模型是一个类似于稀疏矩阵的表格，它里面允许为空。尽管在概念逻辑视图中，表可以看成是一个稀疏的行的集合，但是在物理上，它是区分列族存储的。新的columns可以不经过声明直接加入一个列族。表2-2是表2-1的物理视图。
表2-2 物理视图
| Row Key | Time Stamp | Column Family anchor |
| "com.cnn.www" | t9 | anchor:cnnsi.com = "CNN" |
| "com.cnn.www" | t8 | anchor:my.look.ca = "CNN.com" |
| "com.cnn.www" | t6 | contents:html = "<html>..." |
| "com.cnn.www" | t5 | contents:html = "<html>..." |
| "com.cnn.www" | t3 | contents:html = "<html>..." |
值得注意的是在上面的概念视图中空白的cell在物理上是不存储的，因为根本没有必要，而且存储的话会浪费大量的空间。因此若一个请求要获取t8时间的contents:html，他的结果就是空。相似的，若请求为获取t9时间的anchor:my.look.ca，结果也是空。但是，如果不指明时间，将会返回最新时间的行，每个最新的都会返回。例如，如果请求为获取行键为”com.cnn.www”，如果没有指明时间戳的话，活动的结果是t6下的contents:html，t9下的anchor:cnnsi.com和t8下的anchor:my.look.ca。
物理模型的特点是将不为空的cell存储起来。空白的就不再存储，不再是逻辑模式展示的矩阵的样子。
在上面我们对HBase的逻辑模型和物理模型做了详细的介绍，表2-3总结了HBase和传统关系数据库在逻辑模型和物理模型中的相同点和不同点[17]。
表2-3 HBase和关系数据库的不同
|
| HBase分布式数据库 | 关系数据库 |
| 逻辑模型 | 稀疏矩阵，比传统数据库多了一个时间戳 | 二维矩阵的形式 |
| 物理模型 | 由于数据库逻辑模型是一个巨大的稀疏矩阵，空cell是不存储的 | 矩阵全部存储 |
HBase是一种“NoSQL”数据库，NoSQL是一个通用词（NotOnly SQL）表示该数据库不是关系数据库。关系数据库支持SQL作为主要访问手段。HBase和HDFS一样遵循主从架构。每个HBase集群中有一个Master服务器，其他的节点叫做Regionserver[18]。Master和Regionservers都是基于HDFS的，换句话说，它们的最终操作也是对HDFS的操作。Zookeeper是协调各个数据库节点数据一致性的集群管理工具。
HMaster主服务器在任何时刻都在运行，它将Region分配给Region服务器。协调Region服务器的负载并维护集群的状态。HMaster不对外提供数据查询的功能，这些功能由Region来负责。
由于HMaster需要维护表和Region的元数据，并不参与数据的输入输出过程，Hmaster失效导致所有的元数据不能被修改，但是表的访问仍能正常进行。这并不代表HMaster不重要，当HMaster失效以后，HMaster不知道各个节点的状态，无法进行负载均衡等操作[19]。
HMaster的作用有一下几点：
（1）负责Region server的负载均衡。
（2）发现失效的RegionServer并重新分配其上的Region。
（3）为Region server分配region
（4）HDFS上的垃圾回收
（5）处理schema更新请求。
HRegion服务器上面存储的是HBase的数据。HBase在逻辑上的最小单位是Region，物理上是HFile。每个Region由多个Hfile组成。结合图2-2来理解Region的组成。
图2-2 Region的组成
每个Region是由多个Store和一个Log组成的，Log保存的是Region的日志信息。Store又是由一个MenStore和多个StoreFile组成的，每个Store保存一个列族的数据。StoreFile是由一个或者多个HFile组成的，HFile是保存数据最小的物理单元[20]。
需要讨论的问题，每台regionserver上面运行几个Region，Region的大小是多少，HBase的高可用性是如何实现的，HBase是如何划分Region的。
在HBase表中，所有的行都是按照行键的字典排序，在行的方向上划分多个Region。
Region是按大小划分的，每个表一开始只有一个Region，随着数据不断插入表，region不断增大。每增大到一个阀值时，就会分裂成两个region。当table中行不断增加，region的数量也不断增加。
Region是HBase在分布式存储和负载均衡的最小单元。最小单元的含义是不同的region可以分布在不同的regionserver上，但是一个region 不能处于不同的server上面。
Region是逻辑上的最小单元，但是并不是存储的最小单元。事实上，HRegion由一个或者多个store组成，每个store保存一个列族的数据。每个store又是由一个memStore和多个StoreFile组成的。
HBase中有一张张的表table，每个table在创建的时候只有一个Region，随着数据的插入，Region越来越大，等到它达到一定的阀值的时候，每个Region会分裂成两个Region，注意Region的分裂是按行进行的。如图2-3所示。
图2-3 HBase工作流程
Region和HMaster保持通信，HMaster存放着描述Region状态的元数据，所以HMaster掌握着Region的信息，HMaster决定这些Region分配到那个HRegionServer上面，才能使得集群的负载是均衡的。HMaster监控着HRegionServer上各个Region的状态，当Region失效时，采取相应的措施来恢复数据[21]。应用程序访问HBase时，访问的是HRegionServer上的Region。
元数据即是描述数据的数据。在HBase中，元数据就是描述HBase中Region的数据。这些元数据被存储在META表中，随着Region的增加，元数据也会增加，当增加到一定的阀值时它也会分裂成两个Region，这一点和Region的工作原理是一样的，因为HBase在设计的时候，元数据和普通数据的存储方式是一样的，只是元数据是存储在HMaster上面的。为了定位META表中各个Region的位置，把META表中所有Region的元数据保存在ROOT表中，最后由zookeeper记录ROOT的位置，然后访问ROOT表获取META的位置，通过META中记录的Region的位置找到相应的Region。因此，任何Region经过三跳就能定位。
当客户端进行更新操作时，先连接到相关的HRegionServer，然后向Region提交变更。提交的数据首先要写入WAL和MemStore，当MemStore中的数据积累到一定的数量时，HRegionServer会启动一个线程，将MemStore中的内容刷新得新的磁盘，形成StoreFile文件。当StoreFile的数量增到一定的数量时，将多个storeFile合并成一个StoreFile，合并的过程中进行版本的合并和数据删除。
当用户进行查询操作时，同样需要先定位到相应的Region。读出数据返回client。
HBase以其特有的性质受到广泛的关注。首先，它的强一致性读写特性，HBase不是最终一致性数据存储。这让它很适合高速计数聚合类任务。其次是它的自动分块特性，HBase表通过Region分布在集群中。数据增长时，region会自动分割并重新分布。然后是自动故障转移，当某个HRegionServer发生错误时，HMaster会自动恢复这个HRegionServer上的数据，并做负载均衡。最后是列式存储特性，传统的关系数据库采用行存储，由于HBase存储的是稀疏矩阵，用列式存储提供了磁盘利用率[22]。
HBase与Hadoop无缝连接，有下面几个显著的优点：
1、廉价的节点。在使用传统关系数据库时，一个数据库服务器需要承受很大的访问量，服务器由需要处理器和内存组成，只有大公司比如IBM生存的小型机等菜符合要求。如果服务器宕机，不仅造成不可估量的损失，维护也是很大的问题，因为很少公司会维护IBM公司的设备，买进新的服务器价格也是非常昂贵的。HBase使用的设备是普通的PC机，廉价而且购买的渠道广泛，易于维护。
2、高可用性。传统关系数据放在一台机器上，一旦硬件发生故障，整个系统就瘫痪了。在HBase中，如果一个节点宕机，系统仍然能正常运行。亚马逊机器的可靠性已经做到99.9999999%，可见HBase的高可用性。
3、可扩展性。扩展传统数据库意味着升级服务器，复制数据。且不说服务器的价格不菲，在复制数据的过程中，操作繁琐且易错。而扩展HBase时增加节点（HRegionServer）以后重启Hadoop和HBase即可，其他的工作Hadoop和HBase自己会完成[23]。
HBase由于流式存储的特性也有相应的缺点。HBase的实时性差，不善于处理即时业务。但是随着技术的发展，HBase在实时性方面做出了很大的改进，我们将在HBase的性能优化章节具体介绍这个问题。
729
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
