浅析HBase：为高效的可扩展大规模分布式系统而生

一时失言乱红尘 2022-06-15 11:12 382阅读 0赞

*  什么是HBase
    
     *  关系型数据库与HBase的对比
     *  关系型数据库的局限性
     *  HBase的高效，分布式，可扩展性的设计理念
     *  HBase的数据模型

# 什么是HBase #

Apache HBase是运行在Hadoop集群上的数据库。为了实现更好的可扩展性（scalability），HBase放松了对ACID（数据库的原子性，一致性，隔离性和持久性）的要求。因此HBase并不是一个传统的关系型数据库。另外，与关系型数据库不同的是，存储在HBase中的数据也不需要遵守某种严格的集合格式，这使得HBase是用来存储结构不严格的数据的理想工具。

HBase在大数据应用的架构中应用非常广泛。但是基于其与关系型数据库迥异的设计模式，实现这些应用也与基于关系型数据库来实现非常不同。下文将会对比HBase和关系型数据库，并浅析HBase的特性。

## 关系型数据库与HBase的对比 ##

首先我们要明白在已经存在关系型数据库的情况下，为什么产生了所谓的NoSQL/HBase这样的费关系型数据库？要解答这个问题，我们需要先了解一下关系型数据库的优势和缺点。

*  关系型数据库提供了标准的数据持久性模型
 *  SQL语言是事实上的数据操作标准语言
 *  关系型数据库内置了并发数据操作的管理机制
 *  关系型数据库提供全面的数据操作工具

![RDBMS table][]

关系型数据库是长期以来数据存储的标准工具，那么我们为什么还在寻找新的数据存储方法呢？原因是现在需要存储的数据越来越多，工业界对数据存储工具可伸展性的要求也越来越高。一种简单直接的扩展方法是垂直扩展，也就是采用更大更高效的服务器来存储。但是这种方法成本很高，且可扩展性存在一个上限（单台服务器的性能是有限的）。

![Vertical scale][]

## 关系型数据库的局限性 ##

除垂直扩展之外，我们也可以采用水平扩展的方法。也就是用服务器集群来满足要求。用来集群的服务器可以是性能普通的服务器。这样就可以大大降低运营成本。如果我们要采用水平扩展的方法来扩展关系型数据库，关系型数据库中的数据势必要根据row key分布存储，也就意味着某些row key对应的行存储在某一台服务器上，另一些row key对应的行存储在另一台服务器上。然而，要分割一个关系型数据库是非常复杂的，并且关系型数据库不具备自动分布式存储的功能。不仅如此，分布存储关系型数据库，我们将失去总体上的数据库查询功能及事务（transaction）的一致性。总而言之，关系型数据库是为在单台服务器上运行而设计的。

![Horizontal scale][]

除此之外，关系型数据库中数据库规范化（database normalization）的理念消除了数据的重复存储，使得数据存储更高效。在查询时为了将数据重新组织起来，就需要需要**Join**操作。这也进一步使得关系型数据库的分布式存储更为困难。

## HBase的高效，分布式，可扩展性的设计理念 ##

由于HBase在设计上不支持**关系**和**Join**这样的概念，需要一起查询的数据就被存在一起。因此也就避免了关系型数据库的一些局限性。下图表现了HBase和关系型数据库在数据存储模型上的不同。

![Relational DB vs HBase][]

由于HBase将所有需要一起查询到数据存储在一起这一特性，HBase集群就自然能够根据key来组织数据。在水平分割的时候，key值的范围就可以被用来分割数据。每一个服务器存储全部数据的一个子集。同时分布式的数据还可以被同时访问。这大大增强了HBase的可扩展性。HBase实际上是Google Big Table的一个实现。Big Table是Google提出的一个用来存储大规模数据的一个分布式系统。

HBase是基于**Column family data store**的理念设计的：每一行根据一个row key索引。也就是我们用来查询的主键。同时每一行中有若干column family。每一个column family中有若干相关的column。如下图所示。

![HBase column family oriented database][]

HBase中的row key也是HBase分布式存储数据的主要根据。在分布存储数据的时候，根据row key值的范围，每一台服务器存储全部数据的一个子集。HBase提供基于行的原子性操作保证。也就是每一个row key对应的行为一个原子操作的单元。

![Distributed HBase][]

