6.1 HBase介绍

HBase（Hadoop Database）是一个高可靠、高性能、面向列、可伸缩的分布式数据库，利用HBase技术可在廉价PC上搭建起大规模结构化存储集群。HBase参考Google的BigTable建模，使用类似GFS的HDFS作为底层文件存储系统，在其上可以运行MapReduce批量处理数据，使用ZooKeeper作为协同服务组件。

HBase的整个项目使用Java语言实现，它是Apache基金会的Hadoop项目的一部分，既是模仿Google BigTable的开源产品，同时又是Hadoop的衍生产品。而Hadoop作为批量离线计算系统已经得到了业界的普遍认可，并经过了工业上的验证，所以HBase具备“站在巨人肩膀之上”的优势，其发展势头非常迅猛。

HBase还是一种非关系型数据库，即NoSQL数据库。在Eric Brewer的CAP理论中，HBase属于CP类型的系统，其NoSQL的特性非常明显，这些特性也决定了其独特的应用场景。接下来的内容将详细讲解HBase的发展历史、发行版本和特性。

HBase 特性

HBase作为一个典型的NoSQL数据库，可以通过行键（Rowkey）检索数据，仅支持单行事务，主要用于存储非结构化和半结构化的松散数据。与Hadoop相同，HBase设计目标主要依靠横向扩展，通过不断增加廉价的商用服务器来增加计算和存储能力。

“典型”代表着HBase有不少特性，这些特性都标志着HBase的特立独行、与众不同，同时其良好的出身和特性也奠定了其在大数据处理领域的地位。下面介绍HBase具备的一些非常显著的特点。

1.容量巨大

HBase的单表可以有百亿行、百万列，数据矩阵横向和纵向两个维度所支持的数据量级都非常具有弹性。传统的关系型数据库，如Oracle和MySQL等，如果数据记录在亿级别，查询和写入的性能都会呈指数级下降，所以更大的数据量级对传统数据库来讲是一种灾难。而HBase对于存储百亿、千亿甚至更多的数据都不存在任何问题。对于高维数据，百万量级的列没有任何问题。有的读者可能关心更加多的列：千万和亿级别，这种非常特殊的应用场景，并不是说HBase不支持，而是这种情况下访问单个Rowkey可能造成访问超时，如果限定某个列则不会出现这种问题。

2.面向列

HBase是面向列的存储和权限控制，并支持列独立检索。有些读者可能不清楚什么是列式存储，下面进行简单介绍。列式存储不同于传统的关系型数据库，其数据在表中是按某列存储的，这样在查询只需要少数几个字段的时候，能大大减少读取的数据量，比如一个字段的数据聚集存储，那就更容易为这种聚集存储设计更好的压缩和解压算法。

传统行式数据库的特性如下：

数据是按行存储的。

没有索引的查询使用大量I/O。

建立索引和物化视图需要花费大量的时间和资源。

面对查询需求，数据库必须被大量膨胀才能满足需求。

列式数据库的特性如下：

数据按列存储，即每一列单独存放。

数据即索引。

只访问查询涉及的列，可以大量降低系统I/O。

每一列由一个线索来处理，即查询的并发处理性能高。

数据类型一致，数据特征相似，可以高效压缩。

列式存储不但解决了数据稀疏性问题，最大程度上节省存储开销，而且在查询发生时，仅检索查询涉及的列，能够大量降低磁盘I/O。这些特性也支撑HBase能够保证一定的读写性能。

3.稀疏性

在大多数情况下，采用传统行式存储的数据往往是稀疏的，即存在大量为空（NULL）的列，而这些列都是占用存储空间的，这就造成存储空间的浪费。对于HBase来讲，为空的列并不占用存储空间，因此，表可以设计得非常稀疏。

4.扩展性

HBase底层文件存储依赖HDFS，从“基因”上决定了其具备可扩展性。这种遗传的可扩展性就如同OOP中的继承，“父类”HDFS的扩展性遗传到HBase框架中。这是最底层的关键点。同时，HBase的Region和RegionServer的概念对应的数据可以分区，分区后数据可以位于不同的机器上，所以在HBase核心架构层面也具备可扩展性。HBase的扩展性是热扩展，在不停止现有服务的前提下，可以随时添加或者减少节点。

5.高可靠性

HBase提供WAL和Replication机制。前者保证了数据写入时不会因集群异常而导致写入数据的丢失；后者保证了在集群出现严重问题时，数据不会发生丢失或者损坏。而且HBase底层使用HDFS，HDFS本身的副本机制很大程度上保证了HBase的高可靠性。同时，协调服务的ZooKeeper组件是经过工业验证的，具备高可用性和高可靠性。

6.高性能

底层的LSM数据结构和Rowkey有序排列等架构上的独特设计，使得HBase具备非常高的写入性能。Region切分、主键索引和缓存机制使得HBase在海量数据下具备一定的随机读取性能，该性能针对Rowkey的查询能够达到毫秒级别。同时，HBase对于高并发的场景也具备很好的适应能力。该特性也是业界众多公司选取HBase作为存储数据库非常重要的一点。

