海量数据的黎明——HBase

我们生活在一个互联网时代，无论是想搜索最佳的火鸡菜谱，还是送妈妈什么样的生日礼物，都希望能够通过互联网迅速地检索到问题的答案，同时希望查询到的结果有用，而且非常切合我们的需要。

因此，很多公司开始致力于提供更有针对性的信息，例如推荐或在线广告，这种能力会直接影响公司在商业上的成败。现在类似Hadoop①这样的系统能够为公司提供存储和处理PB级数据的能力，随着新机器学习算法的不断发展，收集更多数据的需求也在与日俱增。

以前，因为缺乏划算的方式来存储所有信息，很多公司会忽略某些数据源，但是现在这样的处理方式会让公司丧失竞争力。存储和分析每一个数据点的需求在不断增长，这种需求的增长直接导致各公司电子商务平台产生了更多的数据。

过去，唯一的选择就是将收集到的数据删减后保存起来，例如只保留最近N天的数据。然而，这种方法只在短期内可行，它无法存储几个月或几年收集到的所有数据，因此建议：构建一种数学模型覆盖整个时间段或者改进一个算法，重跑以前所有的数据，以达到更好的效果。

对于海量数据的重要性，Ralph Kimball博士指出②：

“数据资产会取代20世纪传统有形资产的地位，成为资产负债表的重要组成部分。”

还指出：

“数据的价值已经超越了传统企业广泛认同的价值边界。”

Google和Amazon是认识到数据价值的典范，它们已经开始开发满足自己业务需求的解决方案。例如，Google在一系列的技术出版物中描述了基于商业硬件的可扩展的存储和处理系统。开源社区利用Google的这些思想实现了开源Hadoop项目的两个模块：HDFS和MapReduce。

Hadoop擅长存储任意的、半结构化的数据，甚至是非结构化的数据，可以帮助用户在分析数据的时候决定如何解释这些数据，同样允许用户随时更改数据分类的方式：一旦用户更新了算法，只需要重新分析数据。

目前Hadoop几乎是所有现有数据库系统的一种补充，它给用户提供了数据存储的无限空间，支持用户在恰当的时候存储和获取数据，并且针对大文件的存储、批量访问和流式访问做了优化。这使得用户对数据的分析变得简单快捷，但是用户同样需要访问分析后的最终数据，这种需求需要的不是批量模式而是随机访问模式，这种模式相对于在数据库系统来说，相当于一种全表扫描和使用索引。

通常用户在随机访问结构化数据的时候都会查询数据库。RDBMS在这方面最为突出，但是也有一些少量的有差异的实现方式，比如面向对象的数据库。大多数RDBMS一直遵守科德十二定律（Codd’s 12 rules）③，这个定律对于RDBMS来说是刚性标准，并且由于RDBMS的底层架构是经过仔细研究的，所以在相当长的一段时间里这种架构都不会有明显的改变。近年来出现的各种处理方法，如列式存储的（column-oriented）数据库和大规模并行处理（Massively Parallel Processing，MPP）数据库，表明业界重新思考了技术方案以满足新的工作负载，但是大多数解决方案仍旧是基于科德十二定律来实现的，并没有打破传统的法则。

图1 列式存储结构与行式存储结构

值得注意的是，从典型RDBMS的角度来看，HBase并不是一个列式存储的数据库，但是它利用了磁盘上的列存储格式，这也是RDBMS与HBase最大的相似之处，因为HBase以列式存储的格式在磁盘上存储数据。但它与传统的列式数据库有很大的不同：传统的列式数据库比较适合实时存取数据的场景，HBase比较适合键值对的数据存取，或者有序的数据存取。

如今数据的产生速度比几年以前已经有了迅猛的增长，随着全球化步伐加快，这个增长速度只会越来越迅猛，由此所产生的数据处理问题也会越来越严峻。像Google、Amazon、eBay和Facebook这样网站的用户已经覆盖到了地球上的绝大多数人。全球化网络应用（planet-size web application）的概念已经形成，在这种背景下，企业使用HBase更合适。

