1.5 HBase的使用场景和经典案例
了解软件产品的最好方法是如何使用，解决什么问题以及如何适用于大型应用架构。接下来的内容将详细介绍一些业界成功使用HBase的场景。但是，不要认为HBase只能解决下面的这些使用场景，因为它是一个正在发展和完善的技术框架，根据使用场景进行的创新正驱动着系统的发展。
下面是对HBase适用场景的一些抽象概括，从需求角度进行抽象，涵盖存储量级、性能、扩展、数据格式和关联关系等方面。
存储大量的数据（PB级数据）且能保证良好的随机访问性能。
需要很高的写吞吐量，瞬间写入量很大，传统数据库不能支撑或需要很高成本支撑的场景。
可以进行优雅的数据扩展，动态扩展整个存储系统容量。
数据格式无限制，支持半结构化和非结构化的数据。
业务场景简单，不需要全部的关系型数据库特性，例如交叉列、交叉表，事务、连接等。
愿意使用HBase的用户数量在过去几年里迅猛增长，部分原因在于HBase产品变得更加可靠，性能变得更好，主要原因在于越来越多的公司开始投入大量资源来支持和使用它。随着越来越多的商业服务供应商提供支持，用户越发自信地把HBase应用于关键应用系统。一个设计初衷是存储互联网持续更新网页副本的技术，用在互联网相关的其他方面也很合适。下面涉及通过实际案例来介绍HBase最适合的应用场景。
1.5.1 搜索引擎应用
搜索是定位用户感兴趣信息的行为：例如，搜索“大话西游”，用户可能非常想观看这部电影，或者想了解这部电影的信息。搜索含有特定词语的文档，需要查找索引，该索引提供了特定词语和包含该词语的所有文档的映射。为了能够搜索，首先必须建立索引。Google、百度以及其他搜索引擎都是这么做的。它们的文档库是互联网的Web页面。
HBase为这种文档库提供存储、行级访问。网络爬虫可以基于HBase非常方便地插入和更新单个文档。同时搜索索引可以基于HBase通过MapReduce计算高效生成。如果访问单个文档，可以直接从HBase取出（即随机读取），并且HBase支持多种访问模式。
HBase应用于网络搜索的整个逻辑过程如下：
1）爬虫持续不断地抓取新页面存储到HBase中；
2）在整张表上使用MapReduce计算并生成索引，供网络搜索应用使用；
3）用户发起网络搜索请求；
4）网络搜索应用查询建立好的索引，或者直接从HBase得到单个文档；
5）搜索结果提交给用户。
1.5.2 增量数据存储
在大多数情况下，数据通常是慢慢累加到已有数据库以备将来使用，例如分析、处理和服务。许多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.5.3 用户内容服务
传统数据库的一个最大使用场合是为用户提供内容服务。各种各样的数据库支撑着提供各种内容服务的应用系统。多年来，这些应用在发展，它们所依赖的数据库也在发展。用户希望使用和交互的内容种类越来越多。
1.?内容推荐引擎系统：搜狐
搜狐推荐引擎系统接入几亿用户的行为日志，每日资讯量在百万级，每秒约有几万条左右的用户日志被实时处理入库。在这种数据量上，要求推荐请求和相关新闻请求每秒支持的访问次数在万次以上，推荐请求的响应延时控制在70ms以内，同时系统要求10s左右完成从日志到用户模型的修正过程。
这些性能需求指标是整个系统的难点，需要维护几亿用户200GB的短期属性信息，同时依靠这些随用户行为实时变化的属性信息来更新用户感兴趣的文章主题，还要实时计算用户所属的兴趣小组，完成由短期兴趣主导的内容推荐和用户组协同推荐。记录用户浏览历史、周期性计算热门文章等都是在HBase上完成的，由此可见HBase在高性能上的优势。
2.?用户模型服务：电商行业
经过HBase处理过的内容往往并不直接提交给用户使用，而是用来丰富与用户的交互，具体是决定应该提交给用户什么内容。用户模型可以存储在HBase，用户模型多种多样，可以用于多种不同场景，例如，针对特定用户投放什么广告，用户在电商门户网站购物时是否实时报价，用户在搜索引擎检索时增加背景信息和关联内容，等等。当用户在电商网站上发生交易时，用户模型服务可以用来实时报价。这种模型需要基于不断产生的新用户数据来持续优化。
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的“大客户”，基于这点，我们也有充足理由相信它能变得更加流行。