《MapReduce 2.0源码分析与编程实战》一1.1 数据管理系统：速成

本节书摘来异步社区《MapReduce 2.0源码分析与编程实战》一书中的第1章，第1.1节，作者： 王晓华 责编： 陈冀康，更多章节内容可以访问云栖社区“异步社区”公众号查看。

1.1　数据管理系统：速成

HBase实战
关系型数据库系统已经存在几十年了，多年来在解决数据存储、服务和处理问题方面取得了巨大的成功。一些大型公司使用关系型数据库建立了自己的系统，比如联机事务处理系统和后端分析应用系统。

联机事务处理（OLTP）系统用来实时记录交易信息。对这类系统的期望是能够快速返回响应信息，一般是在毫秒级。例如，零售商店的收银机在客户购买和付款时需要实时记录相应信息。银行拥有大型OLTP系统，用来记录客户之间转账之类的交易信息，但OLTP不仅仅用于资金交易，像LinkedIn这样的互联网公司也需要这样的系统，例如，当用户连接其他用户时也会用到。OLTP中的transaction指的是数据库语境中的事务，而不是金融交易。

联机分析处理（OLAP）系统用来分析查询所存储数据。在零售商那里，这种系统意味着按天、按周、按月生成销售报表，按产品和按地域从不同角度分析信息。OLAP属于商业智能的范畴，数据需要研究、处理和分析，以便收集信息，进一步驱动商业决策。对于LinkedIn这样的公司，连接关系的建立可以看做事务，分析用户关系图的连通性以及生成每用户平均联系数量这种信息的报表就属于商业智能，这种处理很可能需要使用OLAP系统。

无论是开源的还是商业版权的关系型数据库，都已经成功地用于这样的使用场景。这一点通过Oracle、Vertica、Teradata等公司的财务报表可以清楚地看到。微软公司和IBM公司也占有一定份额。所有这些系统提供全面的ACID1保证。一些系统扩展性要优于其他系统；一些系统是开源的，还有一些需要支付夸张的许可费用。

关系型数据库的内部设计由关系算法决定，这些系统需要预先定义一个模式（schema）和数据要遵守的类型。随着时间的推移，SQL成了与这些系统交互的标准方式，被广泛使用了许多年。与使用编程语言编写定制访问代码相比，SQL语句更容易写，花费时间也要少得多。但并不是所有情况下SQL都是表达访问模式的最好方式，比如对象-关系不匹配问题出现的场合。

计算机科学中的问题都可以通过改变使用方式来解决。解决对象-关系不匹配问题也没有什么不同，最终可以通过重建框架来解决。

1.1.1　你好，大数据

让我们认真看看大数据这个术语。说实话，这是一个过分吹捧的术语，很多商业化的企业都会使用它来进行市场营销。我们这里尽量让讨论接点儿地气。

什么是大数据？关于大数据的定义有好几种，我们认为没有哪一种定义清晰地解释了这个术语。比如，一些定义说大数据意味着数据足够大，为了从这些数据中获得一些真知灼见，你不得不研究它；另一些说大数据就是不再适用于单台机器的数据。这些定义从他们各自的角度来看是准确的，但并不完整。我们的观点是，我们需要用一种根本上不同的方式来考虑数据，从如何驱动商业价值的角度来考虑数据，这种数据就是大数据。传统上，有联机事务处理系统（OLTP）和联机分析处理系统（OLAP）。但是，事务处理背后的原因是什么？是什么因素促成业务发生？又是什么直接影响了用户行为？我们缺乏这样的洞察力。以早期的LinkedIn为例，这种使用数据的方式可以理解为：基于用户属性、用户之间的二度关系、浏览行为等寻找可能认识的人，然后主动推荐并引导用户联系他们。有效地寻求这种主动推荐行为显然需要大量的各种各样数据。

这种新型数据使用方式首先为Google和Amazon等互联网公司采用，随后是Yahoo!和Facebook跟进。这些公司需要使用不同种类的数据，经常是非结构化的或者半结构化的数据（如用户访问网站的日志）。这需要系统处理比传统数据分析高了几个数量级的数据。传统关系型数据库能够纵向扩展到一定程度来面对一些使用场景，但这样做经常意味着昂贵的许可费用和复杂的应用逻辑。

但是受制于关系型数据库提供的数据模型，对于逐渐出现的、未预先定义模式（schema）的数据集，关系型数据库不能很好地工作。系统需要能够适应不同种类的数据格式和数据源，不需要预先严格定义模式，并且能够处理大规模数据。系统需求发生了巨大变化，互联网先驱不得不走回画图板，重新设计数据库，他们这样做了。大数据系统和NoSQL的曙光出现了。（有人可能会说曙光出现的时间点还要再晚一些，这并不重要，这的确标志着大家开始以不同方式思考数据了。）

