传统的数据处理主要使用关系数据库（MySQL、Oracle等）来完成，不过关系数据库在面对大规模的数据存储时明显力不从心。比如，在有关高并发操作和海量数据统计运算的应用中，关系数据库的性能就明显下降。

大数据时代的数据规模大、增长快、格式多样，因此传统的关系数据库已经不能适应新的需求。在这样的背景下，非关系数据库开始成为主流的选择。为了更大地拓展数据库的存储潜力，谷歌（Google）公司首先研发了 BigTable，这就是 HBase 的原型。

HBase 是用 Java 编程语言实现的一个开源的非关系型分布式数据库，它参考了谷歌的 BigTable 数据建模白皮书。

HBase 是 Apache 软件基金会的 Hadoop 项目的一部分，运行于 HDFS 之上，为 Hadoop 提供类似于 BigTable 规模的服务。因此，它能以容错方式存储海量的稀疏数据。 HBase 是一个高可靠、高性能、面向列、可伸缩的分布式数据库，主要用来存储非结构化和半结构化的松散数据，设计它的目的就是用于处理非常庞大的表——通过水平扩展的方式，用计算机集群就可以处理由超过 10 亿行数据和数百万列元素所组成的数据表。

HBase 有许多功能支持线性和模块化扩展，HBase 集群通过添加托管在商用服务器上的 RegionServer 进行扩展。例如，一个集群从 10 台 RegionServer 扩展到 20 台，它的存储和处理能力都会翻倍。

以下是 HBase 的发展历程：

• 2006 年谷歌公司发表 BigTable 白皮书。
• 2006 年开始开发 HBase。
• 2008 年 HBase 成为 Hadoop 的子项目，刚开始它只是 Hadoop 的一部分。
• 2010 年 HBase 成为 Apache 的顶级项目。HBase 几乎实现了 BigTable 的所有特性。

HBase的特征

HBase有如下几个重要特征：

强一致性

HBase具有读写强一致性的特征，但HBase的数据存储不是采用“最终一致性”的，所以它非常适用于高效计算、聚合之类的任务。

Hadoop集成

HBase 支持开箱即用的 HDFS 作为其分布式文件系统。

故障转移

HBase 支持自动的 RegionServer 故障转移。

自动分片

HBase 中的表通过 Region 分布在集群上，而且 Region 会随着数据的增长自动拆分和重新分布。

并行处理

HBase 支持通过 MapReduce 进行大规模并行处理，将 HBase 用作源和接收器。

块缓存和布隆过滤器

HBase 支持用于大容量查询优化的块缓存和布隆过滤器。

多种语言的API

HBase 支持使用 Java 的 API 来编程进行数据的存取，还支持使用 Thrift 语言和 REST 语言的 API 来编程进行数据的存取。

HBase的优缺点

作为一种数据存储产品，自然具有优点和缺点。

下面是 HBase 的优点：

• 在传统的关系数据库中，如果数据结构发生了变化，就需要停机维护，而且需要修改表结构，而在 HBase 中数据表内的列可以做到动态增加，并且列为空的时候不存储数据，从而节省存储空间。
• HBase 适合存储 PB 数量级的海量数据，PB 级的数据在只采用廉价 PC 来存储的情况下，也可以在几十到一百毫秒内返回数据。这与 HBase 的极易扩展息息相关，正因如此，HBase 为海量数据的存储提供了便利。
• 传统的通用关系数据库无法应对在数据规模剧增时导致的系统扩展性问题和性能问题。HBase 可以做到自动切分数据，并且会随着数据的增长自动地拆分和重新分布。
• HBase 可以提供高并发的读写操作，而且可以利用廉价的计算机来处理超过 10 亿行的表数据。
• HBase 具有可伸缩性，如果当前集群的处理能力明显下降，可以增加集群的服务器数量来维持甚至提高处理能力。

上述是 HBase 的优点，对于一名优秀的开发者而言，不仅需要知道待选择产品的优点，还需要知道其缺点，唯有如此才能在技术选型时根据不同的业务选择出合适的产品。以下是 HBase 的缺点：

