分布式存储学习——HBase概述

        经美国权威机构IDC调查发现，现如今的公司正在以前所未有的速度和丰富的类型产生数据，并且也有能力存储这些数据，但是，如何关联这两方面以便产生最大的商业价值，是所有公司共同面临的挑战。这个问题非常复杂：虽然业务人员在技能提升和专业工具的帮助下，越来越了解数据，但由于数据的增长速度越来越快，积累量级越来越大，公司可以利用的数据比例正在迅速下降。

1.1.1.1  什么是大数据

        Gartner认为与过去相关概念相比，大数据强调3V特征，即Volume（量级）、Varity（种类）、Velocity（速度）和Value（价值），如图 1.1.1所示。

图 1.1.1 大数据四大特性

        如今存储的数据量正在急剧增长，2000年全球存储了EB级别的数据，预计到2020年，该值将变为ZB级别。仅TWitter每天就会生成超过10TB的数据，Facebook的数据为几十TB，一些特殊的企业在每小时就会产生TB级别的数据。

        上面这些企业是一些典型的案例，其实我们生活的方方面面都会形成很多“轨迹”。例如，打开手机会生成一个事件；乘坐公共交通刷卡，这是一个事件；检票登机、打卡上班、App Store上购买应用、更换电视频道、使用高速路电子收费系统等。每一项操作都会生成数据，并且该数据的量级与参与的人数相关，全球60亿人口，如果仅仅1/10的人参与进来，那么这个数据量级就已经非常惊人。就在10年前IT界超过1TB的数据仓库屈指可数，而现在则是“举不胜举”。

        随着传感器、智能设备以及社交协作技术的激增，企业中的数据也变得更加复杂，因为它不仅包含传统的关系型数据，还包含来自网页、Web日志文件、社交媒体论坛、电子邮件、文档、传感器数据等原始、半结构化和非结构化数据。

        传统系统可能很难存储、分析这些数据的内容，更不要说挖掘有价值的信息。因为传统的数据库、数据仓库、联机事务处理等技术并不适合处理这些数据。尽管一些公司正在朝大数据方向大力发展，但总体而言，大部分公司只是刚开始理解大数据。当回首整个数据库发展的历程会发现，人们将大部分时间都花在仅20％的数据上：这些数据格式整齐且符合严格模式的关系类型。但事实是，全球80％的数据是非结构化的或者半结构化的。

        视频和图片不能轻松或高效地存储在关系型数据库中，某些事件信息可能动态地更改（如气象），它们不太适合严格的模式。要利用大数据，企业必须能够分析所有类型的数据，包括关系和非关系数据：文本、传感器数据、音频和视频等。

        有效处理大数据需要在数据变化的过程中对它的数量和种类进行分析，而不只是在“静止”状态进行分析。业界定义这种情况为从单纯批量计算模式到实时动态计算模式的内涵式转变。内涵式在这里也比较容易理解，即结构优化、质量提高，是一种实现实质性的跨越式的进程。大数据平台允许用户将所有数据存储为其原生的业务对象格式，通过可用组件上的大规模并行计算实现价值，不仅仅是批量处理和离线分析，同时支持实时查询和处理等特征，甚至要求响应时间在毫秒级别，并且可承受大规模的并发访问，这些都是“速度”特征的范畴。

1.1.1.2  为何大数据至关重要

        这种非传统分析是否适合企业的业务需求？换句话说就是能否找到一个大数据平台可为当前的分析工具提供补充实现，并且兼容现有解决方案，以实现更好的业务成果。

        通常情况下，数据必须经过清理才能规范地存放到数据仓库中。相反大数据解决方案不仅会利用不适合传统仓库且数量庞大的数据，而且不需要改变原有数据格式，保留了数据的真实性，并能够快速访问海量的信息。对于不能使用传统关系型数据库方法处理的信息所带来的挑战，大数据解决方案非常适合。大数据之所以重要，是因为其具备解决现实问题的三个关键方面。

• Ø  分析各种不同来源的结构化、半结构化和非结构化数据的理想选择。
• Ø  当需要分析所有或大部分数据，或者对一个数据抽样分析效果不明显时，大数据解决方案是理想的选择。
• Ø  未预先确定数据的业务度量指标时，是进行迭代式和探索式分析的理想选择。

