1.2　HBase使用场景和成功案例 - 异步社区

1.2　HBase使用场景和成功案例

有时候了解软件产品的最好方法是看看它是怎么用的。它可以解决什么问题和这些解决方案如何适用于大型应用架构，这些能够告诉你很多。因为HBase有许多公开的产品部署案例，我们正好可以这么做。本节将详细介绍一些成功使用HBase的使用场景。

注意

不要自我限制，认为HBase只能在这些使用场景下使用。它是一个很新的技术，根据使用场景进行的创新正推动着该系统的发展。如果你有新想法，认为HBase提供的功能会让你受益，那就试试吧。社区很乐于帮助你，也会从你的经验中学习。这正是开源软件精神。

HBase模仿了Google的BigTable，让我们先从典型的BigTable问题开始：存储互联网。

1.2.1　典型的互联网搜索问题：BigTable发明的原因

搜索是一种定位你所关心信息的行为。例如，搜索一本书的页码，其中含有你想读的主题，或者搜索网页，其中含有你想找的信息。搜索含有特定词语的文档，需要查找索引，该索引提供了特定词语和包含该词语的所有文档的映射。为了能够搜索，首先必须建立索引。Google和其他搜索引擎正是这么做的。它们的文档库是整个互联网，搜索的特定词语就是你在搜索框里敲入的任何东西。

BigTable和模仿出来的HBase，为这种文档库提供存储，BigTable提供行级访问，所以爬虫可以插入和更新单个文档。搜索索引可以基于BigTable通过MapReduce计算高效生成。如果结果是单个文档，可以直接从BigTable取出。支持各种访问模式是影响BigTable设计的关键因素。图1-1显示了互联网搜索应用中BigTable的关键角色。

图1-1 使用BigTable提供网络搜索结果，非常简单。爬虫收集网页，存储到BigTable里；

MapReduce计算作业扫描全表生成搜索索引；从Bigtable中查询搜索结果，展示给用户

注意

为简洁起见，这里不做BigTable原作者判定。我们强烈推荐关于Google File System、MapReduce和BigTable三大论文，如果你对这些技术感到好奇，这是必读读物。你不会失望的。

讲完典型HBase使用场景以后，我们来看看其他使用HBase的地方。愿意使用HBase的用户数量在过去几年里迅猛增长。部分原因在于HBase产品变得更加可靠且性能变得更好，更多原因在于越来越多的公司开始投入大量资源来支持和使用它。随着越来越多的商业服务供应商提供支持，用户越发自信地把HBase应用于关键应用系统。一个设计初衷是用来存储互联网持续更新网页副本的技术，用在互联网相关的其他方面也是很合适的。例如，HBase在社交网络公司内部和周围各种各样的需求中找到了用武之地。从存储个人之间的通信信息，到通信信息分析，HBase成为了Facebook、Twitter和StumbleUpon等公司的关键基础设施。

在这个领域，HBase有3种主要使用场景，但不限于这3种。为了保持本节简单明了，本节我们只介绍主要的使用场景。

1.2.2　抓取增量数据

数据通常是细水长流的，累加到已有数据库以备将来使用，如分析、处理和服务。许多HBase使用场景属于这一类——使用HBase作为数据存储，抓取来自各种数据源的增量数据。例如，这种数据源可能是网页爬虫（我们讨论过的BigTable典型问题），可能是记录用户看了什么广告和看了多长时间的广告效果数据，也可能是记录各种参数的时间序列数据。我们讨论几个成功的使用场景，以及这些项目涉及的公司。

1．抓取监控指标：OpenTSDB

服务数百万用户的基于Web的产品的后台基础设施一般都有数百或数千台服务器。这些服务器承担了各种功能——服务流量，抓取日志，存储数据，处理数据，等等。为了保证产品正常运行，监控服务器和上面运行的软件的健康状态是至关重要的（从OS到用户交互应用）。大规模监控整个环境需要能够采集和存储来自不同数据源各种监控指标的监控系统。每个公司都有自己的办法。一些公司使用商业工具来收集和展示监控指标，而另外一些公司采用开源框架。

StumbleUpon创建了一个开源框架，用来收集服务器的各种监控指标。按照时间收集监控指标一般被称为时间序列数据，也就是说，按照时间顺序收集和记录的数据。StumbleUpon的开源框架叫做OpenTSDB，它是Open Time Series Database（开放时间序列数据库）的缩写。这个框架使用HBase作为核心平台来存储和检索所收集的监控指标。创建这个框架的目的是为了拥有一个可扩展的监控数据收集系统，一方面能够存储和检索监控指标数据并保存很长时间，另一方面如果需要增加功能也可以添加各种新监控指标。StumbleUpon使用OpenTSDB监控所有基础设施和软件，包括HBase集群自身。OpenTSDB作为搭建在HBase之上的一种示例应用，我们将在第7章详细介绍。

2．抓取用户交互数据：Facebook和StumbleUpon