## HBase的数据模型 ##

HBase中的数据根据row key分布。row key类似于关系型数据库中的主键（primary key）。HBase中的数据记录根据row key的值排序。这是HBase数据存储的一个重要原则，也是HBase设计架构的一个重要部分。

![Hbase data model--row key][]

HBase中数据表根据row key的值分割为不同的区域，每个区域包含一部分连续的行。这些区域被分配给集群中不同的称为区域服务器的数据结点。可扩展性就是通过将区域分配给集群中的不同服务器实现的。这一操作是自动进行的。也就是HBase如何根据水平扩展设计的。

![Tables are split into regions = contiguous keys][Tables are split into regions _ contiguous keys]

下图表示了column family是如何映射到存储文件的。不同的Column family被存储在不同的文件中。这些文件可以被分别访问。

![Column families stored in separate files][]

数据存储在HBase表格的cell中。cell中包含key和value以及一些其他的信息（如version, type等）。其中key部分包括row key，column family，column qualifier, timestamp。并且对于每一个值，key部分都会与其一同被存储。如下图所示。

![cell key value][]

从逻辑上来看，row似乎是以表格的形式存储的。但事实上，row是以一些cell的集合的形式存储的。其所对应的每一个cell都存储了其所对应的上述所有key信息。

下图中上半部分是HBase的数据的逻辑布局，下半部分是文件的物理布局。Column family被分别存储于不同的文件中。我们每设置一个值，其对应的cell就会存储所有的key信息（row key, column family, column qualifier, timestamp）。

![Logical data model vs physical data model][]

综上所述，对于HBase中每一个cell的值，其完整的索引应当是**Table::Row::Column family::Column::Timestamp –> Value**。Hbase的表是稀疏的。如果某一列没有数据，则其不会被存储。表中的cell有其对应的连续改变的version。version默认参考timestamp，但我们也可以自己定制。对于每一个**Table::Row::Column family::Column –> Value**，数据库中可能存储了多个不同version的值。

![sparse data with cell versions][]

Version系统是HBase自动采用的。从CRUD的角度来说，一个put操作既是插入（insert/create），也是更新（Update）操作，每一个数据都会带有其相应的version。Delete操作并不会立即在物理上删除数据，而是会给数据加一个删除标签。这个标签会保证数据不会在查询时被返回。Get操作根据给定的参数返回特定version的数据。默认情况下最新版本的数据将会被返回。保存在HBase中的同一个数据的不同version的数量也可以配置。这个数量是针对同一个column family而言的。默认情况下，HBase会保存3个不同version的数据。当数据不同的version数目超过这个数字时，最早version的数据将会被删除。

![versioned data][]

[RDBMS table]: /images/20220615/938803cdf82240b0ab59ae3be4f9ef22.png
[Vertical scale]: /images/20220615/b92c80b050cf44c48ed633390fe37a29.png
[Horizontal scale]: /images/20220615/6900452f1f4a431f84ecca020da29472.png
[Relational DB vs HBase]: /images/20220615/4ff32245d79946f48bba3a9bc61bc011.png
[HBase column family oriented database]: /images/20220615/4ee551ad81374ccfbc5de04b97aeb007.png
[Distributed HBase]: /images/20220615/80c2bf972e734471beee9919cdddc1a7.png
[Hbase data model--row key]: /images/20220615/673ad9c56e6c41d7ae6bf08928fec7e3.png
[Tables are split into regions _ contiguous keys]: /images/20220615/b934badfed0d42bb82b5db019e5532de.png
[Column families stored in separate files]: /images/20220615/c5386bf238c0407484348f1b1ac482bd.png
[cell key value]: /images/20220615/b7a5f17415ca428bb2d2ddb0c490e194.png
[Logical data model vs physical data model]: /images/20220615/d7ec662bbe4d4ed9b6cebe8101e675bc.png
[sparse data with cell versions]: /images/20220615/3363d90c8ab1409ca3fc2e1c8718b5ae.png
[versioned data]: /images/20220615/4688fe5c05124762a1530e0833a472c6.png
[HBase and MapR-DB_ Designed for Distribution_ Scale_ and Speed]: https://mapr.com/blog/hbase-and-mapr-db-designed-distribution-scale-and-speed/#.VcKFNflVhBc