1.1.1.3  NoSQL在大数据中扮演的角色

        NoSQL，是Not only SQL的缩写，泛指非关系型的数据库。与关系型数据库相比，NoSQL存在许多显著的不同点，其中最重要的是NoSQL不使用SQL作为查询语言。其数据存储可以不需要固定的表模式，也通常会避免使用SQL的JOIN操作，一般又都具备水平可扩展的特性。NoSQL的实现具有两个特征：使用硬盘和把随机存储器作存储载体。

1.  传统关系型数据库的缺陷

        随着互联网Web2.0的兴起，传统的关系数据库在应付Web2.0网站，特别是超大规模和高并发的SNS类型动态网站时已经力不从心，暴露了很多难以克服的问题。

(1)  高并发读写的瓶颈

        Web2.0网站要根据用户个性化信息来实时生成动态页面和提供动态信息，所以基本上无法使用静态化技术，因此数据库并发负载非常高，可能峰值会达到每秒上万次读写请求。关系型数据库勉强可以应付上万次SQL，但是应付上万次SQL写数据请求，硬盘I/O却无法承受。其实对于普通的BBS网站，往往也存在相对高并发写请求的需求，例如，人人网的实时统计在线用户状态，记录热门帖子的点击次数，投票计数等，这是一个相当普遍的业务需求。

(2)  可扩展性的限制

        在基于Web的架构中，数据库是最难以进行横向扩展的，当应用系统的用户量和访问量与日俱增时，数据库系统却无法像Web Server和APP Server那样简单地通过添加更多的硬件和服务节点来扩展性能和负载能力。对于很多需要提供24小时不间断服务的网站来说，对数据库系统进行升级和扩展是非常痛苦的事情，往往需要停机维护和数据迁移，而不能通过横向添加节点的方式实现无缝扩展。

(3)  事务一致性的负面影响

        事务执行的结果必须是使数据库从一个一致性状态变化到另一个一致性状态。保证数据库一致性是指当事务完成时，必须使所有数据都具有一致的状态。在关系型数据库中，所有的规则必须应用到事务的修改上，以便维护所有数据的完整性，这随之而来的是性能的大幅度下降。很多web系统并不需要严格的数据库事务，对读一致性的要求很低，有些场合对写一致性要求也不高。因此数据库事务管理成了高负载下的一个沉重负担。

(4)  复杂SQL查询的弱化

        任何大数据量的Web系统都非常忌讳几个大表间的关联查询， 以及复杂的数据分析类型的SQL查询，特别是SNS类型的网站，从需求以及产品设计角度就避免了这种情况的产生。更多的情况往往只是一单表的主键查询，以及单表的简单条件分页查询，SQL的功能被极大地弱化了，所以这部分功能不能得到充分发挥。

2.  NoSQL数据库的优势

(1)  扩展性强

        NoSQL数据库种类繁多，但是一个共同的特点就是去掉关系型数据库的关系特性，若数据之间是弱关系，则非常容易扩展。例如，HBase、Cassandra等系统的水平扩展性能非常优越，非常容易实现支撑数据从TB到PB级别的过渡。

(2)  并发性能好

        NoSQL数据库具有非常良好的读写性能， 尤其在大数据量下，同样表现优秀。这得益于它的弱关系性，数据库的结构简单。一般MySQL使用QueryCache，每当表发生更新操作时，Cache就会失效，这是一种大粒度的Cache，在针对Web2.0的交互中频繁应用，Cache性能并不高。而NoSQL的Cache是记录级的，是一种细粒度的Cache，所以NoSQL在这个层面上来说性能要高很多。