抓取监控指标是一种使用方式。还有一种是抓取用户交互数据。如何跟踪数百万用户在网站上的活动？怎么知道哪一个网站功能最受欢迎？怎样使得这一次网页浏览直接影响到下一次？例如，谁看了什么？某个按钮被点击了多少次？还记得Facebook和Stumble里的Like按钮和StumbleUpon里的+1按钮吗？是不是听起来像是一个计数问题？每次用户喜欢一个特定主题，计数器增加一次。

StumbleUpon在开始阶段采用的是MySQL，但是随着网站服务越来越流行，这种技术选择遇到了问题。急剧增长的用户在线负载需求远远超过了MySQL集群的能力，最终StumbleUpon选择使用HBase来替换这些集群。当时，HBase产品不能直接提供必需的功能。StumbleUpon在HBase上做了一些小的开发改动，后来将这些开发工作贡献回了项目社区。

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

3．遥测技术：Mozilia和Trend Micro

软件运行数据和软件质量数据，不像监控指标数据那么简单。例如，软件崩溃报告是有用的软件运行数据，经常用来探究软件质量和规划软件开发路线图。HBase可以成功地用来捕获和存储用户计算机上生成的软件崩溃报告。

Mozilla基金会负责FireFox网络浏览器和Thunderbird电子邮件客户端两个产品。这些工具安装在全世界数百万台计算机上，支持各种操作系统。当这些工具崩溃时，会以Bug报告的形式返回一个软件崩溃报告给Mozilla。Mozilla如何收集这些数据？收集后又是怎么使用的呢？实际情况是这样的，一个叫做Socorro的系统收集了这些报告，用来指导研发部门研制更稳定的产品。Socorro系统的数据存储和分析建构在HBase上1。

使用HBase，基本分析可以用到比以前多得多的数据。这种分析用来指导Mozilla的开发人员，使其更为专注，研制出Bug最少的版本。

Trend Micro为企业客户提供互联网安全和入侵管理服务。安全的重要环节是感知，日志收集和分析对于提供这种感知能力是至关重要的。Trend Micro使用HBase来管理网络信誉数据库，该数据库需要行级更新和支持MapReduce批处理。有点像Mozilla的Socorro系统，HBase也用来收集和分析日志活动，每天收集数十亿条记录。HBase中灵活的数据模式允许数据结构出现变化，当分析流程重新调整时，Trend Micro可以增加新属性。

4．广告效果和点击流

过去十来年，在线广告成为互联网产品的一个主要收入来源。先提供免费服务给用户，在用户使用服务的时侯投放广告给目标用户。这种精准投放需要针对用户交互数据做详细的捕获和分析，以便理解用户的特征。基于这种特征，选择并投放广告。精细的用户交互数据会带来更好的模型，进而导致更好的广告投放效果，并获得更多的收入。但这类数据有两个特点：它以连续流的形式出现，它很容易按用户划分。理想情况下，这种数据一旦产生就能够马上使用，用户特征模型可以没有延迟地持续优化，也就是说，以在线方式使用。

在线系统与离线系统

在线和离线的术语多次出现。对于初学者来说，这些术语描述了软件系统执行的条件。在线系统需要低延迟。某些情况下，系统哪怕给出没有答案的响应，也要比花了很长时间给出正确答案的响应好。你可以把在线系统想象为一个跳着脚的没有耐心的用户。离线系统不需要低延迟，用户可以等待答案，不期待马上给出响应。当实现应用系统时，在线或者离线的目标影响着许多技术决策。HBase是一个在线系统。和Hadoop MapReduce的紧密结合又赋予它离线访问的能力。

HBase非常适合收集这种用户交互数据，HBase已经成功地应用在这种场合，它可以存储第一手点击流和用户交互数据，然后用不同的处理方式（MapReduce是其中一种）来处理数据（清理、丰富和使用数据）。在这类公司，你会发现很多HBase案例。

1.2.3　内容服务

传统数据库最主要的使用场合之一是为用户提供内容服务。各种各样的数据库支撑着提供各种内容服务的应用系统。多年来，这些应用一直在发展，因此它们所依赖的数据库也在发展。用户希望使用和交互的内容种类越来越多。此外，由于互联网迅猛的增长以及终端设备更加迅猛的增长，对这些应用的接入方式提出了更高的要求。各种各样的终端设备带来了另一个挑战：不同的设备需要以不同的格式使用同样的内容。

上面说的是用户消费内容（user consuming content），另外一个完全不同的使用场景是用户生成内容（user generate content）。Twitter帖子、Facebook帖子、Instagram图片和微博等都是这样的例子。

它们的相同之处是使用和生成了许多内容。大量用户通过应用系统来使用和生成内容，而这些应用系统需要HBase作为基础。

内容管理系统（Content Management System，CMS）可以集中管理一切，可以用来存储内容和提供内容服务。但是当用户越来越多，生成的内容越来越多的时候，就需要一个更具可扩展性的CMS解决方案。可扩展的Lily CMS2使用HBase作为基础，加上其他开源框架，如Solr，构成了一个完整的功能组合。

