作者：江大伟、高云君、陈刚 编著
出版社：化学工业出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
大数据管理系统试读：
前言
作为过去十年里最重要的信息技术，大数据技术深刻影响了人们生活的方方面面。如今，从在家购物到出门打车，从投资理财到金融风控，从健康管理到公共安全，人们无时无刻不在使用各种大数据。在大数据引领的信息时代下，如何有效管理大数据，从大数据中获取有价值的信息，提升组织者的决策水平，发现新的利润增长点，成为各界持续关注和广泛研究的重要课题。大数据管理技术已经成为互联网等行业的核心竞争力之一。
大数据管理技术涉及了大数据管理的各个方面，包括数据存储、数据查询、数据治理、数据集成、数据处理、数据分析、数据可视化。传统关系数据库的一站式服务已经无法满足大数据领域的数据处理需求。一方面，以互联网应用为代表的大数据应用产生的庞大数据量超出了传统工具的处理能力；另一方面，异构数据源和种类繁多的大数据应用对数据处理和数据查询提出了诸多灵活性需求，这些需求大多不易通过传统的SQL查询来实现。为解决数据量大和数据处理需求多样性所带来的挑战，大数据管理技术发展出了一系列革新的数据管理技术。
本书从大数据管理技术产生的历史背景出发，对大数据管理技术的起源和发展进行了全面介绍，详细讨论大数据管理技术，包括大数据建模技术、大数据存储和索引技术、大数据查询处理技术、大数据事务处理技术和大数据总线技术等，并在此基础上，对大数据应用系统进行了全面分析。
本书采取理论与实践并重的方式介绍大数据管理技术。在理论层面，力求覆盖面广，涵盖大数据管理技术的所有重要分支。在具体技术层面，力求深入浅出，重点介绍技术产生的应用背景，以及该技术解决应用中痛点问题的基本原理。对技术实现细节感兴趣的读者，可以通过书中列出的引文，从原始文献中获取相关信息。在实践层面，本书通过三章内容，具体介绍大数据管理技术如何应用于实际的大数据应用系统。希望这样的安排，能够满足不同层面的读者对大数据管理技术的研习需求。
本书面向大数据应用的开发人员、大数据管理系统的开发人员以及大数据管理技术的研究人员，也适用于高等院校相关专业师生学习。本书要求读者具有一定的计算机基础和数据库相关知识。希望本书在帮助读者了解大数据技术发展的同时，能够为相关领域的工作者在进行大数据系统开发时提供借鉴。
本书由浙江大学计算机科学与工程系陈刚教授、江大伟研究员、高云君教授共同编著。在本书的撰写过程中，丹麦奥尔堡大学的助理教授陈璐博士给予了有益的反馈。浙江大学计算机科学与工程系研究生张哲槟、鲁鹏凯、胡文涛、蒋飞跃、卜文凤、张远亮、仲启露等同学参与本书的校对以及插图绘制等工作。在此，向上述在本书撰写过程中给予帮助的老师和同学们表示深深的感谢。
由于作者水平有限，书中难免会有疏漏之处，敬请同行和读者不吝赐教，我们当深表感谢。编著者第1篇 大数据管理系统基础第1章 大数据技术简介1.1 大数据技术的起源“大数据”一词最早出现于SGI公司首席科学家John R.Mashey博士在1999年USENIX年度技术会议上做的特邀报告中。在该报告中，Mashey博士论述到：“人们对网络应用的期望正在不断提升，人们希望网络应用能够创建、存储、理解大数据，数据量越来越大（图片、［1］图像、模型），数据类型越来越多（音频、视频）。”Mashey博士的论述总结了我们对大数据最初的两点认识：①互联网应用是大数据的驱动型应用；②大数据的特征是数据量大、数据类型多。随后，Laney博士在一份未公开的研究报告中进一步将大数据的特征定义为［2］数据量大、数据类型杂、数据产生速度快（即3V）。Laney博士的定义构成了我们普遍接受的对大数据的描述性定义。
然而，大数据的概念在提出后并没有受到人们的关注，甚至在相当长的时间内被人们遗忘。2000年3月10日美国纳斯达克指数创造了5048.62点的历史性新高。不幸的是，在随后的黑色星期一（即3月13日），发生了互联网泡沫破裂，以.com公司为代表的科技股票遭受大规模抛售。在纳斯达克上市的企业有500家破产（其中90%的企业为互联网企业），惨淡的股市使人们再没有理由不关注互联网应用以及与之相关的大数据技术。
互联网泡沫破裂的原因是多方面的，但是其中最重要的原因是当时的互联网企业无法找到稳定的盈利模式。与传统企业不同，互联网企业并不经营实物资产，而是经营虚拟的数据资产。因此，传统企业研发的实物资产管理和变现技术并不适用于互联网企业。而互联网企业也没有研发出适应自身特点的资产管理和变现技术。由于缺乏有效的资产变现手段，在互联网泡沫破裂前，几乎所有的互联网企业都处于严重亏损状态。糟糕的营收绩效极大地打击了投资者的信心，从而引发了大规模的股票抛售。
幸运的是，互联网产业并没有从此消失。一些互联网企业如亚马逊、谷歌、雅虎等存活了下来。他们反思企业运营中出现的问题，投入大量的精力研发适合自身特点的资产管理和变现技术，向技术要红利。经过近十年的摸索，亚马逊的股价在2011年升至246.71美元，相较2001年泡沫破裂后的5.51美元，增长了近50倍！如此戏剧性的惊天逆转震惊了所有人。人们纷纷追问两个问题：①互联网企业成功的秘诀是什么？②能否将互联网企业成功的秘诀复制到非互联网企业？
经过研究，人们发现互联网企业成功的秘密在于研发出了适应自身资产特点的“开源节流”技术。首先，互联网企业研发出云计算技术，有效地降低了维护海量数据资产的运营成本；其次，互联网企业研发出大数据管理技术，高效地管理其数据资产；最后，互联网企业研发出大数据分析技术，有效地从数据资产中发现规律，提升数据资产的变现效率。人们将互联网企业研发出的大数据管理技术和大数据分析技术统称为大数据技术。进一步的研究表明，大数据技术乃至云计算技术可以向非互联网企业迁移。也就是说，大数据技术和云计算技术仍然有巨大的潜力和上升空间。
至此，谜底揭开。人们重新以巨大的热情讨论大数据技术。各国政府纷纷制定政策推动大数据技术的研发与应用。大数据相关的研讨［3，4］［5］经常被《经济学家》、《纽约时报》和“国家公共广播电
［6，7］台”等公共媒体报道。两个主要的科学期刊《自然》和《科［8，9］学》也开辟了专栏来讨论大数据的挑战和影响。
本书主要介绍大数据管理技术。在正式展开讨论之前，我们首先介绍与大数据技术密切相关的云计算技术。1.2 大数据与云计算
云计算与大数据密切相关。大数据是计算密集型操作的对象，需要消耗巨大的存储空间。云计算的主要目标是在集中管理下使用巨大的计算和存储资源，用微粒度计算能力提供大数据应用。云计算的发展为大数据的存储和处理提供了解决方案。另外，大数据的出现也加速了云计算的发展。基于云计算的分布式存储技术可以有效地管理大数据；借助云计算的并行计算能力可以提高大数据采集和分析的效率。尽管云计算和大数据技术存在很多重叠的技术，但在以下两个方面有所不同。首先，它们的概念在一定程度上是不同的。云计算转换IT架构，而大数据影响业务决策。但是，大数据依赖云计算作为平稳运行的基础架构。其次，大数据和云计算有不同的目标客户。云计算是针对首席信息官（CIO）的技术和产品，是一种先进的IT解决方案。大数据是针对首席执行官（CEO）、聚焦于业务运营的产品。因为决策者可能直接感受到市场竞争的压力，所以必须以更具竞争力的方式击败对手。随着大数据和云计算的发展，这两种技术当然也越来越相互融合。云计算具有类似于计算机和操作系统的功能，提供系统级资源；大数据及相应的大数据管理系统运行在云计算支持的上层，提供类似于数据库的功能和高效的数据处理能力。
大数据的演变受快速增长的应用需求所驱动，而云计算是由虚拟化技术发展而成的。因此，云计算不仅为大数据提供计算和处理，其本身也是一种服务模式。在一定程度上，云计算的发展促进了大数据的发展，两者相辅相成。参考文献［1］ Diebold F. On the Origin（s） and Development of the Term“Big Data”. Pier working paper archive，Penn Institute for Economic Research，Department of Economics，University of Pennsylvania，2012.［2］ Laney D. 3-D Data Management：Controlling Data Volume，Velocity and Variety.META Group Research Note，2001.［3］ Cukier K. Data，data everywhere：a sp-ecial report on managing information. Economist Newspaper，2010.［4］ Drowning in numbers-digital data will flood the planet and help us understand it better，2011. http：//www. economist. com/bl-ogs/dailychart/2011/11/bigdata-0.［5］ Lohr S. The age of big data. New York Times，2012.［6］ Yuki N. Following digital breadcrumbs to big data gold. http：//www. npr. org/2011/11/29/142521910/thedigitalbreadcrumbsthat-lead-to-big-data，2011.［7］ Yuki N. The search for analysts to make sense of big data. http：//www. npr. org/2011/11/30/142893065/the-searchforanalyststo-make-sense-of-big-data，2011.［8］ Big data. http：//www. nature. com/news/specials/bigdata/index. html，2008.［9］ Special online collection：dealing with big
data. http：//www. sciencemag. org/site/special/data/，2011.第2章 大数据管理系统架构2.1 大数据管理系统不能采用单一架构2.1.1 大数据的5V特征
麦肯锡研究所将大数据定义为那些用传统数据库软件无法有效地获取、存储、管理和分析的超大规模数据集。在20世纪70年代，6MB（10bytes）级别的数据就能被称作“大”数据了，随着存储介质的更新换代和数据来源的不断扩大，如今能够被称作大数据的数据1215规模已经从TB（10bytes）到PB（10bytes），甚至达到了18EB（10bytes）级别。Gartner研究机构将大数据的特征概括为3V：大体量（Volume）、高速性（Velocity）和多样性（Variety），而后其他研究者在此基础上增加了真实性（Veracity）和价值性（Value），它们共同构成了大数据的5V特征。（1）大体量（Volume）
在如今这个信息爆炸的时代，我们每年获取的数据量，都比以前成百上千年所积累的信息总量要多得多。数据的来源十分广泛，股票交易、社交网站、交通网络，每分每秒都有数据源源不断地被收集和存储。随着人们的生活逐渐迈入智能化和云计算的时代，数据量的增长将会难以估量。
要对如此海量的数据进行存储和加工，所需的硬件设备规模也是十分庞大的。以Google公司为例，截至2015年，他们已经在全球拥有36个数据中心，分布于美国、欧洲、南美洲和亚洲等区域。据估计，Google公司的服务器数量至少有20万台，实际的数字可能更多，并且还在不断地增长当中。Google公司也正在进一步扩展其数据中心的数量，2017年在另外12个地区建立了更多的数据中心。（2）高速性（Velocity）
大数据的高速性指的是数据以极快的速度被产生、累积、消化和处理。许多数据都具有时效性，这要求它们在一定的时间限度内被消化掉。在很多领域，对这些源源不断产生的海量数据进行实时分析和处理是十分必要的——搜索引擎要能让用户查找到几分钟前发生的事情的新闻报道；个性推荐算法需要根据用户行为特征尽可能快地向用户完成推送；医疗机构通过监测网上的文章和用户搜索记录来跟踪流感传播等。
大数据管理系统，不仅需要对海量的数据进行可靠存储，更要具备高效的数据分析和处理能力，才能适应当今时代下大数据的发展。（3）多样性（Variety）
传统的数据库管理系统是为了管理交易记录而诞生的，这些结构化的数据能够用关系数据库系统保存和分析。而如今，传播于互联网中的数据已经远不止是简单的交易记录了，数据的类型也从简单的结构化数据转变成了半结构化和非结构化的数据。数据来源的广泛性极大地增加了数据格式的多样性——社交网络中的博客内容、购物网站中的购买记录、移动设备中的位置信息、监控网络中的录像视频、传感仪器上传的测量数据，不一而足。格式的多样性使得很难用传统的结构化数据库软件来存储这些数据，人们需要用新的技术来迎接大数据多样性带来的挑战。（4）真实性（Veracity）
数据的来源是极其广泛的，通常无法人为进行控制，这就导致了数据的可靠性和完整性的问题。数据的可靠性和完整性决定了数据的质量，如果不加以甄别地对这些质量不一的数据进行统一的加工处理，那么得到的分析结果也将是不可靠的。如何在数据分析处理的过程中对数据的真实性加以判别，将是大数据时代下人们面临的另一个挑战。（5）价值性（Value）
大数据的价值不在于数据本身，而在于从大数据的分析中所能发掘出的潜在价值。大数据的体量大而价值密度低，大数据的分析挖掘过程就是提升其价值的过程。通过强大的算法来对庞大的数据集合进行有机的组织和分析，大数据中所蕴含的价值才能被提炼出来。
前面的四个特征是从技术的角度看待大数据的特征的，而大数据价值性的实现依赖于技术基础。只有当我们能够解决大数据时代带来的技术挑战时，大数据的价值性才能够得到体现。2.1.2 关系数据库系统架构的缺陷
1970年，E.F.Codd博士发表了有关数据库的关系模型的论文［1］
，提出了关系数据库的理论模型。紧接着IBM公司便着手开发了关系数据库的原型系统——System R。1973年，加州大学伯克利分校开发了自己的关系数据库系统Ingres。至此，关系数据库成了数据库市场的主流，走上了商业化的道路。Oracle等公司基于Ingres项目推出了自己的商业化产品。关系数据库迅速发展起来，成了商业领域数据管理的不二之选。
随着数据库需要处理的数据量的增加，单台计算机的磁盘和性能已经无法对如此多的数据进行存储和分析，并行数据库应运而生。“无共享型”并行数据库的各个节点都是一台单独的计算机，它们拥有各自独立的处理器、内存和磁盘，并通过网络互相连接。数据以哈希或其他方式分散存储于各个节点上，而对数据的操作采取的是分而治之、并行处理的策略。并行数据库的第一代系统诞生于20世纪80年代，它为用户提供了统一的SQL查询语言，掩盖了并行编程的复杂性，其高性能和高可用性使其取得了巨大成功。看起来，并行数据库似乎已经是一个十分完善的系统了。
然而到了20世纪90年代，万维网的兴起使得Google、Yahoo这样的搜索引擎公司需要处理的数据量激增，数据的处理方式也和以前的关系模型大不相同，并行数据库提供的SQL查询已不能适应他们的应用需求。Google为了解决该问题，开发了自己的文件系统——Google File System（GFS），以及相应的编程模型——［2］MapReduce。这就是大数据分析平台Hadoop的前身，我们在下一节将会详细介绍。
反观数据库在过去几十年里的发展，数据库厂商致力于往同一个方向发展——One size fits all——使用单一数据库管理系统架构来服务各种各样的应用场景。数据库厂商们希望为所有的用户提供相同软件服务，使他们能在自己的应用中轻松地部署这样的数据库系统。但在应用和需求不断变化的今天，One size fits all的图景已经不复存在，大数据的出现给管理系统带来的新的挑战，逼迫传统的关系数据库走下历史的舞台，而根据个性需求为用户定制的大数据系统正在兴起。
如今，在数据库系统的各个市场分支上，相比于专门定制的数据库系统，传统的关系数据库的性能都已经远远落后。我们将通过几个例子来说明这一点。（1）数据仓库
所有主流的数据库管理系统都是使用行存储的，也就是把一条记录的各个属性的值在磁盘上连续存储。行存储方式带来的好处是，当需要写入一条记录的时候，只需要对磁盘进行一次写操作，因此这样的存储方式是面向写优化的。写优化在联机事务处理的应用中显得尤其重要，这也是主流数据库系统采用行存储的原因。
但是数据仓库不同于联机事务处理，通常只是周期地将大量数据导入到数据仓库中而不需要频繁地写入和更新操作，数据仓库需要向用户提供的是强大的即席（ad-hoc）查询能力——让用户根据自己的需求，灵活地选择查询条件，在大规模数据集上做查询并得到相应的统计报表。因此数据仓库需要实现的是面向读优化的系统，而列存储方式能够满足这一要求。在某些应用场景中，一条记录的属性可能多达上百个，但用户查询只关心其中的某几个属性，如果使用行存储模式，那么读取无关属性就会浪费大量的磁盘读取时间，而列存储系统可以只读取特定的属性，极大提升了查询效率。（2）文本检索
文本检索被广泛地应用于搜索引擎等领域。在文本检索中，最常见的操作主要包含两个方面：将网络爬虫得到的新文档保存到已有目录中；对现有目录进行即席查询。在这样的系统中，写操作通常只包含追加操作，而读操作通常是连续读取。为了提升效率，需要支持对同一文件并发的写入。另外，系统需要有很高的容错率，因为在这样一个由性能一般的机器组成的集群中错误时常发生，系统设计需要具有高可用性和从错误中迅速恢复的能力。
擅长处理传统的交易事务的数据库系统已经难以胜任文本检索这样的工作，即便某些数据库系统已经添加了对文本检索应用的支持，但其性能和易用性也远不及那些专门针对文本检索的定制系统，比如Google的GFS文件系统。
除了上面提到的数据仓库和文本检索之外，在另外一些领域诸如科学计算数据库、XML数据库和传感器网络数据，传统数据库管理工具也已经暴露出了其局限性。
单一架构（One size fits all）的时代已经过去，在大数据的浪潮下，数据管理系统的发展正在进入一个新的时期。不同的领域中呈现出各种不同的应用场景，从而对数据管理工具提出个性化要求。数据库管理系统需要不断去适应用户需求，才能在竞争激烈的市场中占得一席之地。2.2 基于Hadoop生态系统的大数据管理系统架构2.2.1 Hadoop简介［3］
Hadoop起源于Google Lab开发的Google File System（GFS）存储系统和MapReduce数据处理框架。当时Google为了处理其搜索引擎中的大规模网页文件而开发了MapReduce并行处理技术，并在OSDI会议上发表了题为“MapReduce：Simplified ［2］Data Processing on Large Clusters”的论文。Doug Cutting看到此论文后大受启发，在Apache Nutch项目中根据Google的设计思想开发了一套新的MapReduce并行处理系统，并将其与Nutch的分布式文件系统NDFS相结合，用以服务Nutch项目中搜索引擎的数据处理。2006年，NDFS和MapReduce从Nutch项目中独立出来，被重新命名为Hadoop，Apache Hadoop项目正式启动以支持其发展。同年，Hadoop 0.1.0版本发布。2008年，Hadoop成了Apache上的顶级项目，发展到今天，Hadoop已经成了主流的大数据处理平台，与Spark、HBase、Hive、Zookeeper等项目一同构成了大数据分析和处理的生态系统。Hadoop是一个由超过60个子系统构成的系统集合。实际使用的时候，企业通过定制Hadoop生态系统（即选择相应的子系统）完成其实际大数据管理需求。Hadoop生态系统由两大核心子系统构成：HDFS分布式文件系统和MapReduce数据处理系统。2.2.2 HDFS分布式文件系统
HDFS是一个可扩展的分布式文件系统，它为海量的数据提供可靠的存储。HDFS的架构是基于一组特定的节点构建的，其中包括一个NameNode节点和数个DataNode节点。NameNode主要负责管理文件系统名称空间和控制外部客户机的访问，它对整个分布式文件系统进行总控制，记录数据分布存储的状态信息。DataNode则使用本地文件系统来实现HDFS的读写操作。每个DataNode都保存整个系统数据中的一小部分，通过心跳协议定期向NameNode报告该节点存储的数据块的状况。为了保证系统的可靠性，在DataNode发生宕机时不致文件丢失，HDFS会为文件创建复制块，用户可以指定复制块的数目，默认情况下，每个数据块拥有额外两个复制块，其中一个存储在与该数据块同一机架的不同节点上，而另一复制块存储在不同机架的某个节点上。
所有对HDFS文件系统的访问都需要先与NameNode通信来获取文件分布的状态信息，再与相应的DataNode节点通信来进行文件的读写。由于NameNode处于整个集群的中心地位，当NameNode节点发生故障时整个HDFS集群都会崩溃，因此HDFS中还包含了一个Secondary NameNode，它与NameNode之间保持周期通信，定期保存NameNode上元数据的快照，当NameNode发生故障而变得不可用时，Secondary NameNode可以作为备用节点顶替NameNode，使集群快速恢复正常工作状态。
NameNode的单点特性制约了HDFS的扩展性，当文件系统中保存的文件过多时NameNode会成为整个集群的性能瓶颈。因此在Hadoop 2.0中，HDFS Federation被提出，它使用多个NameNode分管不同的目录，使得HDFS具有横向扩展的能力。2.2.3 MapReduce数据处理系统
MapReduce是位于HDFS文件系统上一层的计算引擎，它由JobTracker和TaskTracker组成。JobTracker是运行在Hadoop集群主节点上的重要进程，负责MapReduce的整体任务调度。同NameNode一样，JobTracker在集群中也具有唯一性。TaskTracker进程则运行在集群中的每个子节点上，负责管理各自节点上的任务分配。
当外部客户机向MapReduce引擎提交计算作业时，JobTracker将作业切分成一个个小的子任务，并根据就近原则，把每个子任务分配到保存了相应数据的子节点上，并由子节点上的TaskTracker负责各自子任务的执行，并定期向JobTracker发送心跳来汇报任务执行状态。
以上介绍的是Hadoop 1.0版本中MapReduce的架构，但其自身面临着许多局限。其一，JobTracker的单点故障会导致整个计算任务的失败；其二，JobTracker由于需要负责所有TaskTracker的执行状态和每个子节点的资源利用情况，系统的可扩展性低；其三，根据子节点中存放资源的数量来分配作业的方式不利于整个系统的负载均衡。
为了解决上述的问题，Hadoop 2.0对MapReduce的架构加以改造，对JobTracker所负担的任务分配和资源管理两大职责进行分离，在原本的底层HDFS文件系统和MapReduce计算框架之间加入了新一代架构设计——YARN。Hadoop 1.0与Hadoop 2.0架构对比如图2-1所示。YARN是一个通用的资源管理系统，为上层的计算框架提供统一的资源管理和调度。在新的架构中，ResourceManager负责整个集群资源的管理和分配，而不需要对作业进行状态追踪；NodeManager则运行于每个子节点上，对各个节点进行自管理，分担了ResourceManager的职责。任务分配的职责也从原本的JobTracker中独立出来，由ApplicationMaster来负责，并在NodeManager控制的资源容器中运行。每个应用程序都有其专门的ApplicationMaster，负责向ResourceManager索要适当的资源容器，运行任务以及跟踪应用程序执行状态。图2-1 Hadoop 1.0与Hadoop 2.0架构对比
YARN新架构采用的责任下放思路使得Hadoop 2.0拥有更高的扩展性，资源的动态分配也极大提升了集群资源利用率。不仅如此，ApplicationMaster的加入使得用户可以将自己的编程模型运行于Hadoop集群上，加强了系统的兼容性和可用性。
HDFS和MapReduce是Hadoop生态系统中的核心组件，提供基本的大数据存储和处理能力。以上述两个核心组件为基础，Hadoop社区陆续开发出一系列子系统完成其他大数据管理需求，这些子系统和HDFS、MapReduce一起共同构成了Hadoop生态系统。图2-2显示了HortonWorks公司发布的Hadoop生态系统的系统架构。图2-2 Hadoop生态系统结构组成
综上概括，Hadoop生态系统为用户提供的是一套可以用来组装自己的个性化数据管理系统的工具，用户根据自己的数据特征和应用需求，对一系列的部件进行有机地组装和部署，就能得到一个完整可用的管理平台。如2.1.2节所述，传统数据库软件采用的“One size fits all”的理念在大数据时代已经不再适用，大数据处理对系统架构的灵活性、数据处理伸缩性、数据处理效率提出了更高的要求。Hadoop生态系统是开源社区对大数据5V挑战的解决方案，为大数据管理系统的后续发展奠定了良好的基础。2.3 面向领域的大数据管理系统2.3.1 什么是面向领域的大数据管理系统
Hadoop生态系统已经成为目前主流的大数据平台解决方案。不仅大型的互联网公司在他们的系统中部署了Hadoop工具，一些传统的企业也选择Hadoop平台进行日志分析等工作。随着该生态系统的不断完善，Hadoop为它的用户提供了更多更方便的数据处理工具。然而，随着大数据应用种类的进一步扩大，Hadoop生态系统的局限性也逐步显现出来。
Hadoop呈现在用户面前的是一个处理问题的框架，是一个等待被组装的零件集合。要得到一个健全可用的数据处理平台，需要用户根据个性化需求自己进行构建。尽管用户可以结合多种多样的组件来满足不同的数据处理需求，但在这些组件中的数据流动并不是自动化的，需要人工手写很多脚本代码去实现数据传递和数据转换。这是Hadoop系统的问题之一。
随着更多的查询引擎被加入到Hadoop生态系统中，用户开始逐渐使用Hive和Pig等高级编程框架来进行查询，而不再是直接写底层的MapReduce代码。高级查询语言的优势在于提供高层次的抽象，使得查询过程更为简单，但问题在于，Hive与Pig是建立在MapReduce查询引擎之上的，它们最终还是转化为Map与Reduce两种操作，而不能提供关系数据库中丰富的关系代数算子，制约着查询分析能力的扩展，而且这样的中间转化过程不利于系统性能的最优化。
由于Hadoop生态系统过于通用，企业需要复杂的定制过程才能实际部署。当企业的大数据处理需求相对固定，并且只需要Hadoop生态系统中的一小部分组件时，许多研究者选择脱离Hadoop生态圈，转而开发新的大数据管理系统。这类面向特定垂直应用领域的大数据管理系统称为面向领域的大数据管理系统。与Hadoop的高度定制化不同，这类系统虽然具备一定的通用性，但无需进行复杂的定制和配［4］置就可以实际部署。我们以AsterixDB为例介绍面向领域的大数据管理系统。
AsterixDB是一个从2009年开始发起的开源项目，其设计之初就旨在结合传统数据库系统与Hadoop这类分布式系统各自的优势，实现一个具备如下特征的系统：
①采用灵活的半结构化数据模型，既能处理有schema定义的数据，也能处理无schema定义的数据；
②拥有与SQL相媲美的查询能力；
③有强大的并行处理能力；
④支持数据管理和自动索引；
⑤能够处理各种规模的查询；
⑥支持处理连续的数据流；
⑦具备良好的扩展性；
⑧能够处理常见的大数据类型。
AsterixDB的开发者提出的口号是“One size fits a bunch”，他们不要求新的大数据系统能够处理所有的问题，但要求至少在某些领域具备通用性。与Hadoop拼装组件的方式不同，AsterixDB为用户提供的是一个整体性更强的系统，它本身具备完善的功能，也更容易管理。AsterixDB的性能也许比不上那些深度定制的系统，但其目标是在相对更广阔的应用场景中发挥出令人满意的性能。2.3.2 面向领域的大数据管理系统架构
图2-3显示了AsterixDB的系统架构。数据通过批量加载、数据流和插入查询等方式进入到集群存储中；集群控制器为外部访问集群提供接口，数据导入、用户查询、结果返回都是通过集群控制器进行的。集群中的节点控制器和MD节点控制器分别提供数据和元数据的底层存储。图2-3 AsterixDB的系统架构
图2-4显示AsterixDB的软件堆栈。集群控制器通过一个基于HTTP的编程接口接受来自于外部客户端的查询命令，用户可以使用AQL查询语言来进行查询操作。AQL是由AsterixDB团队基于XQuery开发的查询语言，适用于半结构化数据的处理。当AQL语句被传入到集群控制器之后，它被AQL编译器转化为一系列的Hyracks任务，任务执行器将这些任务分配给对应的节点控制器。节点控制器主要有两个职责，一是管理各自节点上的数据，二是执行由任务执行器分配的任务。图2-4 AsterixDB的软件堆栈
下面我们从存储索引、事务处理和计算引擎方面具体介绍AsterixDB。（1）数据存储与索引
AsterixDB使用日志归并（log-structured merge，LSM）树来实现大数据存储和索引。LSM树被分为两部分，一部分存储在内存中，另一部分存储在磁盘上。新插入的记录先被保存在内存中的LSM树上，随着插入数据量不断增加达到一个阈值时，缓存被清空，内存中的树被写到磁盘上，新写入到磁盘上的LSM树定期与老的LSM树进行归并。这样的方式带来的好处是，从内存到磁盘上的写入过程都是批量进行的，避免了随机读写造成的额外I/O开支。因此AsterixDB可以支持高效率的流数据连续处理。
另外，AsterixDB支持对外部数据的处理，为了提高效率，AsterixDB不需要将外部数据集拷贝到自己内部存储中。以HDFS文件系统为例，查询编译器通过与HDFS的NameNode交换信息，把查询任务发送到对应的节点上，从而在相应的数据上执行操作。（2）事务处理
AsterixDB中的并发事务处理是通过2PL协议进行控制的，所有的锁都是在节点内部，没有分布式的锁，并且只有在用主索引对记录进行修改的时候上锁才是必要的，这就允许通过使用不同的索引进行高并发度的访存。但这也可能会引起数据的不一致性——如果在使用二级索引读取记录的时候，有其他程序使用主索引修改相应数据，那么读操作得到的结果是非一致的。为了解决这个问题，使用二级索引查找数据的时候需要同时获取该数据的主索引，另外在获得返回值之后，需要检查其是否满足二级索引搜索的条件。（3）编译优化
在对查询语句进行处理的过程中，AsterixDB先使用编译器对用户的AQL语句进行编译，将查询过程转化为Algebricks代数（相当于关系数据库中的关系代数），之后使用优化器对Algebricks代数表示的查询过程进行优化重组得到具体的查询计划，最后查询计划被转化成Hyracks任务，并由Hyracks引擎负责执行。（4）Hyracks计算引擎
AsterixDB使用Hyracks作为其底层计算引擎，负责执行由AQL语句编译优化之后得到的Hyracks任务。任务以DAG（directed acyclic graph，有向无环图）的形式被提交到Hyracks中。DAG的每一个节点对应于一个操作算符，连接器代表节点之间的边。AsterixDB目前支持53种操作算符和6种连接器。操作算符负责将输入块进行相应的操作之后得到输出块，连接器对输出块中的数据进行重分配，为下一个操作算符提供输入块。DAG将查询任务有序地组织起来，供Hyracks执行。
一系列的系统性能测试表明，相对于Hive和Mongo这样的成熟的数据处理工具，AsterixDB具有很强的竞争力，无论是各种类型的查询操作，还是数据的批量插入，AsterixDB的处理效率并不落下风。作为一个新的大数据系统，AsterixDB的表现是令人十分满意的。在经过进一步的系统优化之后，AsterixDB的性能还有很大的提升空间。参考文献［1］ Codd E F. A relational model of data for large shared data banks［J］. Communications of the ACM，1970，13（6）：377-387.［2］ Dean J，Ghemawat S. MapReduce：simplified data processing on large clusters［J］. Communications of the ACM，2008，51（1）：107-113.［3］ White T. Hadoop：The definitive guide［M］. “O’Reilly Media，Inc. ”，2012.［4］ Alsubaiee S，Altowim Y，Altwaijry H，et al. AsterixDB：A scalable，open source BDMS［J］. Proceedings of the VLDB Endowment，2014，7（14）：1905-1916.第3章 大数据模型
大数据的重要特征是数据类型多。大数据管理系统采用分而治之的方式，通过为每种类型的数据建立特定数据模型的方法，解决数据类型多所带来的挑战。本章介绍大数据管理系统支持的常见数据模型。3.1 关系数据模型3.1.1 关系数据模式
关系数据模式用表的集合来表示数据和数据间的关系，它具有以下特征：
•具有严格的数学理论基础。
•数据结构简单清晰。
•优点：数据具有高度一致性，易于管理和维护；可使用通用的SQL查询语言进行数据查询分析。
•缺点：无法表示复杂的数据类型；可扩展性较差。3.1.2 关系大数据存储模型
关系数据库是由表的集合构成的，表中的每一行称为一个元组，表中的列称作属性，属性上取值范围称为该属性的域。在一个关系（表）中，超键是一个或多个属性的集合，该集合唯一标识该关系中元组的属性的组合，使得任何两个关系不同的元组在该属性组合上的取值都不同。对于某些超键，它的任何真子集都不能成为超键，那么这样的超键被称为候选键。主键是被指定的一个候选键，用来区分关系中的不同元组，我们通常说的键指的是主键。在关系数据模型中，一个关系r中的属性A可能会包括另一个关系r的主键，在这种情况12下，属性A在r中称作参照r的外键，r是该外键的参照关系，而r是1212被参照关系。参照完整性约束规定，在参照关系中的任何一个元组的外键上的取值必须等于被参照关系中某个元组在该属性上的值。
在关系模型中，表的模式也叫做关系模式，它是由属性序列及各属性的域组成的。关系模式在创建表的时候就已经确定，向表中导入的每条记录（即每个元组）都需要在属性的域上满足关系模式中的约束条件。3.1.3 查询语言
在关系数据库中，SQL是使用最为广泛的结构化查询语言，主要的关系数据库系统都支持SQL语言来对数据进行查询。但需要注意的是，在不同的数据库实现中，开发商都对SQL标准进行了各自的改编扩展，因此它们对SQL的支持也会有些不同，支持的语法也不完全一致，在不同的数据库系统中，SQL不能完全通用。
作为一种结构化的查询语言，SQL允许用户在不关心底层数据存储的情况下，只对高层数据结构进行操作和查询，它包含了数据定义语言（DDL）和数据操纵语言（DML）两部分。数据定义语言提供了定义关系模式、删除关系模式以及修改关系模式的命令；而数据操纵语言包括了查询语言，以及往数据库中插入元组、删除和修改元组的命令。SQL基本查询包括三个子句：select、from和where。select指定输出结果中所包含的属性列表和聚集运算，from指定查询输入中的关系，where指定在关系上进行的运算。SQL查询的输出结果是一个关系，它可以作为子句嵌套到其他SQL查询中。SQL语言还支持连接、集合运算、聚集函数等运算，为数据查询分析提供了丰富的功能。3.1.4 典型系统
MySQL是中小型数据库，由于其体积小、源码开放等特点，受到了个人使用者和中小型企业开发者的欢迎。但在处理大规模数据时，相比于其他的大型商业化数据库，MySQL的数据处理能力就略显不足了。
Oracle数据库是由甲骨文公司开发的关系型数据库管理系统，是一种高效率、高可靠性、高吞吐量的数据库解决方案。Oracle数据库提供了完整的数据管理功能，能够对大量数据进行永久性存储，并保证数据的可靠性和共享性。在处理大数据方面，Oracle数据库提供了完善的分布式数据库功能，Oracle RAC支持多达100个集群节点，极大增强了系统的可用性和可扩展性。
虽然分布式的关系数据库能够通过加入新的节点来增大存储容量，但是由于数据查询的时候经常需要将多个表进行连接操作，随着数据量的不断增大，查询延迟也会越来越大，数据库系统的整体性能也随之下降。因此在处理海量数据的时候，关系数据库有其本质上的局限性。3.2 键值数据模型3.2.1 键值数据模式
键值数据模式按照键值对的形式对数据进行存储和索引，它具有以下特征：
•通过键来获取数据对象。
•值可以存储各种类型的数据，如视频和图像等。
•优点：容易扩展，并且有着简单的应用程序编程接口（get、put和delete）。
•缺点：不能根据值域来生成查询。3.2.2 键值数据存储模型
在键值数据存储中，数据是用键值对来表示的，每个键值对表示一个属性名和它对应的值。键值存储中的每条记录都可以包含任意数量的属性，每个属性可以是一个对象、一个单值，或是一个集合。这些条目的集合就构成了键值存储中的表。与关系数据模型不同，键值数据存储不需要事先定义表的模式，用户可以灵活地为表中的每条记录添加属性和它对应的值。在用户创建一个表的时候，除了表的名称之外，还需要指定表的主键，它是表中每个条目的唯一标识。例如，在一个键值存储的产品列表中，表名加上产品ID构成了表中每个产品的主键，它保证表中不同的产品对应不同产品ID。
在键值数据存储模型中，主键有两种类型：
•分区键：这是一种由单个属性构成的简单主键，它决定了条目被存储的分区。不同的条目不能拥有相同的分区键。
•分区排序键：这种键包含两个属性，一个属性是分区键，另一个是排序键。分区键决定了条目存储的位置，排序键决定了如何对条目进行排序。拥有相同分区键的条目被存储在一起，不同的条目可以有相同的分区键，但是它们的排序键不能重复。3.2.3 查询语言
与关系数据库不同，非关系型数据库没有统一的查询语言，根据数据模型的不同，需要使用不同的方式来对数据进行查询。键值存储模型为用户提供了简单的应用程序编程接口：
•get（key）：获取键为key的条目对应的值。
•put（key，value）：向数据库中插入一条记录，其键和值分别为key和value。
•delete（key）：删除键为key的条目。
除了这些基本的数据操作接口，根据具体实现的不同，各种键值数据库还可能提供对列表和集合的操作函数，用户可以根据这些接口来创建和管理更为复杂的数据类型。很多编程语言都提供了对不同键值数据库的支持，可以参考具体的编程语言来查看管理和使用键值数据库的方法。3.2.4 典型系统
Redis是一款可基于内存也可持久化的数据库，相比于其他键值数据库而言，它支持丰富的数据类型，包括字符串、哈希、链表、集合和有序集合等，并且提供交、并、差等集合操作。Redis中的所有操作都是原子操作，并提供多个编程语言接口。
在3.0版本以前，Redis只支持单例模式，数据库容量受到物理内存的限制，使得Redis主要局限于数据量较小的应用场景。直到3.0正式版本于2015年发布之后，Redis开始支持集群，最多可以在集群中配置1000个节点，能够承受更多的并发访问。
作为一款内存数据库，Redis的低延时特性使其十分适合用作缓存层组件，同时，它的高吞吐、数据结构丰富的特点也适合OLTP场景。3.3 列族数据模型3.3.1 列族数据模式
列族数据模式具有以下特点：
•键包括了一行、一个列族和一个列名；
•将版本化的二进制文件对象存储在一个大的表格中；
•可以使用列名、列族和行进行数据查询；
•优点：良好的扩展性和版本控制；
•缺点：列式存储设计十分重要，无法根据二进制对象的内容进行查询。3.3.2 列族数据存储模型
在列族数据存储模型中，数据是存储在行和列中的。这里所说的行和列不同于关系数据库，在列式数据库中，数据模型是多维的，它包含了以下概念。
①表——表是由许多行构成的。
②行——每一行包括一个行键和多个列。列族存储使用行键的字母序来对行进行存储，其目的在于将有关联的行保存在一起。这就使得行键的设计尤其重要，举个例子来说，对于如下两个网站域名：maps.google.com和google.com，使用倒序来存储域名就是一个明智的设计，它会让这些有关联的域名聚集在一起；否则的话，它们就会被分散存储在不同的位置。
③列——列包含了两个部分：列族和列修饰符，它们之间用冒号分隔。表中的每一行都有相同的列族，列族拥有一系列与存储有关的属性，包括了数据压缩、内存缓存和编码属性等。列族的设计是为了在物理上将成员列与它们的值并置存储，从而优化系统性能。列修饰符为数据提供了索引。例如，如果一个列族的内容是.pdf，那么修饰符就是pdf；如果列族的内容是图片，那么修饰符就是gif。列修饰符是可编辑的，并且不同行的列修饰符可能是不同的，但列族在表创建之后就固定不变了。
④单元格——单元格是由数据的值构成的。一个单元格由行、列族和列修饰符的组合所确定，它包括了数据的值和时间戳。时间戳表示了数据被写入或更新时的系统时间，它与数据的值存储在一起。3.3.3 查询语言
在列族数据库中，用户需要通过使用行键、行键+时间戳或行键+列（列族：列修饰符）的方式定位特定的数据，从而对数据进行查询和操作。
熟悉SQL语言的开发人员对列族数据库提供的查询方式比较陌生，于是人们开发了相应的中间层来连接列族数据库与人们熟悉的SQL查询语言。以Phoenix为例，它为NoSQL数据库HBase提供了标准的SQL和JDBC接口，帮助开发者轻松地使用NoSQL数据库，让他们既能享受NoSQL数据库提供的高性能存储，又能以传统的SQL方式进行查询操作。3.3.4 典型系统
HBase是一个分布式的、面向列的开源数据库，它是根据Google的BigTable开发的，在Hadoop集群上实现了类似于Bigtable的功能。HBase为用户提供了高可靠性、高性能、高可扩展性的分布式存储解［1］决方案，适用于非结构化数据的存储。HBase运行于HDFS集群之上，其低延迟的读写特性适合用来进行大数据的实时查询，它能够处理PB级别的数据量，吞吐量能达到每秒百万条查询。HBase本身只提供了Java的API接口，不支持SQL语句，需要联合Phoenix等工具来支持SQL查询。
HBase适用于处理超大数据量的半结构化或非结构化数据，在需要强大吞吐能力和水平扩展能力的应用中，HBase是不错的选择，但它不支持事务、连接等关系数据库特性，不适合应对事务要求高、多维度查询的应用。目前HBase为用户提供了以下接口。
•Native Java API——最常规和高效的访问方式，适合Hadoop MapReduce Job对HBase 表数据进行并行批处理。
试读结束[说明：试读内容隐藏了图片]