(3)  数据模型灵活

        NoSQL无须事先为要存储的数据建立字段，随时可以存储自定义的数据格式。而在关系型数据库中，增删字段是一件非常麻烦的事情。对于数据量非常大的表，增加字段简直就是一场噩梦。NoSQL允许使用者随时随地添加字段，并且字段类型可以是任意格式。HBase作为NoSQL数据库的一种，当然也具备上面提到的种种优势。使用过Hadoop的读者知道，Hadoop最适合的应用场景是离线批量处理数据，其离线分析的效率非常高，能在分钟级别处理TB级的数据，但是一般的应用系统并不适合批量模式访问，更多的还是用户的随机访问，就类似访问关系型数据库中的某条记录一样。HBase的列式存储的特性支撑它实时随机读取、基于KEY的特殊访问需求。当然，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的发展历史、发行版本和特性。

1.1.2.1  HBase的发展历史

        Apache HBase最初是Powerset公司为了处理自然语言搜索产生的海量数据而开展的项目，由Chad Walters和Jim Kellerman两人发起，经过两年的发展之后被Apache基金会收录为顶级项目，同时成为非常活跃、影响重大的项目。

        2006年11月， Google开放了论文“Bigtable:A Distributed Storage System for structured Data"，该论文就是HBase的原型。2007年2月，倡导者提出作为Hadoop的模块的HBase原型，该原型包含HBase的基本介绍、表设计、行键设计和底层数据存储结构设计等内容。

        经过一段时间的酝酿和开发工作，在2007年10月第一个可用的、简单的HBase版本发布，该版本只实现了最基本的模块和功能，因为只是初始开发阶段，此时的HBase版本发展很不完善。2008年1月，Hadoop升级为顶级项目，HBase作为Hadoop的一个子项目存在，HBase的活跃度非常高，在短短不到2年的时间经历了N多个版本的发布，并且其中包含了版本号的大“跳跃”。下面是一些版本发布的信息：

• Ø  HBase-0.18.0于2008年9月21日发布
• Ø  HBase-0.20.6于2010年7月10日发布
• Ø  HBase-0.89.20100621于2010年6月25日发布

        其中，从HBase-0.20.6到HBase-0.89.20100621版本，经历了版本的大“跳跃”。在2009年秋季发布0.20系列版本后，HBase经历了发展历史上的一次版本大变动，在此之前的版本都追随Hadoop的主版本，例如，HBase 0.X.＊版本都会伴随着Hadoop 0.X.＊版本，之所以出现版本跳跃，官方给出的解释有两点。

• Ø  Hadoop的版本更新已经放缓，而HBase相比Hadoop开发来讲更加活跃，发布版本更加频繁，并且Hadoop已经有多个分支，HBase也需要兼容多个分支，所以不再需要与Hadoop的版本更新步伐保持一致。
• Ø  从HBase的功能实现上来讲，已经基本实现BigTable论文中实现的功能，也就是HBase的实现已经接近“1.0"，应该赋予一个更接近“1.0”的版本。

        “跳跃”之后的版本发布比较规律，先后经历了0.90.＊、0.92.＊、0.94.＊、0.96.＊、0.98.*、1.0.*、1.1*七个大的版本，现在稳定版本是1.0.1.1。

1.1.2.2  HBase的发行版本

        本节主要介绍现有HBase的版本知识，从0.90.0之后，HBase的版本更新是非常有规律的，可以从0.90.0、0.91.0、0.92.0、0.93.0、0.94.0、0.95.0、0.96.0、0.97.0、0.98.0、0.99.0、1.0.0、1.1.0这样的版本变化中发现一些规律。

        这些版本都是大版本，其中偶数版本是稳定发布版，而奇数版本都是开发版，基本不对外发布，但是可以在官方JIRA的项目管理系统中找到这些奇数版本对应的开发信息，并且可以在SVN上找到相关的最新开发代码。所以，偶数发布版本属于稳定版本，奇数开发版本属于不稳定版本，一般不建议用户在生产环境中使用开发版本，这些也是大版本的发布规律。

        小版本一般基于当前大版本的问题进行修正，一般表示小版本的数字在1-100之间，例如： 0.98.1、0.98.2、0.98.3、0.98.4。这些小版本都是基于0.98大版本的，截止到本书撰写时，最新版本是1.1.1。小版本都是从小到大依次递增，不存在版本跳跃的情况。对于小版本而言，原则上数值越大越稳定，因为小版本都是基于某一个大版本的，在小版本中并不会增加新特征，而是修正一些代码的漏洞和问题。

        截止到本书完稿时，HBase官方给出的最新版本信息如下面的代码所示。从中可以看出，发布版本存在0.94、0.96、0.98、1.0、1.1几个大版本。其中stable文件夹包含了最新的稳定发布版本； HEADER.html文件用于对代码发行版进行说明，即下面代码中的前半部分，从“HBase Releases…”开始，一直到“’fresh’.”结束的解释说明。每部分后面都有对应的发布时间，可以通过该时间判断版本发布的间隔和项目的活跃程度。