Salesforce提供托管CRM产品，这个产品通过网络浏览器界面提交给用户使用，显示出丰富的关系型数据库功能。在Google发表NoSQL原型概念论文之前很长一段时间，在生产环境中使用的大型关键数据库最合理的选择就是商用关系型数据库管理系统。多年来，Salesforce通过数据库分库和尖端性能优化手段的结合扩展了系统处理能力，达到每天处理数亿事务的能力。

当Salesforce把分布式数据库系统列入选择范围后，他们评测了所有NoSQL技术产品，最后决定部署HBase3。一致性的需求是这个决定的主要原因。BigTable类型的系统是唯一的架构方式，结合了无缝水平扩展能力和行级强一致性能力。此外，Salesforce已经在使用Hadoop完成大型离线批处理任务，他们可以继续沿用Hadoop上面积累的宝贵经验。

1．URL短链接

最近一段时间URL短链接非常流行，许多类似产品破土而出。StumbleUpon使用名字为su.pr.的短链接产品，这个产品以HBase为基础。这个产品用来缩短URL，存储大量的短链接以及和原始长链接的映射关系，HBase帮助这个产品实现扩展能力。

2．用户模型服务

经HBase处理过的内容往往并不直接提交给用户使用，而是用来决定应该提交给用户什么内容。这种中间处理数据用来丰富用户的交互。

还记得前面提到的广告服务场景里的用户特征吗？用户特征（或者说模型）就是来自HBase。这种模型多种多样，可以用于多种不同场景。例如，针对特定用户投放什么广告的决定，用户在电商网站购物时实时报价的决定，用户在搜索引擎检索时增加背景信息和关联内容，等等。很多这种使用案例可能不便于公开讨论，说多了我们就有麻烦了。

当用户在电商网站上发生交易时，Runa4用户模型服务可以用来实时报价。这种模型需要基于不断产生的新用户数据持续调优。

1.2.4　信息交换

各种社交网络破土而出5，世界变得越来越小。社交网站的一个重要作用就是帮助人们进行互动。有时互动在群组内发生（小规模和大规模），有时互动在两个个人之间发生。想想看，数亿人通过社交网络进行对话的场面。单单和远处的人对话还不足以让人满意，人们还想看看和其他人对话的历史记录。让社交网络公司感到幸运的是，保存这些历史记录很廉价，大数据领域的创新可以帮助他们充分利用廉价的存储。6

在这方面，Facebook短信系统经常被公开讨论，它也可能极大地推动了HBase的发展。当你使用Facebook时，某个时候你可能会收到或者发送短信给你的朋友。Facebook的这个特性完全依赖于HBase。用户读写的所有短信都存储在HBase里7。Facebook短信系统要求：高的写吞吐量，极大的表，数据中心内的强一致性。除了短信系统之外，其他应用系统要求：高的读吞吐量，计数器吞吐量，自动分库。工程师们发现HBase是一个理想的解决方案，因为它支持所有这些特性，它拥有一个活跃的用户社区，Facebook运营团队在Hadoop部署上有丰富经验，等等。在“Hadoop goes realtime at Facebook8”这篇文章里，Facebook工程师解释了这个决定背后的逻辑并展示了他们使用Hadoop和HBase构建在线系统的经验。

Facebook工程师在HBaseCon 2012大会上分享了一些有趣的数据。在这个平台上每天交换数十亿条短信，每天带来大约750亿次操作。尖峰时刻，Facebook的HBase集群每秒发生150万次操作。从数据规模角度看，Facebook的集群每月增加250TB的新数据9，这可能是已知的最大的HBase部署，无论是服务器的数量还是服务器所承载的用户量。

上述一些示例，解释了HBase如何解决一些有趣的老问题和新问题。你可能注意到一个共同点：HBase可以用来对相同数据进行在线服务和离线处理。这正是HBase的独到之处。了解到可以如何使用HBase之后，现在来试用一下。

1Laura Thomson, “Moving Socorro to HBase,” Mozilla WebDev,http://mng.bz/L2k9.

2Lily Content Management System:www.lilyproject.org。

3这段内容基于与Salesforce的一些工程师的个人沟通。

4www.runa.com。

5有人认为通过社交网络联系不意味着更加社会化。这是哲学讨论，我们不争论。和HBase没关系，对吧？

6加上广告收入。

7Kannan Muthukkaruppan, “The Underlying Technology of Messages,” Facebook, https://www.facebook.com/note.php?note_id=454991608919。

8Dhruba Borthakur等人的 “Apache Hadoop goes realtime at Facebook,” ACM Digital Library,http://dl.acm.org/citation.cfm?id=1989438。

9这些统计数据是在HBaseCon 2012的一个发言中分享的。我们没有可以引用的文档，但你可以搜索找到更多的信息。