HBase的使用场景和经典案例

了解软件产品的最好方法是如何使用，解决什么问题以及如何适用于大型应用架构。接下来的内容将详细介绍一些业界成功使用HBase的场景。但是，不要认为HBase只能解决下面的这些使用场景，因为它是一个正在发展和完善的技术框架，根据使用场景进行的创新正驱动着系统的发展。

下面是对HBase适用场景的一些抽象概括，从需求角度进行抽象，涵盖存储量级、性能、扩展、数据格式和关联关系等方面。

存储大量的数据（PB级数据）且能保证良好的随机访问性能。

需要很高的写吞吐量，瞬间写入量很大，传统数据库不能支撑或需要很高成本支撑的场景。

可以进行优雅的数据扩展，动态扩展整个存储系统容量。

数据格式无限制，支持半结构化和非结构化的数据。

业务场景简单，不需要全部的关系型数据库特性，例如交叉列、交叉表，事务、连接等。

愿意使用HBase的用户数量在过去几年里迅猛增长，部分原因在于HBase产品变得更加可靠，性能变得更好，主要原因在于越来越多的公司开始投入大量资源来支持和使用它。随着越来越多的商业服务供应商提供支持，用户越发自信地把HBase应用于关键应用系统。一个设计初衷是存储互联网持续更新网页副本的技术，用在互联网相关的其他方面也很合适。下面涉及通过实际案例来介绍HBase最适合的应用场景。

• 搜索引擎应用

搜索是定位用户感兴趣信息的行为：例如，搜索“大话西游”，用户可能非常想观看这部电影，或者想了解这部电影的信息。搜索含有特定词语的文档，需要查找索引，该索引提供了特定词语和包含该词语的所有文档的映射。为了能够搜索，首先必须建立索引。Google、百度以及其他搜索引擎都是这么做的。它们的文档库是互联网的Web页面。

HBase为这种文档库提供存储、行级访问。网络爬虫可以基于HBase非常方便地插入和更新单个文档。同时搜索索引可以基于HBase通过MapReduce计算高效生成。如果访问单个文档，可以直接从HBase取出（即随机读取），并且HBase支持多种访问模式。

HBase应用于网络搜索的整个逻辑过程如下：

1）爬虫持续不断地抓取新页面存储到HBase中；

2）在整张表上使用MapReduce计算并生成索引，供网络搜索应用使用；

3）用户发起网络搜索请求；

4）网络搜索应用查询建立好的索引，或者直接从HBase得到单个文档；

5）搜索结果提交给用户。

• 增量数据存储

在大多数情况下，数据通常是慢慢累加到已有数据库以备将来使用，例如分析、处理和服务。许多HBase使用场景属于这个类别——使用HBase作为数据存储，存储来自各种数据源的增量数据。这种数据源可能是网页爬虫，可能是记录用户看了什么广告和看多长时间的广告效果数据，也可能是记录各种参数的时间序列数据。下面介绍一些有关该使用场景的成功案例。

1.增量监控数据：OpenTSDB系统

如果一款Web产品的注册用户达到千万，则后台的基础架构需要数百台以上的服务器，用于承担服务流量、日志收集、数据存储和数据处理等操作。为了保持产品正常运行，监控服务器和其中运行软件的健康状态至关重要。大规模监控整个环境需要能够采集和存储来自不同数据源的各种参数的监控系统。一些公司使用商业工具来收集和展示参数，而其他一些公司采用开源框架。

StumbleUpon开源了OpenTSDB框架，其含义是开放时间序列数据库（Open Time Series Database），用来收集服务器的各种监控参数。该框架使用HBase作为核心平台来存储和检索所收集的参数。创建这个框架的目的是为了拥有一个可扩展的监控数据收集系统，一方面能够存储和检索参数数据并保存很长时间，另一方面如果需要增加功能也可以随时添加各种新参数。

2.增量用户交互数据：Facebook Like按钮

用过Facebook的读者，应该记得其特有的Like按钮，该按钮已经成为Facebook的标志之一，每次用户喜欢一个特定主题时，计数器就增加一次。这里的计数器是一个整数类型的变量，每次触发喜欢操作就加1。这就是另外一种增量数据——用户交互数据。

Facebook使用HBase的计数器来计量用户喜欢特定网页的次数，内容原创人和页面所有者可以得到近乎实时的多少用户喜欢他们网页的数据信息。他们可以因此更敏捷地判断应该提供什么内容。Facebook为此创建了一个叫Facebook Insight的系统，该系统需要一个可扩展的存储系统。在技术选型的时候考虑了很多种可能，包括关系型数据库、内存数据库和Cassandra数据库，最后决定使用HBase。基于HBase，Facebook可以很方便地横向扩展服务规模，提供给数百万用户，也可以继续使用他们已有的运行大规模HBase集群的经验。该系统每天处理数百亿条事件，记录数百个参数。