HBase Releases

Please make sure you're downloading from a nearby mirror site, not from www.apache.org.

We suggest downloading the current stable release.

The 1.0.x series is the current stable release line, it supercedes 0.98.x and 0.94.x (the 0.98.x and 0.94.x lines are still seeing a monthly cadence of bug fix releases for those who are not easily able to update). Note that 0.96 was EOL'd September 1st, 2014. Use 1.0.x instead.

HBase最新版本，如表 1.1.1所示：

        Stable文件夹存放的是最新的稳定发布版本，从下面的代码中可以看到最新的稳定版本信息，其中发布版本包含文件名字、文件大小和发布日期等参数。

File Name                          File Size                Date

HBase-1.0.1.1-bin.tar.gz               95869521          21-May-2015 18:01

HBase-1.0.1.1-bin.tar.gz.mds              1133           21-May-2015 18:01

HBase-1.0.1.1-src.tar.gz               13701870          21-May-2015 18:01

HBase-1.0.1.1-src.tar.gz.mds               1133          21-May-2015 18:01

        这里不建议使用非稳定版本,因为很多的新功能并没有经过工业界的验证。需要特别声明一下，本书的知识点讲解、安装部署、实战案例和性能调优等都是基于HBase-1.0.1.1版本的，该版本是写作本书时的最新稳定版。

1.1.2.3  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参考了Google的BigTable建模，且将下面三篇博文作为HBase实现的理论基础：

• Ø  BigTable by Google (2006)
• Ø  HBase and HDFS Locality by Lars George (2010)
• Ø  No Relation:The Mixed Blessings of Non-Relational Databases by Ian Varley (2009)

        从上面的博文列表中也可以看出，HBase和HDFS有着非常紧密的关系，更准确的说法是：HBase严重依赖Hadoop的HDFS组件，HBase使用HDFS作为底层存储系统。因此，如果要使用HBase，前提是首先必须有Hadoop系统。从后面第2节的HBase安装过程的讲解中也可以总结出这点。Hadoop的组件之一MapReduce可以直接访问HBase，但是，这不是必需的，因为HBase中最重要的访问方式是原生Java API，而不是MapReduce这样的批量操作方式。图1.1.2展示了HBase在Hadoop生态系统中的位置。

图1.1.2 Hadoop生态系统总图

        因为HBase底层依赖Hadoop，所以选择Hadoop版本对HBase部署很关键。表 1.1.2显示了不同HBase发行版本所支持的Hadoop版本信息。基于HBase版本，应该选择合适的Hadoop版本，表 1.1.2是官方给出的HBase和Hadoop的版本支持矩阵。

表 1.1.2 Hadoop版本支持矩阵

表 1.1.2中字母的含义如下。

• Ø  S：经过测试的、支持的。
• Ø  X：不支持。
• Ø  NT：可以运行但测试不充分。

当然，并不是说只要满足表 1.1.2中的版本匹配就可以了，在考虑版本匹配的同时也需要考虑一些其他因素，例如：

1. Ø  对于ZooKeeper的版本只需要跟HBase依赖库中的ZooKeeper保持一致即可。

        Hadoop框架包含两个核心组件：HDFS和MapReduce，其中HDFS是文件存储系统，负责数据存储；MapReduce是计算框架，负责数据计算。它们之间分工明确、低度耦合、相关关联。对于HBase数据库的核心组件，即核心功能模块共有4个，它们分别是：客户端Client、协调服务模块ZooKeeper、主节点HMaster和Region节点RegionServer，这些组件相互之间的关联关系如图 1.1.3所示。