• 不能支持条件查询，只支持按照 RowKey（行键）来查询，也就是只能按照主键来查询。这样在设计 RowKey 时，就需要完美的方案以设计出符合业务的查询。
• HBase 不能支持 Master（主）服务器的故障切换，当 Master 宕机后，整个存储系统就会挂掉，不能提供正常的服务。
• 查询 HBase 时不支持通过 SQL 语句进行查询。

HBase与关系数据库的区别

这里从下面 6 点介绍 HBase 和关系数据库的区别：

数据类型

关系数据库采用关系模型，具有丰富的数据类型和存储方式；HBase 采用了更加简单的数据模型，它把数据存储为未经解释的字符串。

数据操作

关系数据库中包含了丰富的操作，其中包含了复杂的多表连接等；HBase 操作不存在复杂的表与表之间的关系，只有简单的插入、查询、删除、清空等，因为 HBase 在设计上就避免了复杂的表和表之间的关系。

存储模式

关系数据库是基于行模式存储的；HBase 是基于列模式存储的，每个列族都由几个文件保存，不同列族的文件是分离的。

数据索引

关系数据库通常可以针对不同列构建复杂的多个索引，以提高数据的访问性能；HBase 只有一个索引，通过巧妙的 RowKey 设计，HBase 中的所有访问方法，或者通过 RowKey 访问，或者通过 RowKey 扫描，使得整个系统的运行速度不会减慢。

数据维护

在关系数据库中，更新操作会用最新的当前值去替换记录中原来的旧值，旧值被覆盖后就不存在了；在 HBase 中执行更新操作时，并不会删除旧值，而是生成一个新值，旧值仍然保留。

可伸缩性

关系数据库很难实现横向扩展，纵向扩展的空间也比较有限；HBase 是为了实现灵活的水平扩展而开发的，所以能够通过在集群中增加或者减少硬件数量的方式轻松实现性能的伸缩。

HBase的应用场景

Hadoop 是高性能、高稳定、可管理的大数据应用平台。Hadoop 实现了一个分布式文件系统（Hadoop Distributed File System，HDFS）。HDFS 具有高容错性，被设计部署在低廉的硬件上，为应用程序访问数据提供了高吞吐量，因而适用于那些有着超大数据集的应用程序。

HBase 的存储是基于 Hadoop 的，HBase 具有超强的扩展性和大吞吐量，采用的存储方式为 Key-Value（键-值）方式，故而即使数据量增大也几乎不会导致查询性能的下降。

当然，我们也需要注意到，数据分析是 HBase 的弱项，因为 HBase 不支持表关联，所以当我们想实现 group by 或者 order by 时，需要编写很多的代码来实现 MapReduce。

正因为如此，我们才需要更合理地使用 HBase。下面是笔者根据自己的工作经验给出的一些使用 HBase 的建议，希望这些建议对于读者的技术选型有所助益。

1) 数据量超千万，可以选择使用HBase

一般而言，如果单表的数据量只有百万的数量级或者更少，则不建议使用 HBase，而应该考虑关系数据库是否能够满足应用的需求。

如果单表数据量超过千万或者有十亿、百亿的数量级，并且伴有较高并发的存取应用，则可以考虑使用 HBase，这样可以充分利用分布式存储系统的优势。

2) 数据分析需求不多，可以选择使用HBase

虽然说 HBase 是一个面向列的数据库，但是它与真正的列式存储系统（比如 Parquet、Kudu等）又有所区别，再加上自身存储架构的设计，使得 HBase 并不擅长做数据分析。所以如果业务需求是为了做数据分析，比如做报表，那么不建议使用 HBase。

3) 实时根据主键查询，可以选择使用HBase

HBase 是一个 Key-Value 数据库，默认对 RowKey 做了索引优化，所以即使数据量非常庞大，根据 RowKey 查询的效率也会很高。但是，如果还需要根据其他条件进行查询，则不建议使用 HBase。

4) 多表连接查询，不建议使用HBase

HBase 是 NoSQL 产品中的一种，它也具有 NoSQL 的缺点，就是不能进行连表查询等操作，也就是说，如果业务场景是需要事务支持、复杂的关联查询，则不建议使用 HBase。

本文链接：http://task.lmcjl.com/news/14721.html