作为数据管理系统创新的一部分，出现了几种新技术。每种新技术都适用于不同的使用场景，有着不同的设计前提和功能要求，也有着不同的数据模型。

什么时候会谈到HBase呢？是什么促使了这个系统的创立呢？请看下一节介绍。

1.1.2　数据创新
我们知道，许多杰出的互联网公司，如最突出的Google、Amazon、Yahoo!、Facebook等，都处于这场数据大爆炸的最前沿。一些公司自己生成数据，还有一些公司收集免费可获得的数据；但是管理这些海量的不同种类的数据成为他们推进业务发展的关键。开始阶段他们都采用了当时可用的关系型数据库技术，但是这些技术的局限性随后成了他们继续发展和业务成功的障碍。尽管数据管理技术不是他们业务的核心，但却是推进业务的基础。因此，他们大量投资于新技术研究领域，带来了许多新数据技术的突破。

很多公司都对自己的研究成果严格保密，但是Google选择公开讲述他的伟大技术。Google发表了震撼性的Google文件系统（Google File System）2和MapReduce3的论文。两者结合展示了一种全新的存储和处理数据的方法。此后不久，Google发表了BigTable4的论文，对基于Google文件系统的存储范型提供了补充。其他公司也参与进来，公布了各自的成功技术的想法和做法。Google的论文提供了对于如何建立互联网索引的深刻理解，Amazon公布了Dynamo5，解密了网上购物车的基本组件。

不久，所有这些新想法都被浓缩到开源实践中。接下来的几年，数据管理领域出现了形形色色的项目。一些项目关注快速键值（key-value）存储，而另外一些关注内置数据结构或者基于文档的抽象化。同样多种多样的是这些技术可以支持的预期访问模式和数据量。一些项目甚至放弃写数据到硬盘，为了性能而牺牲当前的数据持久化。大多数技术不能保证支持受推崇的ACID。尽管有一些是商业版权产品，但是绝大多数这类技术都是开源项目。因此，这些技术作为整体被称为NoSQL。

HBase适于什么场合呢？HBase的确被称为NoSQL数据库。它提供了键值API，尽管有些变化，与其他键值数据库有些不同。它承诺强一致性，所以客户端能够在写入后马上看到数据。HBase运行在多个节点组成的集群上，而不是单台机器。它对客户端隐藏了这些细节。你的应用代码不需要知道它在访问1个还是100个节点，对每个人来说事情变得简单了。HBase被设计用来处理TB到PB级数据，它为这种场景做了优化。它是Hadoop生态系统的一部分，依靠Hadoop其他组件提供的重要功能，例如数据冗余和批处理。

了解了大背景后，我们再专门看看HBase的崛起。

1.1.3　HBase的崛起
假设你正忙于一个开源项目，通过爬网站和建立索引来搜索互联网。你有一个实现方案，这个实现方案工作在一个小集群上，但是需要许多手工环节。再假设你正忙于这个项目的时候，Google发表了数据存储和数据处理框架的论文。显然，你会研究这些论文，模仿它们启动一个开源实现。好吧，你不打算这么做，我们当然也不会，但是Doug Cutting和Mike Cafarella就是这么做的。

Nutch是他们的互联网搜索开源项目，脱胎于Apache Lucene，Hadoop就是在Nutch项目里诞生的6。从那时起，Yahoo!开始关注Hadoop，最后Yahoo!招募了Cutting和其他人为Yahoo!全职工作。随后，Hadoop从Nutch中剥离出来，最后成为Apache的顶级项目。随着Hadoop的良好发展和BigTable论文的发表，在Hadoop上面实现一个BigTable开源版本的基础工作开始了。2007年，Cafarella发布了实验性代码，开源的BigTable。他称其谓HBase。创业公司Powerset决定贡献出Jim Kellerman和Michael Stack两位专家专职做这个BigTable的模仿产品，回馈它所依赖的开源社区7。

HBase被证实是一个强大的工具，尤其是在已经使用Hadoop的场合。在其“婴儿期”的时候，它就快速部署到了其他公司的生产环境并得到开发人员的支持。今天，HBase已经是Apache顶级项目，有着众多的开发人员和兴旺的用户社区。它成为一个核心的基础架构部件，运行在世界上许多公司（如StumbleUpon、Trend Micro、Facebook、Twitter、Salesforce和Adobe）的大规模生产环境中。

HBase不是数据管理问题的；“万能药”，针对不同的使用场景你可能需要考虑其他的技术。让我们看看现在HBase是如何使用的，人们用它构建了什么类型的应用系统。通过这个讨论，你会知道哪种数据问题适合使用HBase。