HBase仿效了Google的BigTable，让我们开始探索典型的BigTable问题：存储互联网。

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

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

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

　　建立互联网索引

　　1 爬虫持续不断地抓取新页面，这些页面每页一行地存储到BigTable里。

　　2 MapReduce计算作业运行在整张表上，生成索引，为网络搜索应用做准备。

　　搜索互联网

　　3 用户发起网络搜索请求。

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

　　5 搜索结果提交给用户。

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

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

　　捕获增量数据

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

　　捕获监控参数：OPENTSDB

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

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

　　捕获用户交互数据：Facebook和StumbleUpon

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

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

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

　　TELEMETRY：MOZILLA 和 TREND MICRO

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

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

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

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

　　广告效果和点击流

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

　　在线 VS 离线系统

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

　　HBase非常适合收集这种用户交互数据，HBase已经成功地应用在这种场合，它可以增量捕获第一手点击流和用户交互数据，然后用不同处理方式(MapReduce是其中一种)来处理数据(清理、装饰、使用数据)。在这种公司，你会发现很多HBase案例。

　　内容服务

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

　　一方面是用户使用内容 User Consuming Content，对应另一面是用户生成内容 User GenerateContent。Tweete、Facebook帖子、Instagram 图片和微博等都是这样的例子。

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

　　集中的内容系统系统 CMS可以存储内容和提供服务。但是当用户越来越多，生成内容越来越多的时候，就需要一个更具扩展性的CMS解决方案。

　　这种可扩展的CMS往往使用Hbase作为基础，再加上其他的开源框架，例如Solr，构成一个完整的功能组合。

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

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

　　URL短链

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

　　用户模型服务

　　经过HBase处理过的内容往往并不直接提交给用户使用，而是用来决定应该提交给用户什么内容。这种中间处理数据用来丰富用户的交互。还记得前面提到的广告服务场景里的用户模式吗?用户模式(或者说模型)就是来自于HBase。这种模型多种多样，可以用于多种不同场景，例如，针对特定用户投放什么广告的决定，用户在电商门户购物时实时报价的决定，用户在搜索引擎检索时增加背景信息和关联内容，等等。很多这种使用案例可能不便于公开讨论，说多了我们就麻烦了。

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

　　 信息交换

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

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

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