图 1.1.3  HBase架构图

1.1.4.1  客户端Client

        客户端Client是整个HBase系统的入口。使用者直接通过客户端操作HBase。客户端使用HBase的RPC机制与HMaster和RegionServer进行通信。对于管理类操作，Client与HMaster进行RPC通信；对于数据读写类操作，Client与RegionServer进行RPC交互。这里客户端可以是多个，并不限定是原生Java接口，还有Thrift、Avro、Rest等客户端模式，甚至MapReduce也可以算作一种客户端。

1.1.4.2  协调服务组件ZooKeeper

        ZooKeeper Quorum（队列）负责管理HBase中多HMaster的选举、服务器之间状态同步等。再具体一些就是，HBase中ZooKeeper实例负责的协调工作有：存储HBase元数据信息、实时监控Regionserver、存储所有Region的寻址入口，当然还有最常见的功能就是保证HBase集群中只有一个HMaster节点。

1.1.4.3  主节点HMaster

        HMaster没有单点问题，在HBase中可以启动多个HMaster，通过ZooKeeper的Master选举机制保证总有一个Master正常运行并提供服务，其他HMaster作为备选时刻准备（当目前HMaster出现问题时）提供服务。HMaster主要负责Table和Region的管理工作：

• Ø  管理用户对Table的增、删、改、查操作。
• Ø  管理RegionServer的负载均衡，调整Region分布。
• Ø  在Region分裂后，负责新Region的分配。
• Ø  在RegionServer死机后，负责失效RegionServer上的Region迁移。

1.1.4.4  Region节点HRegionServer

        HRegionServer主要负责响应用户I/O请求，向HDFS文件系统中读写数据，是HBase中最核心的模块。HRegion内部管理了一系列HRegion对象，每个HRegion对应了Table中的一个Region。HRegion由多个HStore组成, 每个HStore对应了Table中的一个Column Family的存储。可以看出每个Column Family其实就是一个集中的存储单元，因此最好将具备共同I/O特性的列放在一个column Family中，这样能保证读写的高效性。HRegionServer的组成结构如图 1.1.4所示。

        如图 1.1.4所示，HStore存储是HBase存储的核心，由两部分组成：MemStore和StoreFile。Memstore是Sorted Memory Buffer，用户写入的数据首先会放入MemStore中，当MemStore满了以后会缓冲（flush）成一个StoreFile（底层实现是HFile)，当StoreFile文件数量增长到一定阈值，会触发Compact操作，将多个StoreFiles合并成一个StoreFile，在合并过程中会进行版本合并和数据删除，因此可以看出HBase其实只有增加数据，所有的更新和删除操作都是在后续的Compact过程中进行的，这使得用户的写操作只要进入内存中就可以立即返回，保证了HBase I/O的高性能。

图 1.1.4 HRegionServer的组成结构

        StoreFiles在触发Compact操作后，会逐步形成越来越大的StoreFile，当单个StoreFile大小超过一定阈值后，会触发Split操作，同时把当前Region分裂成2个Region，父Region会下线，新分裂的2个子Region会被HMaster分配到相应的HRegionServer上，使得原先1个Region的压力得以分流到2个Region上。

        每个HRegionServer中都有一个HLog对象，HLog是一个实现Write Ahead Log的类，在每次用户操作写入MemStore的同时，也会写一份数据到HLog文件中，HLog文件定期会滚动出新，并删除旧的文件（已持久化到StoreFile中的数据）。在HRegionServer意外终止后，HMaster会通过ZooKeeper感知到，首先处理遗留的HLog文件，将其中不同Region的Log数据进行拆分，分别放到相应Region的目录下，然后再将失效的Region重新分配，领取到这些Region的HRegionServer在加载Region的过程中， 会发现有历史HLog需要处理，因此会将HLog中的数据回放到MemStore中，然后缓冲（flush）到StoreFiles，完成数据恢复。

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

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

