本文主要简单的介绍一下hbase数据库，主要是基本模型，与关系数据库的不同，主要应用场景。

本文并未涉及hbase数据库的安装，具体安装过程网上都比较详细，也可参考《hbase权威指南》

1 hbase数据库产生的根源

hbase是google公司bigtable的开源实现，hbase基于hadoop的hdfs主要是对hadoop分布式文件系统hdfs的有效补充。因为hdfs存在存储大量小文件效率低下（小文件太对存储文件的原信息就多，造成namenode效率低下），同时还有效的解决了hdfs的不便随机存储问题。hbase可应用与在线存储，或者离线分析等。

hbase平台的结构如下图:

2 hbase 数据库与关系型数据库的异同

通常用户访问结构化数据的时候都会查询数据库，主要是RDBMS数据库 ，但随着数据量的增加关系数据库的底层架构尚未有明显的变化，主要变化是是列式存储和大规模并行处理，下图是列式存储与行式存储的对比：

因此，关系型数据库在保存增长量有限的数据是是很好的选择，比如用户注册，订单量，产品等，但对应极具增加的数据就显得力不从心了，因此这时可以考虑分布式的NOSQL数据库hbase。

hbase与关系数据库的相同点：

从典型的RDBMS的角度看，hbase并不是一个列式存储的数据库，但是它利用了磁盘上的列存储格式，这也算RDBMS与Hbase最大的相似之处，因为hbase以列式存储的格式在磁盘上存储数据。

hbase与关系数据库的不同点

1 传统数据库比较适合实时存取数据的场景，hbase比较适合 键值对的数据存取，或者是有序的数据存取。

2 RDBMS实现了数据存储的强一致性，因此根据CAP理论为了实现强一致性，通过严格的ACID事务来进行同步，这就造成了系统的可用性和伸缩性方面大大折扣，而目前的很多NoSQL 产 品，包括Hbase，它们都是一种最终一致性的系统，它们为了高的可用性牺牲了一部分的一致性。（数据库中一般通过ACID事务来实现一致性）

3 RDBMS一般有固定模式和ACID事务，但hbase一类的系统大都并不支持ACID事务和辅助索引，并且hbase无固定的访问模式，可以随着应用灵活的变化。

下面是一写其他的不同点或者是区分关系数据库与非关系数据库的点：

数据模型：数据有多种存储方式，包括键值对，列式存储，文档存储

一致性：是严格一致性（关系数据库）还是最终一致性（非关系数据库）

物理模型：分布式还是单机！

读写性能：是读多写少，还是读少写多，是范围扫描好还是随机读写好！

辅助索引：辅助索引按用户不同的字段或排列方式访问。

 HBase  使用场景和成功案例

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

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

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

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

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

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

 下图是googleweb索引的应用图：

建立互联网索引

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

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

搜索互联网

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

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

5 搜索结果提交给用户。

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

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

1.2.2 捕获增量数据

数据通常是细水长流，累加到已有数据库以备将来使用，例如分析，处理和服务。许多 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 案例。

1.2.3 内容服务

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

一方面是用户使用内容 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 。这种模型多种多样，可以用于多种不同场景，例如，针对特定用户投放什么广告的决定，用户在电商门户购物时实时报价的决定，用户在搜索引擎检索时增加背景信息和关联内容，等等。很多这种使用案例可能不便于公开讨论，说多了我们就麻烦了。

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

1.2.4 信息交换

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

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 部署，无论是服务器的数量还是服务器所承载的用户量。

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

原文：http://blog.csdn.net/u010282707/article/details/24091125