3.增量遥测数据：Firefox浏览器

软件运行和质量数据，不会像监控参数数据那么简单。例如，软件崩溃报告是有用的软件运行数据，经常用来探究软件质量和规划软件开发路线图。HBase可以成功地收集和存储用户计算机上生成的软件崩溃报告。这种使用场景与前两种使用场景不同，不一定与网络服务应用有关系。

Mozilla最出色的软件就是Firefox浏览器，该软件安装在全球数千万量级的个人计算机上，支持各种操作系统。当浏览器出现异常或者崩溃时，会以Bug报告的形式返回给Mozilla后台服务器。Mozilla后台使用Socorro系统收集这些报告，该系统的数据存储和分析建构在HBase上，分析结果用于向研发部门提供建议和决策支持。采用HBase可以存储更多的数据，使得分析结果更加准确，可以在更大程度上帮助和指导开发人员。

4.增量广告点击数据：电商、广告监控行业

现今，在线广告已经成为互联网产品的一个主要收入来源。绝大部分的互联网产品提供免费服务给用户，在用户使用服务时投放广告给目标用户。这种精准投放需要针对用户交互数据做详细的采集和分析，以便理解用户的特征。精细的用户交互数据带来更好的模型，进而导致更好的广告投放效果和更多的收入。但这类数据有两个特点：以连续流的形式出现、很容易按用户划分。在理想情况下，这种数据一旦产生就能够马上使用，用户特征模型可以没有延迟地持续优化。

国内的电商和广告监控等非常前沿、活跃的互联网公司已经在熟练地使用类似Hadoop和HBase这样的新技术，例如淘宝的实时个性化推荐服务，中间推荐结果的存储使用HBase，并且广告相关的用户建模数据也存储在HBase中。广告监控行业中的AdMaster、缔元信等公司的实时广告数据监控和部分报表业务已经在使用HBase。

• 用户内容服务

传统数据库的一个最大使用场合是为用户提供内容服务。各种各样的数据库支撑着提供各种内容服务的应用系统。多年来，这些应用在发展，它们所依赖的数据库也在发展。用户希望使用和交互的内容种类越来越多。

1.内容推荐引擎系统：搜狐

搜狐推荐引擎系统接入几亿用户的行为日志，每日资讯量在百万级，每秒约有几万条左右的用户日志被实时处理入库。在这种数据量上，要求推荐请求和相关新闻请求每秒支持的访问次数在万次以上，推荐请求的响应延时控制在70ms以内，同时系统要求10s左右完成从日志到用户模型的修正过程。

这些性能需求指标是整个系统的难点，需要维护几亿用户200GB的短期属性信息，同时依靠这些随用户行为实时变化的属性信息来更新用户感兴趣的文章主题，还要实时计算用户所属的兴趣小组，完成由短期兴趣主导的内容推荐和用户组协同推荐。记录用户浏览历史、周期性计算热门文章等都是在HBase上完成的，由此可见HBase在高性能上的优势。

2.用户模型服务：电商行业

经过HBase处理过的内容往往并不直接提交给用户使用，而是用来丰富与用户的交互，具体是决定应该提交给用户什么内容。用户模型可以存储在HBase，用户模型多种多样，可以用于多种不同场景，例如，针对特定用户投放什么广告，用户在电商门户网站购物时是否实时报价，用户在搜索引擎检索时增加背景信息和关联内容，等等。当用户在电商网站上发生交易时，用户模型服务可以用来实时报价。这种模型需要基于不断产生的新用户数据来持续优化。

• 实时消息系统构建

Facebook全新的Social Inbox产品，集成了E-mail、IM、短信、文本信息、在线消息。最为重要的是，该产品每个月要存储超过1350亿条消息。Facebook的Kannan Muthukkaruppan在《邮件的底层技术：HBase》一文中给了一个十分意外的答案——HBase打败了MySQL、Cassandra和其他一些技术，成为Facebook的选择。为什么说是一个意外的答案？Cassandra是Facebook创造的，并且它就是为邮件类型的应用而打造的，但是Facebook发现Cassandra的最终一致性模型并不适合其全新的实时邮件产品。Facebook同样拥有大量的MySQL架构，但是在使用过程中发现MySQL性能会随着数据和索引的增加变差。所以，Facebook同样可以选择自己来开发一个新的存储模型，但是最终选择了HBase。

Facebook检视了自己的应用场景，指出为什么要选择HBase。Facebook所需要的系统应该能处理以下两种数据：

一个较小的临时数据集，是经常变化的；

一个不断增加的数据集，是很少被访问的。

显然HBase就能搞定这一切。Facebook在Hadoop、Hive上积累了丰富的经验，并且成为HBase的“大客户”，基于这点，我们也有充足理由相信它能变得更加流行。