举例来说，Facebook每天增量存储到它们Hadoop集群的数据量超过15 TB④，并且随后会对所有这些数据进行处理。这些数据一部分是点击流日志，用户点击了它们的网站或点击了使用Facebook提供的社交插件的网站，每一步点击操作都会被记录并保存，这非常适合以批处理的模式，为预测和推荐系统构建机器学习模型。

Facebook还有一个实时组件，就是它们的消息系统，其中包括聊天、涂鸦墙和电子邮件，每个月会产生超过1350亿条数据⑤，存储几个月之后便会产生一个量级庞大的尾部数据，并且这些尾部数据需要被有效地处理。尽管电子邮件中占用存储量较大的部分（如附件）通常存储在二级系统中⑥，但这些消息产生的数据量还是令人难以置信的。以Facebook的数据产生条目为基础，假如按Twitter中的每条数据占用140字节来计算，Facebook每个月将会产生超过17 TB的数据，在将这些数据导入到HBase之前，现存的系统每个月也要处理超过25 TB的数据。⑦

目前在少数的重点行业中，面向Web业务的公司收集的数据量也在不断增长。

金融

如股票涨跌产生的数据。

生物信息学

如全球生物多样性信息机构（Global Biodiversity Information Facility，http://www.gbif.org/）。

智能电网

如OpenPDC（http://openpdc.codeplex.com/）项目。

销售

如销售终端（POS机）产生的数据，或者是股票系统、库存系统。

基因组学

如Crossbow（http://bowtie-bio.sourceforge.net/crossbow/index.shtml）项目。

移动电话服务、军事、环境工程

也产生了海量的数据。

海量数据领域越来越被重视，且该领域涌现出了非常多的新技术。技术的发展和时间的沉淀使得HBase开始被大家广泛认可，成为海量数据在线存储领域的首选。

①相关信息可以在Hadoop的官方网站http://hadoop.apache.org/中找到。也可以到Tom White编写的《Hadoop权威指南（第2版）》（原出版社为O’Reilly）一书中查阅你想了解的Hadoop知识。

②此处引用的是Kimball集团的Ralph Kimball博士的一篇题为“Rethinking EDW in the Era of Expansive Information Management”的演讲（http://www.informatica.com/campaigns/rethink_edw_kimball.pdf），这个演讲讨论了一个不断发展的企业数据仓库市场的需求。

③Edgar F. Codd定义了13个规则（编号为0～12），这些规则促使数据库管理系统（Datebase Management System，DBMS）被考虑为RDBMS。HBase需要满足更多的通用规则，但也有一些规则没有满足，最重要的是规则5：全面的数据子语言规则，这个规则定义了至少需要支持一种关系型语言。详情见维基百科关于科德十二定律的链接http://en.wikipedia.org/wiki/Codd's_12_rules。

④见Facebook提供的信息http://www.facebook.com/note.php?note_id=89508453919。

⑤请看博文http://www.facebook.com/note.php?note_id=454991608919，这篇博文来自Facebook的工程团队。150亿条墙消息和1200亿条聊天消息，共计1350亿条消息一个月。此外，Facebook还添加了SMS和其他一些应用，这些都会使数据量变得更为庞大。

⑥Facebook使用了Haystack，Haystack优化了二进制大对象的存储结构，提供了二进制小对象存储，例如图片。

⑦见http://www.slideshare.net/brizzzdotcom/facebook-messages-hbase，这是Facebook的员工Nicolas Spiegelberg写的，他也是HBase的committer。

本文节选自《HBase权威指南》

内容简介

本书探讨了如何通过使用与HBase高度集成的Hadoop将HBase的可伸缩性变得简单；把大型数据集分布到相对廉价的商业服务器集群中；使用本地Java客户端，或者通过提供了REST、Avro和Thrift应用编程接口的网关服务器来访问HBase；了解HBase架构的细节，包括存储格式、预写日志、后台进程等；在HBase中集成MapReduce框架；了解如何调节集群、设计模式、拷贝表、导入批量数据和删除节点等。

本书适合使用HBase进行数据库开发的高级数据库研发人员阅读。

本文转载自异步社区

原文链接：https://www.epubit.com/articleDetails?id=NC7E3EF9195500001AEB69C171B8015AB