• Ø  存储大量的数据（PB级数据）且能保证良好的随机访问性能。
• Ø  需要很高的写吞吐量，瞬间写入量很大，传统数据库不能支撑或需要很高成本支撑的场景。
• Ø  可以进行优雅的数据扩展，动态扩展整个存储系统容量。
• Ø  数据格式无限制，支持半结构化和非结构化的数据。
• Ø  业务场景简单，不需要全部的关系型数据库特性，例如交叉列、交叉表，事务、连接等。

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

1.1.5.1  搜索引擎应用

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

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

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

1.  爬虫持续不断地抓取新页面存储到HBase中；
2. 在整张表上使用MapReduce计算并生成索引，供网络搜索应用使用；
3.  用户发起网络搜索请求；
4.  网络搜索应用查询建立好的索引，或者直接从HBase得到单个文档；
5.  搜索结果提交给用户。

1.1.5.2  增量数据存储

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

• Ø  增量监控数据：OpenTSDB系统

        如果一款Web产品的注册用户达到千万，则后台的基础架构需要数百台以上的服务器，用于承担服务流量、日志收集、数据存储和数据处理等操作。为了保持产品正常运行，监控服务器和其中运行软件的健康状态至关重要。大规模监控整个环境需要能够采集和存储来自不同数据源的各种参数的监控系统。一些公司使用商业工具来收集和展示参数，而其他一些公司采用开源框架。StumbleUpon开源了OpenTSDB框架，其含义是开放时间序列数据库（Open Time Series Database)，用来收集服务器的各种监控参数。该框架使用HBase作为核心平台来存储和检索所收集的参数。创建这个框架的目的是为了拥有一个可扩展的监控数据收集系统，一方面能够存储和检索参数数据并保存很长时间，另一方面如果需要增加功能也可以随时添加各种新参数。

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

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

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

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

        软件运行和质量数据，不会像监控参数数据那么简单。例如，软件崩溃报告是有用的软件运行数据，经常用来探究软件质量和规划软件开发路线图。HBase可以成功地收集和存储用户计算机上生成的软件崩溃报告。这种使用场景与前两种使用场景不同，不一定与网络服务应用有关系。Mozilla最出色的软件就是Firefox浏览器，该软件安装在全球数千万量级的个人计算机上，支持各种操作系统。当浏览器出现异常或者崩溃时，会以Bug报告的形式返回给Mozilla后台服务器。Mozilla后台使用Socorro系统收集这些报告，该系统的数据存储和分析建构在HBase上，分析结果用于向研发部门提供建议和决策支持。采用HBase可以存储更多的数据，使得分析结果更加准确，可以在更大程度上帮助和指导开发人员。

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

        现今，在线广告已经成为互联网产品的一个主要收入来源。绝大部分的互联网产品提供免费服务给用户，在用户使用服务时投放广告给目标用户。这种精准投放需要针对用户交互数据做详细的采集和分析，以便理解用户的特征。精细的用户交互数据带来更好的模型，进而导致更好的广告投放效果和更多的收入。但这类数据有两个特点：以连续流的形式出现、很容易按用户划分。在理想情况下，这种数据一旦产生就能够马上使用，用户特征模型可以没有延迟地持续优化。国内的电商和广告监控等非常前沿、活跃的互联网公司已经在熟练地使用类似Hadoop和HBase这样的新技术，例如淘宝的实时个性化推荐服务，中间推荐结果的存储使用HBase， 并且广告相关的用户建模数据也存储在HBase中。广告监控行业中的AdMaster、缔元信等公司的实时广告数据监控和部分报表业务已经在使用HBase。

1.1.5.3  用户内容服务

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

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

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

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

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

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

1.1.5.4  实时消息系统构建

        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的“大客户”，基于这点，我们也有充足理由相信它能变得更加流行。

        本节主要介绍了HBase上下文相关的知识，包括大数据背景、HBase的发展历史、发行版本、特性、核心功能模块以及使用场景和经典案例等知识点，并且详细介绍了HBase是什么和HBase能做什么两个要点，方便学生快速理解和掌握HBase框架。任何一种框架或者软件都有其特定的应用场景，类似“万金油”的框架是10年前大家追求的设计理念，所以HBase有其特定的使用场景。通过本节学习，学生可以迅速掌握HBase能用来做什么，不能用来做什么，最大程度上缩短学生的学习和使用成本。