大数据管理：概念、技术与挑战
孟小峰 慈 祥 （中国人民大学信息学院 北京 １００８７２）
摘 要 云计算、物联网、社交网络等新兴服务促使人类社会的数据种类和规模正以前所未有的速度增 长，大数据时代正式到来．数据从简单的处理对象开始转变为一种基础性资源，如何更好地管理和利用 大数据已经成为普遍关注的话题．大数据的规模效应给数据存储、管理以及数据分析带来了极大的挑 战，数据管理方式上的变革正在酝酿和发生．对大数据的基本概念进行剖析，并对大数据的主要应用作 简单对比．在此基础上，阐述大数据处理的基本框架，并就云计算技术对于大数据时代数据管理所产生 的作用进行分析．最后归纳总结大数据时代所面临的新挑战． 关键词 大数据；数据分析；云计算 中图法分类号 ＴＰ３１１
随着以博客、社交网络、基于位置的服务ＬＢＳ 为代表的新型信息发布方式的不断涌现，以及云计 算、物联网等技术的兴起，数据正以前所未有的速度 在不断地增长和累积，大数据时代已经来到．学术 界、工业界甚至于政府机构都已经开始密切关注大 数据问题，并对其产生浓厚的兴趣．就学术界而言， 《 Ｎａｔｕｒｅ》早在２００８年就推出了Ｂｉ ｇ Ｄａｔａ专刊［ １］．计 算社区联盟（Ｃｏｍｐｕｔｉｎｇ Ｃｏｍｍｕｎｉｔ ｙ Ｃｏｎｓｏｒｔｉｕｍ） 在２００８年发表了报告“Ｂｉ ｇ ｄａｔａ ｃｏｍｐｕｔｉｎｇ：Ｃｒｅａｔｉｎｇ ｒｅｖｏｌｕｔｉｏｎａｒ ｙ ｂｒｅａｋｔｈｒｏｕｇｈｓ ｉｎ ｃｏｍｍｅｒｃｅ，ｓｃｉｅｎｃｅ，
ａｎｄ ｓｏｃｉｅｔ ｙ” ［ ２］，阐述了在数据驱动的研究背景下， 解决大数据问题所需的技术以及面临的一些挑战． 《 Ｓｃｉｅｎｃｅ》在２０１１年２月推出专刊“Ｄｅａｌｉｎｇ ｗｉｔｈ Ｄａｔａ” ［ ３］，主要围绕着科学研究中大数据的问题展 开讨论，说明大数据对于科学研究的重要性．美国 一些知名的数据管理领域的专家学者则从专业的研 究角度出发，联合发布了一份白皮书《Ｃｈａｌｌｅｎｇｅｓ ａｎｄ Ｏｐｐｏｒｔｕｎｉｔｉｅｓ ｗｉｔｈ Ｂｉ ｇ Ｄａｔａ》 ［ ４］．该白皮书从学 术的角度出发介绍了大数据的产生，分析了大数据 的处理流程，并提出大数据所面临的若干挑战全球知名的咨询公司麦肯锡（ＭｃＫｉｎｓｅｙ）２０１１ 年６月份发布了一份关于大数据的详尽报告“Ｂｉ ｇ ｄａｔａ：Ｔｈｅ ｎｅｘｔ ｆｒｏｎｔｉｅｒ ｆｏｒ ｉｎｎｏｖａｔｉｏｎ，ｃｏｍｐｅｔｉｔｉｏｎ， ａｎｄ ｐｒｏｄｕｃｔｉｖｉｔ ｙ” ［ ５］，对大数据的影响、关键技术和 应用领域等都进行了详尽的分析．进入２０１２年以 来，大数据的关注度与日俱增．１月份的达沃斯世界 经济论坛上，大数据是主题之一，该次会议还特别针 对大数据发布了报告“Ｂｉ ｇ ｄａｔａ，ｂｉ ｇ ｉｍｐａｃｔ：Ｎｅｗ ｐｏｓｓｉｂｉｌｉｔｉｅｓ ｆｏｒ ｉｎｔｅｒｎａｔｉｏｎａｌ ｄｅｖｅｌｏｐｍｅｎｔ” ［ ６］，探讨 了新的数据产生方式下，如何更好地利用数据来产 生良好的社会效益．该报告重点关注了个人产生的 移动数据与其他数据的融合与利用．３月份美国奥 巴马政府发布了“大数据研究和发展倡议” ［ ７］（Ｂｉ ｇ ｄａｔａ ｒｅｓｅａｒｃｈ ａｎｄ ｄｅｖｅｌｏｐｍｅｎｔ ｉｎｉｔｉａｔｉｖｅ），投资２亿 以上美元，正式启动“大数据发展计划”．计划在科 学研究、环境、生物医学等领域利用大数据技术进 行突破．奥巴马政府的这一计划被视为美国政府 继信息高速公路（Ｉｎｆｏｒｍａｔｉｏｎ Ｈｉ ｇｈｗａ ｙ）计划之后 在信息科学领域的又一重大举措．与此同时，联合 国一个名为“Ｇｌｏｂａｌ Ｐｕｌｓｅ”的倡议项目在今年５月 发布报告“Ｂｉ ｇ ｄａｔａ ｆｏｒ ｄｅｖｅｌｏｐｍｅｎｔ：Ｃｈａｌｌｅｎｇｅｓ ＆ ｏｐｐｏｒｔｕｎｉｔｉｅｓ” ［ ８］，该报告主要阐述大数据时代各国 特别是发展中国家在面临数据洪流（ｄａｔａ ｄｅｌｕｇｅ）的 情况下所遇到的机遇与挑战，同时还对大数据的应 用进行了初步的解读．《纽约时报》的文章“Ｔｈｅ ａｇｅ ｏｆ ｂｉ ｇ ｄａｔａ” ［ ９］则通过主流媒体的宣传使普通民众开 始意识到大数据的存在，以及大数据对于人们日常 生活的影响． 大数据的火热并不意味着对于大数据的了解深 入，反而表明大数据存在过度炒作的危险．大数据的 基本概念、关键技术以及对其利用上均存在很多的 疑问和争议．本文从大数据问题背后的本质出发，对 现有的大数据研究资料进行全面的归纳和总结．首 先简要介绍大数据的基本概念，阐述其同传统数据 库的区别．在此基础上，对大数据处理框架进行详细 解析．我们认为大数据的发展离不开云计算技术，云 计算支撑着大数据存储、管理以及数据分析等．因此 本文展开介绍了大数据时代不可或缺的云计算技术 和工具．最后全面阐述大数据时代面临的新挑战．
１ 大数据的基本概念、来源与应用
１．１ 大数据的基本概念 大数据本身是一个比较抽象的概念，单从字面
来看，它表示数据规模的庞大．但是仅仅数量上的庞 大显然无法看出大数据这一概念和以往的“海量数 据”（ｍａｓｓｉｖｅ ｄａｔａ）、“超大规模数据”（ｖｅｒ ｙ ｌａｒ ｇｅ ｄａｔａ）等概念之间有何区别．对于大数据尚未有一个 公认的定义，不同的定义基本是从大数据的特征出 发，通过这些特征的阐述和归纳试图给出其定义．在 这些定义中，比较有代表性的是３Ｖ定义［１０］，即认为 大数据需满足３个特点：规模性（ｖｏｌｕｍｅ）、多样性 （ ｖａｒｉｅｔ ｙ）和高速性（ｖｅｌｏｃｉｔ ｙ）．除此之外，还有提出 ４Ｖ定义的，即尝试在３Ｖ的基础上增加一个新的特 性．关于第４个 Ｖ 的说法并不统一，国际数据公司 （ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｄａｔａ Ｃｏｒ ｐｏｒａｔｉｏｎ，ＩＤＣ）认为大数据 还应当具有价值性（ｖａｌｕｅ） ［ １１］，大数据的价值往往呈 现出稀疏性的特点．而ＩＢＭ 认为大数据必然具有真 实性（ｖｅｒａｃｉｔ ｙ） ［ １２］．维基百科对大数据的定义［１３］则 简单明了：大数据是指利用常用软件工具捕获、管理 和处理数据所耗时间超过可容忍时间的数据集． 眼下在大数据定义问题上很难达成一个完全的 共识，这点和云计算的概念刚提出时的情况是相似 的．在面对实际问题时，不必过度地拘泥于具体的定 义之中，在把握３Ｖ定义的基础上适当地考虑４Ｖ特 性即可． １．２ 从数据库（ｄａｔａｂａｓｅ，ＤＢ）到大数据（ｂｉ ｇ ｄａｔａ， ＢＤ） 从数据库到大数据，看似只是一个简单的技术 演进，但细细考究不难发现两者有着本质上的差别． 大数据的出现必将颠覆传统的数据管理方式．在数 据来源、数据处理方式和数据思维等方面都会对其 带来革命性的变化． 如果要用简单的方式来比较传统的数据库和大 数据的区别，我们认为“池塘捕鱼”和“大海捕鱼”是 个很好的类比．“池塘捕鱼”代表着传统数据库时代 的数据管理方式，而“大海捕鱼”则对应着大数据时 代的数据管理方式，“鱼”是待处理的数据．“捕鱼”环 境条件的变化导致了“捕鱼”方式的根本性差异．这 些差异主要体现在如下几个方面： １）数据规模．“池塘”和“大海”最容易发现的区 别就是规模．“池塘”规模相对较小，即便是先前认为 比较大的“池塘”，譬如 ＶＬＤＢ（ｖｅｒ ｙ ｌａｒ ｇ ｅ ｄａｔａｂａｓｅ）， 和“大海”ＸＬＤＢ（ｅｘｔｒｅｍｅｌ ｙ ｌａｒ ｇ ｅ ｄａｔａｂａｓｅ）相比仍旧偏 小． “池塘”的处理对象通常以 ＭＢ为基本单位，而“大 海”则常常以ＧＢ，甚至是ＴＢ，ＰＢ为基本处理单位． ２）数据类型．过去的“池塘”中，数据的种类单 一，往往仅仅有一种或少数几种，这些数据又以结构
化数据为主．而在“大海”中数据的种类繁多，数以千 计，而这些数据又包含着结构化、半结构化以及非结 构化的数据，并且半结构化和非结构化数据所占份 额越来越大． ３）模式（ｓｃｈｅｍａ）和数据的关系．传统的数据库 都是先有模式，然后才会产生数据．这就好比是先选 好合适的“池塘”，然后才会向其中投放适合在该“池 塘”环境生长的“鱼”．而大数据时代很多情况下难以 预先确定模式，模式只有在数据出现之后才能确定， 且模式随着数据量的增长处于不断的演变之中．这 就好比先有少量的鱼类，随着时间推移，鱼的种类和 数量都在不断地增长．鱼的变化会使大海的成分和 环境处于不断的变化之中． ４）处理对象．在“池塘”中捕鱼，“鱼”仅仅是其 捕捞对象．而在“大海”中，“鱼”除了是捕捞对象之 外，还可以通过某些“鱼”的存在来判断其他种类的 “鱼”是否存在．也就是说传统数据库中数据仅作为 处理对象．而在大数据时代，要将数据作为一种资源 来辅助解决其他诸多领域的问题． ５）处理工具．捕捞“池塘”中的“鱼”，一种渔网 或少数几种基本就可以应对，也就是所谓的 Ｏｎｅ
ｓｉｚｅ ｆｉｔｓ ａｌｌ．但是在“大海”中，不可能存在一种渔网 能够捕获所有的鱼类，也就是说Ｎｏ ｓｉｚｅ ｆｉｔｓ ａｌｌ． 从“池塘”到“大海”不仅仅是规模的变大．传统 的数据库代表着数据工程（ｄａｔａ ｅｎｇｉｎｅｅｒｉｎｇ）的处理 方式，大数据时代的数据已不仅仅只是工程处理的
对象，需要采取新的数据思维来应对．图灵奖获得 者、著名数据库专家Ｊｉｍ Ｇｒａｙ博士观察并总结人类 自古以来，在科学研究上，先后历经了实验、理论和 计算３种范式．当数据量不断增长和累积到今天，传 统的３种范式在科学研究，特别是一些新的研究领 域已经无法很好地发挥作用，需要有一种全新的第 ４种范式来指导新形势下的科学研究．基于这种考 虑，Ｊｉｍ Ｇｒａｙ提出了一种新的数据探索型研究方 式，被他自己称之为科学研究的“第４种范式”（Ｔｈｅ Ｆｏｕｒｔｈ Ｐａｒａｄｉ ｇｍ） ［ １４］． ４种范式的比较如表１［１４］所示．第４种范式的 实质就是从以计算为中心转变到以数据处理为中 心，也就是我们所说的数据思维．这种方式需要我们 从根本上转变思维．正如前面提到的“捕鱼”，在大数 据时代，数据不再仅仅是“捕捞”的对象，而应当转变 成一种基础资源，用数据这种资源来协同解决其他 诸多领域的问题．计算社会科学（ｃｏｍｐｕｔａｔｉｏｎａｌ ｓｏｃｉａｌ ｓｃｉｅｎｃｅ） ［ １５］基于特定社会需求，在特定的社会理论 指导下，收集、整理和分析数据足迹（ｄａｔａ ｐｒｉｎｔ），以 便进行社会解释、监控、预测与规划的过程和活动． 计算社会科学是一种典型的需要采用第４种范式来 作指导的科学研究领域．Ｗａｔｔｓ在《Ｎａｔｕｒｅ》杂志上的 文章“ Ａ ｔｗｅｎｔ ｙ － ｆｉｒｓｔ ｃｅｎｔｕｒ ｙ ｓｃｉｅｎｃｅ” ［ １６］也指出，借 助于社交网络和计算机分析技术，２１世纪的社会科 学有可能实现定量化的研究，从而成为一门真正的 自然科学．
Ｔａｂｌｅ １ Ｆｏｕｒ Ｓｃｉｅｎｃｅ Ｐａｒａｄｉ ｇｍｓ 表１ 科学发现的４种范式
Ｓｃｉｅｎｃｅ Ｐａｒａｄｉ ｇｍｓ Ｔｉｍｅ Ｍｅｔｈｏｄｏｌｏｇｙ
Ｅｍｐｉｒｉｃａｌ Ｔｈｏｕｓａｎｄ ｙｅａｒｓ ａｇｏ Ｄｅｓｃｒｉｂｉｎｇ ｎａｔｕｒａｌ ｐｈｅｎｏｍｅｎａ
Ｔｈｅｏｒｅｔｉｃａｌ Ｌａｓｔ ｆｅｗ ｈｕｎｄｒｅｄ ｙｅａｒｓ Ｕｓｉｎｇ ｍｏｄｅｌｓ，ｇｅｎｅｒａｌｉｚａｔｉｏｎｓ
Ｃｏｍｐｕｔａｔｉｏｎａｌ Ｌａｓｔ ｆｅｗ ｄｅｃａｄｅｓ Ｓｉｍｕｌａｔｉｎｇ ｃｏｍｐｌｅｘ ｐｈｅｎｏｍｅｎａ
Ｄａｔａ Ｅｘｐｌｏｒａｔｉｏｎ （ ｅＳｃｉｅｎｃｅ）
Ｔｏｄａｙ
Ｄａｔａ ｃａｐｔｕｒｅｄ ｂｙ ｉｎｓｔｒｕｍｅｎｔｓ ｏｒ ｇｅｎｅｒａｔｅｄ ｂｙ ｓｉｍｕｌａｔｏｒ；Ｐｒｏｃｅｓｓｅｄ ｂｙ ｓｏｆｔｗａｒｅ；
Ｉｎｆｏｒｍａｔｉｏｎ ｓｔｏｒｅｄ ｉｎ ｃｏｍｐｕｔｅｒ；Ｓｃｉｅｎｔｉｓｔ ａｎａｌ ｙ ｚｅｓ ｄａｔａｂａｓｅ
１．３ 大数据的产生和应用 人类历史上从未有哪个时代和今天一样产生如 此海量的数据．数据的产生已经完全不受时间、地点 的限制．从开始采用数据库作为数据管理的主要方 式开始，人类社会的数据产生方式大致经历了３个 阶段，而正是数据产生方式的巨大变化才最终导致 大数据的产生． １）运营式系统阶段．数据库的出现使得数据管
理的复杂度大大降低，实际中数据库大都为运营系 统所采用，作为运营系统的数据管理子系统，比如超 市的销售记录系统、银行的交易记录系统、医院病人 的医疗记录等．人类社会数据量第１次大的飞跃正 是建立在运营式系统开始广泛使用数据库．这个阶 段最主要特点是数据往往伴随着一定的运营活动而 产生并记录在数据库中，比如超市每销售出一件产 品就会在数据库中产生相应的一条销售记录．这种
数据的产生方式是被动的． ２）用户原创内容阶段．互联网的诞生促使人类 社会数据量出现第２次大的飞跃．但是真正的数据 爆发产生于 Ｗｅｂ ２．０时代，而 Ｗｅｂ ２．０的最重要标 志就是用户原创内容（ｕｓｅｒ ｇ ｅｎｅｒａｔｅｄ ｃｏｎｔｅｎｔ，ＵＧＣ）． 这类数据近几年一直呈现爆炸性的增长，主要有两 方面的原因：首先是以博客、微博为代表的新型社交 网络的出现和快速发展，使得用户产生数据的意愿 更加强烈；其次就是以智能手机、平板电脑为代表的 新型移动设备的出现，这些易携带、全天候接入网络 的移动设备使得人们在网上发表自己意见的途径更 为便捷，这个阶段数据的产生方式是主动的． ３）感知式系统阶段．人类社会数据量第３次大 的飞跃最终导致了大数据的产生，今天我们正处于 这个阶段．这次飞跃的根本原因在于感知式系统的
广泛使用．随着技术的发展，人们已经有能力制造极 其微小的带有处理功能的传感器，并开始将这些设 备广泛地布置于社会的各个角落，通过这些设备来 对整个社会的运转进行监控．这些设备会源源不断 地产生新数据，这种数据的产生方式是自动的． 简单来说，数据产生经历了被动、主动和自动３ 个阶段．这些被动、主动和自动的数据共同构成了大 数据的数据来源，但其中自动式的数据才是大数据 产生的最根本原因． 正如 Ｇｏｏｇｌｅ的首席经济学家 Ｈａｌ Ｖａｒｉａｎ所 说［１７］，数据是广泛可用的，所缺乏的是从中提取出 知识的能力．数据收集的根本目的是根据需求从数 据中提取有用的知识，并将其应用到具体的领域之 中．不同领域的大数据应用有不同的特点，表２列举 了若干具有代表性的大数据应用及其特征：
Ｔａｂｌｅ ２ Ｃｏｍｐａｒｉｓｏｎ ｂｅｔｗｅｅｎ Ｔｙｐｉｃａｌ Ｂｉ ｇ Ｄａｔａ Ａｐｐｌｉｃａｔｉｏｎｓ 表２ 典型大数据应用的比较
Ａｐｐｌｉｃａｔｉｏｎｓ Ｅｘａｍｐｌｅｓ Ｎｕｍｂｅｒ ｏｆ Ｕｓｅｒｓ Ｒｅｓｐｏｎｓｅ Ｔｉｍｅ Ｄａｔａ Ｓｃａｌｅ Ｒｅｌｉａｂｉｌｉｔ ｙ Ａｃｃｕｒａｃ ｙ
Ｓｃｉｅｎｔｉｆｉｃ Ｃｏｍｐｕｔｉｎｇ Ｂｉｏｉｎｆｏｒｍａｔｉｃｓ Ｓｍａｌｌ Ｓｌｏｗ ＴＢ Ｍｏｄｅｒａｔｅ Ｖｅｒ ｙ Ｈｉ ｇｈ
Ｆｉｎａｎｃｅ Ｈｉ ｇｈ － ｆｒｅ ｑｕｅｎｃ ｙ ｔｒａｄｉｎｇ Ｌａｒ ｇｅ Ｖｅｒ ｙ Ｆａｓｔ ＧＢ Ｖｅｒ ｙ Ｈｉ ｇｈ Ｖｅｒ ｙ Ｈｉ ｇｈ
Ｓｏｃｉａｌ ｎｅｔｗｏｒｋ Ｆａｃｅｂｏｏｋ Ｖｅｒ ｙ Ｌａｒ ｇｅ Ｆａｓｔ ＰＢ Ｈｉ ｇｈ Ｈｉ ｇｈ
Ｍｏｂｉｌｅ Ｄａｔａ Ｍｏｂｉｌｅ ｐｈｏｎｅ Ｖｅｒ ｙ Ｌａｒ ｇｅ Ｆａｓｔ ＴＢ Ｈｉ ｇｈ Ｈｉ ｇｈ
Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ Ｓｅｎｓｏｒ ｎｅｔｗｏｒｋ Ｌａｒ ｇｅ Ｆａｓｔ ＴＢ Ｈｉ ｇｈ Ｈｉ ｇｈ
Ｗｅｂ Ｄａｔａ Ｎｅｗｓ ｗｅｂｓｉｔｅ Ｖｅｒ ｙ Ｌａｒ ｇｅ Ｆａｓｔ ＰＢ Ｈｉ ｇｈ Ｈｉ ｇｈ
Ｍｕｌｔｉｍｅｄｉａ Ｖｉｄｅｏ ｓｉｔｅ Ｖｅｒ ｙ Ｌａｒ ｇｅ Ｆａｓｔ ＰＢ Ｈｉ ｇｈ Ｍｏｄｅｒａｔｅ
正是由于大数据的广泛存在才使得大数据问题 的解决很具挑战性．而它的广泛应用则促使越来越 多的人开始关注和研究大数据问题．
２ 大数据处理框架
２．１ 大数据处理模式 大数据的应用类型有很多，主要的处理模式可 以分为流处理（ｓｔｒｅａｍ ｐｒｏｃｅｓｓｉｎｇ）和批处理（ｂａｔｃｈ ｐｒｏｃｅｓｓｉｎｇ）两 种［１８ －１９］．批处理是先存储后处理 （ ｓｔｏｒｅ － ｔｈｅｎ －ｐｒｏｃｅｓｓ），而流处理则是直接处理 （ ｓｔｒａｉ ｇｈｔ － ｔｈｒｏｕｇｈ ｐｒｏｃｅｓｓｉｎｇ）． ２．１．１ 流处理 流处理的基本理念是数据的价值会随着时间的 流逝而不断减少，因此尽可能快地对最新的数据作 出分析并给出结果是所有流数据处理模式的共同目 标．需要采用流数据处理的大数据应用场景主要有
网页点击数的实时统计、传感器网络、金融中的高频 交易等． 流处理的处理模式将数据视为流，源源不断的 数据组成了数据流．当新的数据到来时就立刻处理 并返回所需的结果．图１［１８］是流处理中基本的数据 流模型：
Ｆｉ ｇ．１ Ｂａｓｉｃ ｄａｔａ ｓｔｒｅａｍ ｍｏｄｅｌ． 图１ 基本的数据流模型 数据的实时处理是一个很有挑战性的工作，数 据流本身具有持续达到、速度快且规模巨大等特点， 因此通常不会对所有的数据进行永久化存储，而且
数据环境处在不断的变化之中，系统很难准确掌握 整个数据的全貌． 由于响应时间的要求，流处理的过程基本在内 存中完成，其处理方式更多地依赖于在内存中设计 巧妙的概要数据结构（ ｓｙｎｏｐｓｉｓ ｄａｔａ ｓｔｒｕｃｔｕｒｅ），内 存容量是限制流处理模型的一个主要瓶颈．以ＰＣＭ （相变存储器）为代表的储存级内存（ｓｔｏｒａｇｅ ｃｌａｓｓ ｍｅｍｏｒ ｙ，ＳＣＭ）设备的出现或许可以使内存未来不 再成为流处理模型的制约．
数据流的理论及技术研究已经有十几年的历 史，目前仍旧是研究热点．与此同时很多实际系统也 已开发和得到广泛的应用，比较代表性的开源系统 如Ｔｗｉｔｔｅｒ的Ｓｔｏｒｍ［２０］、Ｙａｈｏｏ的Ｓ４［２１］以及Ｌｉｎｋｅｄｉｎ 的 Ｋａｆｋａ［２２］等． ２．１．２ 批处理 Ｇｏｏｇｌｅ公司在２００４年提出的 ＭａｐＲｅｄｕｃｅ ［ ２３］ 编程模型是最具代表性的批处理模式．一个完整的 ＭａｐＲｅｄｕｃｅ过程如图２［２３］所示：
Ｆｉ ｇ．２ Ｅｘｅｃｕｔｉｏｎ ｏｖｅｒｖｉｅｗ ｏｆ ＭａｐＲｅｄｕｃｅ． 图２ ＭａｐＲｅｄｕｃｅ执行流程图 ＭａｐＲｅｄｕｃｅ模型首先将用户的原始数据源进 行分块，然后分别交给不同的 Ｍａ ｐ任务区处理．Ｍａ ｐ 任务从输入中解析出链?值（Ｋｅｙ ?Ｖａｌｕｅ）对集合，然 后对这些集合执行用户自行定义的 Ｍａｐ函数得到 中间结果，并将该结果写入本地硬盘．Ｒｅｄｕｃｅ任务 从硬盘上读取数据之后会根据ｋｅｙ值进行排序，将 具有相同 Ｋｅｙ值的组织在一起．最后用户自定义的 Ｒｅｄｕｃｅ函数会作用于这些排好序的结果并输出最 终结果． 从 ＭａｐＲｅｄｕｃｅ 的处理过程我们可以看出， ＭａｐＲｅｄｕｃｅ的核心设计思想在于： １）将问题分而治 之； ２）把计算推到数据而不是把数据推到计算，有效 地避免数据传输过程中产生的大量通信开销． ＭａｐＲｅｄｕｃｅ模型简单，且现实中很多问题都可用 ＭａｐＲｅｄｕｃｅ模型来表示．因此该模型公开后立刻受 到极大的关注，并在生物信息学、文本挖掘等领域得 到广泛的应用． 无论是流处理还是批处理都是大数据处理的可 行思路．大数据的应用类型很多，在实际的大数据处 理中，常常并不是简单地只使用其中的某一种，而是 将二者结合起来．互联网是大数据最重要的来源之 一，很多互联网公司根据处理时间的要求将自己的 业务划分为在线（ｏｎｌｉｎｅ）、近线（ｎｅａｒｌｉｎｅ）和离线 （ ｏｆｆｌｉｎｅ），比如著名的职业社交网站Ｌｉｎｋｅｄｉｎ［２４］，这 种划分方式是按处理所耗时间来划分的．其中在线 的处理时间一般在秒级甚至是毫秒级，因此通常采用 上面所说的流处理．离线的处理时间可以以天为基 本单位，基本采用批处理方式，这种方式可以最大限 度地利用系统Ｉ ?Ｏ．近线的处理时间一般在分钟级或 者是小时级，对其处理模型并没有特别的要求，可以 根据需求灵活选择，但在实际中多采用批处理模式． ２．２ 大数据处理的基本流程 大数据的数据来源广泛，应用需求和数据类型 都不尽相同，但是最基本的处理流程一致．海量 Ｗｅｂ 数据的处理是一类非常典型的大数据应用，从中可以 归纳出大数据处理的最基本流程．ＳｃｈｏｌａｒＳｐａｃｅ ［ ２５］ 由中国人民大学网络与移动数据管理实验室 （ＷＡＭＤＭ）开发，目标是建立一个“以人为本”，即
１５０ 计算机研究与发展 ２０１３，５０（ １）
以作者为中心来展示多学科中文文献的集成数据库 系统．该系统已经从最初的计算机领域扩展到包括 经济、法律等人文社会科学在内的多领域，从数据抽
取和集成，一直到最终的结果展示，ＳｃｈｏｌａｒＳｐａｃｅ完 整地体现出大数据处理的一般流程．在其基础上我 们归纳出大数据的基本流程，如图３所示：
Ｆｉ ｇ．３ Ｂａｓｉｃ ｆｒａｍｅｗｏｒｋ ｏｆ ｂｉ ｇ ｄａｔａ ｐ ｒｏｃｅｓｓｉｎｇ． 图３ 大数据处理基本流程 整个大数据的处理流程可以定义为在合适工具 的辅助下，对广泛异构的数据源进行抽取和集成，结 果按照一定的标准统一存储．利用合适的数据分析 技术对存储的数据进行分析，从中提取有益的知识 并利用恰当的方式将结果展现给终端用户．具体来说 可以分为数据抽取与集成、数据分析以及数据解释． ２．２．１ 数据抽取与集成 大数据的一个重要特点就是多样性，这就意味 着数据来源极其广泛，数据类型极为繁杂，这种复杂 的数据环境给大数据的处理带来极大的挑战．要想 处理大数据，首先必须对所需数据源的数据进行抽 取和集成，从中提取出关系和实体，经过关联和聚合 之后采用统一定义的结构来存储这些数据．在数据 集成和提取时需要对数据进行清洗，保证数据质量 及可信性．同时还要特别注意前面提及的大数据时 代模式和数据的关系，大数据时代的数据往往是先有 数据再有模式，且模式是在不断的动态演化之中的． 数据抽取和集成技术不是一项全新的技术，传 统数据库领域已对此问题有了比较成熟的研究．随 着新的数据源的涌现，数据集成方法也在不断的发 展之中．从数据集成模型来看，现有的数据抽取与集 成方式可以大致分为以下４种类型［２６］：基于物化或 ＥＴＬ方法的引擎（ｍａｔｅｒｉａｌｉｚａｔｉｏｎ ｏｒ ＥＴＬ ｅｎｇｉｎｅ）、基 于联邦数据库或中间件方法的引擎（ｆｅｄｅｒａｔｉｏｎ ｅｎｇｉｎｅ ｏｒ ｍｅｄｉａｔｏｒ）、基于数据流方法的引擎（ｓｔｒｅａｍ ｅｎｇｉｎｅ） 及基于搜索引擎的方法（ｓｅａｒｃｈ ｅｎｇｉｎｅ）． ２．２．２ 数据分析 数据分析是整个大数据处理流程的核心，因为 大数据的价值产生于分析过程．从异构数据源抽取 和集成的数据构成了数据分析的原始数据．根据不 同应用的需求可以从这些数据中选择全部或部分进 行分析．传统的分析技术如数据挖掘、机器学习、统 计分析等在大数据时代需要作出调整，因为这些技 术在大数据时代面临着一些新的挑战，主要有：
１５１孟小峰等 ：大数据管理：概念、技术与挑战
１）数据量大并不一定意味着数据价值的增加， 相反这往往意味着数据噪音的增多．因此在数据分 析之前必须进行数据清洗等预处理工作，但是预处 理如此大量的数据对于机器硬件以及算法都是严峻 的考验． ２）大数据时代的算法需要进行调整．首先大数 据的应用常常具有实时性的特点，算法的准确率不 再是大数据应用的最主要指标．很多场景中算法需 要在处理的实时性和准确率之间取得一个平衡，比 如在线的机器学习算法（ｏｎｌｉｎｅ ｍａｃｈｉｎｅ ｌｅａｒｎｉｎｇ）； 其次云计算是进行大数据处理的有力工具，这就要 求很多算法必须作出调整以适应云计算的框架，算 法需要变得具有可扩展性；最后在选择算法处理大 数据时必须谨慎，当数据量增长到一定规模以后，可 以从小量数据中挖掘出有效信息的算法并一定适用 于大数据．统计学中的邦弗朗尼原理（Ｂｏｎｆｅｒｒｏｎｉｓ ｐｒｉｎｃｉ ｐ ｌｅ） ［ ２７］① 就是一个典型的例子． ３）数据结果好坏的衡量．得到分析结果并不 难，但是结果好坏的衡量却是大数据时代数据分析 的新挑战．大数据时代的数据量大、类型庞杂，进行 分析时往往对整个数据的分布特点掌握的不太清 楚，这会导致最后在设计衡量的方法以及指标时遇 到诸多困难． 大数据分析已被广泛应用于诸多领域，典型的 有推荐系统、商业智能、决策支持等． ２．２．３ 数据解释 数据分析是大数据处理的核心，但是用户往往 更关心结果的展示．如果分析的结果正确但是没有 采用适当的解释方法，则所得到的结果很可能让用 户难以理解，极端情况下甚至会误导用户．数据解释 的方法很多，比较传统的就是以文本形式输出结果 或者直接在电脑终端上显示结果．这种方法在面对 小数据量时是一种很好的选择．但是大数据时代的 数据分析结果往往也是海量的，同时结果之间的关 联关系极其复杂，采用传统的解释方法基本不可行． 可以考虑从下面两个方面提升数据解释能力． １）引入可视化技术．可视化作为解释大量数据 最有效的手段之一率先被科学与工程计算领域采 用．通过对分析结果的可视化用形象的方式向用户 展示结果，而且图形化的方式比文字更易理解和接 受．常见的可视化技术有标签云（ ｔａｇ ｃｌｏｕｄ）、历史流
（ ｈｉｓｔｏｒ ｙ ｆｌｏｗ）、空间信息流 （ ｓｐａｔｉａｌ ｉｎｆｏｒｍａｔｉｏｎ ｆｌｏｗ）等．可以根据具体的应用需要选择合适的可视 化技术． ２）让用户能够在一定程度上了解和参与具体 的分析过程．这个既可以采用人机交互技术，利用交 互式的数据分析过程来引导用户逐步地进行分析， 使得用户在得到结果的同时更好地理解分析结果的 由来．也可以采用数据起源技术［２８］，通过该技术可 以帮助追溯整个数据分析的过程，有助于用户理解 结果．
３ 关键技术分析
大数据价值的完整体现需要多种技术的协同． 文件系统提供最底层存储能力的支持．为了便于数 据管理，需要在文件系统之上建立数据库系统．通过 索引等的构建，对外提供高效的数据查询等常用功 能．最终通过数据分析技术从数据库中的大数据提 取出有益的知识． ３．１ 云计算：大数据的基础平台与支撑技术 如果将各种大数据的应用比作一辆辆“汽车”， 支撑起这些“汽车”运行的“高速公路”就是云计算． 正是云计算技术在数据存储、管理与分析等方面的 支撑，才使得大数据有用武之地． 在所有的“高速公路”中，Ｇｏｏｇｌｅ无疑是技术最 为先进的一个．需求推动创新，面对海量的 Ｗｅｂ数 据，Ｇｏｏｇｌｅ于２００６年首先提出了云计算的概念．支 撑 Ｇｏｏｇｌｅ内部各种大数据应用的正是其自行研发 的一系列云计算技术和工具．难能可贵的是 Ｇｏｏｇｌｅ 并未将这些技术完全封闭，而是以论文的形式逐步 公开其实现．正是这些公开的论文，使得以 ＧＦＳ， ＭａｐＲｅｄｕｃｅ，Ｂｉ ｇ ｔａｂｌｅ为代表的一系列大数据处理 技术被广泛了解并得到应用，同时还催生出以 Ｈａｄｏｏｐ［２９］为代表的一系列云计算开源工具．云计 算所涉及到的技术很多，但是通过Ｇｏｏｇｌｅ云计算技 术的介绍能够快速、完整地把握云计算技术的核心 和精髓．本节以 Ｇｏｏｇｌｅ的相关技术介绍为主线，详 细介绍 Ｇｏｏｇｌｅ以及其他众多学者和研究机构在大 数据技术方面已有的一些工作．根据Ｇｏｏｇｌｅ已公开 的论文及相关资料，结合大数据处理的需求，我们对 Ｇｏｏｇｌｅ的技术演化进行了整理，如图４② 所示：
① 邦弗朗尼原理表明并非给定数据集和挖掘任务就肯定能挖掘出合理的结果。具体内容见文献［２７］． ② 上面所列的系统绝大部分都已经有论文公布其大致实现，虽然Ｃｏｌｏｓｓｕｓ和Ｃａｆｆｅｉｎｅ系统并没有论文公开，但是可以确定其存在．图４中 所列时间如无特别标明，均为论文发表时间，并不代表其在 Ｇｏｏｇｌｅ内部的正式部署和使用时间．
１５２ 计算机研究与发展 ２０１３，５０（ １）
Ｆｉ ｇ．４ Ｔｅｃｈｎｏｌｏｇｙ ｅｖｏｌｕｔｉｏｎ ｉｎ Ｇｏｏｇｌｅ． 图４ Ｇｏｏｇｌｅ技术演化图
３．１．１ 文件系统 文件系统是支撑上层应用的基础．在Ｇｏｏｇｌｅ之 前，尚未有哪个公司面对过如此多的海量数据．因此 对于 Ｇｏｏｇｌｅ而言并没有完全成熟的存储方案可以 直接使用．Ｇｏｏｇｌｅ认为系统组件失败是一种常态而 不是异常，基于此思想 Ｇｏｏｇｌｅ自行设计开发了 Ｇｏｏｇｌｅ文件系统ＧＦＳ［３０］（Ｇｏｏｇｌｅ ｆｉｌｅ ｓｙｓｔｅｍ）．ＧＦＳ 是构建在大量廉价服务器之上的一个可扩展的分布 式文件系统，ＧＦＳ主要针对文件较大，且读远大于 写的应用场景，采用主从（Ｍａｓｔｅｒ －Ｓｌａｖｅ）结构．通过 数据分块、追加更新（ ａｐｐｅｎｄ －ｏｎｌ ｙ）等方式实现了海 量数据的高效存储．随着时间推移，ＧＦＳ的架构逐 渐开始无法适应需求．Ｇｏｏｇｌｅ对 ＧＦＳ进行了重新 的设计，该系统正式的名称为Ｃｏｌｏｓｕｓｓ，具体实现尚 未公开，但是从 ＡＣＭ 对 ＧＦＳ团队核心工程师的访 谈［３１］可以了解其一些新的特性．其中 ＧＦＳ的单点 故障（指仅有一个主节点容易成为系统的瓶颈）、海 量小文件的存储等问题在 Ｃｏｌｏｓｕｓｓ中均得到了 解决． 除了Ｇｏｏｇｌｅ，众多企业和学者也从不同方面对 满足大数据存储需求的文件系统进行了详尽的研 究．微软自行开发的Ｃｏｓｍｏｓ ［ ３２］支撑着其搜索、广告 等业务．ＨＤＦＳ［３３］和 ＣｌｏｕｄＳｔｏｒｅ ［ ３４］都是模仿 ＧＦＳ 的开源实现．ＧＦＳ类的文件系统主要是针对较大文 件设计的，而在图片存储等应用场景，文件系统主要 存储海量小文件，此时ＧＦＳ等文件系统因为频繁读 取元 数 据 等 原 因，效 率 很 低．针 对 这 种 情 况， Ｆａｃｅｂｏｏｋ推出了专门针对海量小文件的文件系统 Ｈａｙｓｔａｃｋ［３５］，通过多个逻辑文件共享同一个物理文 件、增加缓存层、部分元数据加载到内存等方式有效
地解决了Ｆａｃｅｂｏｏｋ海量图片存储问题．淘宝推出了 类似的文件系统 ＴＦＳ［３６］（Ｔａｏ ｆｉｌｅ ｓｙｓｔｅｍ），通过将 小文件合并成大文件、文件名隐含部分元数据等方 式实现了海量小文件的高效存储．ＦａｓｔＤＦＳ［３７］针对 小文件的优化类似于ＴＦＳ． ３．１．２ 数据库系统 原始的数据存储在文件系统之中，但是用户习 惯通过数据库系统来存取文件．因为这样会屏蔽掉 底层的细节，且方便数据管理．直接采用关系模型的 分布式数据库并不能适应大数据时代的数据存储， 主要因为： １）规模效应所带来的压力．大数据时代的数据 量远远超过单机所能容纳的数据量，因此必须采用 分布式存储的方式．这就需要系统具有很好的扩展 性，但这恰恰是传统数据库的弱势之一．因为传统的 数据库产品对于性能的扩展更倾向于ｓｃａｌｅ －ｕｐ（纵 向扩展）的方式，而这种方式对于性能的增加速度远 低于需要处理数据的增长速度，且性能提升存在上 限．适应大数据的数据库系统应当具有良好的
ｓｃａｌｅ －ｏｕｔ（横向扩展）能力，而这种性能扩展方式恰 恰是传统数据库所不具备的．即便是性能最好的并 行数据库产品其ｓｃａｌｅ －ｏｕｔ能力也相对有限． ２）数据类型的多样化．传统的数据库比较适合 结构化数据的存储，但是数据的多样性是大数据时 代的显著特征之一．这也就是意味着除了结构化数 据，半结构化和非结构化数据也将是大数据时代的 重要数据类型组成部分．如何高效地处理多种数据类 型是大数据时代数据库技术面临的重要挑战之一． ３）设计理念的冲突．关系数据库追求的是“Ｏｎｅ
ｓｉｚｅ ｆｉｔｓ ａｌｌ”的目标，希望将用户从繁杂的数据管理
１５３孟小峰等 ：大数据管理：概念、技术与挑战
中解脱出来，在面对不同的问题时不需要重新考虑 数据管理问题，从而可以将重心转向其他的部分．但 在大数据时代不同的应用领域在数据类型、数据处 理方式以及数据处理时间的要求上有极大的差异． 在实际的处理中几乎不可能有一种统一的数据存储 方式能够应对所有场景．比如对于海量 Ｗｅｂ数据的 处理就不可能和天文图像数据采取同样的处理方 式．在这种情况下，很多公司开始尝试从“Ｏｎｅ ｓｉｚｅ ｆｉｔｓ ｏｎｅ”和“Ｏｎｅ ｓｉｚｅ ｆｉｔｓ ｄｏｍａｉｎ”的设计理念出发 来研究新的数据管理方式，并产生了一系列非常有 代表性的工作． ４）数据库事务特性．众所周知关系数据库中事 务的正确执行必须满足 ＡＣＩＤ 特性，即原子性 （ ａｔｏｍｉｃｉｔ ｙ）、一致性（ｃｏｎｓｉｓｔｅｎｃ ｙ）、隔离性（ｉｓｏｌａｔｉｏｎ） 和持久性（ｄｕｒａｂｉｌｉｔ ｙ）．对于数据强一致性的严格要 求使其在很多大数据场景中无法应用．这种情况下 出现了新的 ＢＡＳＥ 特性，即只要求满足 ｂａｓｉｃａｌｌ ｙ ａｖａｉｌａｂｌｅ（基 本 可 用），ｓｏｆｔ ｓｔａｔｅ（柔 性 状 态）和 ｅｖｅｎｔｕａｌｌ ｙ ｃｏｎｓｉｓｔｅｎｔ（最终一致）．从分布式领域著 名的ＣＡＰ理论［３８］① 的角度来看，ＡＣＩＤ追求一致性 Ｃ，而ＢＡＳＥ更加关注可用性 Ａ．正是在事务处理过 程中对于 ＡＣＩＤ特性的严格要求，使得关系型数据 库的可扩展性极其有限． 面对这些挑战，以 Ｇｏｏｇｌｅ为代表的一批技术公
司纷纷推出了自己的解决方案．Ｂｉ ｇ ｔａｂｌｅ ［ ３９］是 Ｇｏｏｇｌｅ 早期开发的数据库系统，它是一个多维稀疏排序表， 由行和列组成，每个存储单元都有一个时间戳，形成 三维结构．不同的时间对同一个数据单元的多个 操作形成数据的多个版本之间由时间戳来区分． 除了 Ｂｉ ｇ ｔａｂｌｅ，Ａｍａｚｏｎ的 Ｄｙｎａｍｏ［４０］和 Ｙａｈｏｏ的 ＰＮＵＴＳ［４１］也都是非常具有代表性的系统．Ｄｙｎａｍｏ 综合使用了键?值存储、改进的分布式哈希表（ＤＨＴ）、 向量时钟（ｖｅｃｔｏｒ ｃｌｏｃｋ）等技术实现了一个完全的 分布式、去中心化的高可用系统．ＰＮＵＴＳ是一个分 布式的数据库，在设计上使用弱一致性来达到高可 用性的目标，主要的服务对象是相对较小的记录，比 如在线的大量单个记录或者小范围记录集合的读和 写访问．不适合存储大文件、流媒体等．Ｂｉ ｇ ｔａｂｌｅ， Ｄｙｎａｍｏ，ＰＮＵＴＳ等的成功促使人们开始对关系数 据库进行反思，由此产生了一批未采用关系模型的 数据库，这些方案现在被统一称为ＮｏＳＱＬ（ｎｏｔ ｏｎｌ ｙ ＳＱＬ）．ＮｏＳＱＬ并没有一个准确的定义，但一般认为 ＮｏＳＱＬ数据库应当具有以下的特征［４２］：模式自由 （ ｓｃｈｅｍａ － ｆｒｅｅ）、支 持 简 易 备 份 （ｅａｓｙ ｒｅｐｌｉｃａｔｉｏｎ ｓｕｐｐｏｒｔ）、简单的应用程序接口（ｓｉｍｐｌｅ ＡＰＩ）、最终 一致性（或者说支持ＢＡＳＥ特性，不支持 ＡＣＩＤ）、支 持海量数据（ｈｕｇｅ ａｍｏｕｎｔ ｏｆ ｄａｔａ）．ＮｏＳＱＬ和关系 型数据库的简单比较如表３所示：
① ＣＡＰ理论指出：一个分布式系统不可能同时满足一致性、可用性（ａｖａｉｌａｂｉｌｉｔ ｙ）和分区容错性（ ｐａｒｔｉｔｉｏｎ ｔｏｌｅｒａｎｃｅ），最多只能同时满足其中 两个．
Ｔａｂｌｅ ３ Ｃｏｍｐａｒｉｓｏｎ ｂｅｔｗｅｅｎ ＮｏＳＱＬ Ｄａｔａｂａｓｅ ａｎｄ ＲＤＢＭＳ 表３ ＮｏＳＱＬ数据库和关系数据库的对比
Ｏｂ ｊ ｅｃｔｓ ｏｆ Ｃｏｍｐａｒｉｓｏｎ ＲＤＢＭＳ ＮｏＳＱＬ Ｎｏｔｅｓ
Ｒａｔｉｏｎａｌｅ Ｐｅｒｆｅｃｔ Ｉｍｐｅｒｆｅｃｔ ＲＤＢＭＳ ｉｓ ｂａｓｅｄ ｏｎ ｍａｔｈｅｍａｔｉｃａｌ ｍｏｄｅｌ；ＮｏＳＱＬ ｈａｓ ｎｏ ｓｕｃｈ ｍｏｄｅｌ．
Ｄａｔａ Ｓｃａｌｅ Ｌａｒ ｇｅ Ｅｘｔｒｅｍｅｌ ｙ Ｌａｒ ｇｅ
Ｐｅｒｆｏｒｍａｎｃｅ ｏｆ ＲＤＢＭＳ ｗｉｌｌ ｄｅｇｒａｄｅ ａｓ ｔｈｅ ｄａｔａ ｉｎｃｒｅａｓｅ，ｓｏ ｉｔｓ ｕｓｕａｌｌ ｙ ｎｏｔ ａｐｐｒｏｐｒｉａｔｅ ｆｏｒ ｅｘｔｒｅｍｅｌ ｙ ｌａｒ ｇｅ ｄａｔａ；ＮｏＳＱＬ ｃａｎ ｉｎｃｒｅａｓｅ ｔｈｅ ｖｏｌｕｍｅ ｏｆ ｓｔｏｒａｇｅ ｂｙ ａｄｄｉｎｇ ｍｏｒｅ ｄｅｖｉｃｅｓ．
Ｓｃｈｅｍａ Ｆｉｘｅｄ Ｆｌｅｘｉｂｌｅ ＲＤＢＭＳ ｍｕｓｔ ｄｅｆｉｎｅ ｓｃｈｅｍａ ａｔ ｆｉｒｓｔ；ＮｏＳＱＬ ｉｓ ｓｃｈｅｍａ － ｆｒｅｅ．
Ｑｕｅｒ ｙ Ｆａｓｔ
Ｓｉｍｐｌｅ ｑｕｅｒ ｙ ｉｓ ｅｆｆｉｃｉｅｎｔ
ＲＤＢＭＳ ｗｉｌｌ ｂｕｉｌｄ ｉｎｄｅｘ，ｓｏ ｉｔ ｃａｎ ｗｅｌｌ ｓｕｐｐｏｒｔ ｐｏｉｎｔ ｑｕｅｒ ｙ ａｎｄ ｒａｎｇｅ ｑｕｅｒ ｙ； ＮｏＳＱＬ ｈａｓ ｎｏ ｉｎｄｅｘ，ａｌｔｈｏｕｇｈ ｔｈｅ ｑｕｅｒ ｙ ｐ ｒｏｃｅｓｓｉｎｇ ｃａｎ ｂｅ ａｃｃｅｌｅｒａｔｅｄ ｂｙ ＭａｐＲｅｄｕｃｅ，ｉｔ ｉｓ ｓｔｉｌｌ ｌｅｓｓ ｅｆｆｉｃｉｅｎｔ．
Ｃｏｎｓｉｓｔｅｎｃ ｙ Ｓｔｒｏｎｇ ｃｏｎｓｉｓｔｅｎｃ ｙ Ｗｅａｋ ｃｏｎｓｉｓｔｅｎｃ ｙ ＲＤＢＭＳ ｏｂｅｙ ＡＣＩＤ；ＮｏＳＱＬ ｏｂｅｙ ＢＡＳＥ．
Ｓｃａｌａｂｉｌｉｔ ｙ Ｍｏｄｅｒａｔｅ Ｇｏｏｄ ＲＤＢＭＳ ｉｓ ｄｉｆｆｉｃｕｌｔ ｔｏ ｓｃａｌｅ；ＮｏＳＱＬ ｃａｎ ｅａｓｉｌ ｙ ｓｃａｌｅ ｏｕｔ ｂｙ ａｄｄｉｎｇ ｎｅｗ ｎｏｄｅｓ．
Ａｖａｉｌａｂｉｌｉｔ ｙ Ｇｏｏｄ Ｖｅｒ ｙ Ｇｏｏｄ
Ａｖａｉｌａｂｉｌｉｔ ｙ ｏｆ ＲＤＢＭＳ ｉｓ ｒｅｌａｔｉｖｅｌ ｙ ｗｅａｋ ｗｈｅｎ ｔｈｅ ｖｏｌｕｍｅ ｏｆ ｄａｔａ ｉｓ ｖｅｒ ｙ ｌａｒ ｇｅ ｂｅｃａｕｓｅ ｏｆ ｉｔｓ ｌｉｍｉｔａｔｉｏｎ ｏｆ ｓｔｒｏｎｇ ｃｏｎｓｉｓｔｅｎｃ ｙ；ＮｏＳＱＬ ｃａｎ ａｃｈｉｅｖｅ ｂｅｔｔｅｒ ａｖａｉｌａｂｉｌｉｔ ｙ ｂｙ ｒｅｌａｘｉｎｇ ＡＣＩＤ ｓｅｍａｎｔｉｃｓ．
Ｓｔａｎｄａｒｄ Ｙｅｓ Ｎｏ ＲＤＢＭＳ ｈａｓ ｓｔａｎｄａｒｄ（ＳＱＬ）；ＮｏＳＱＬ ｈａｓ ｎｏ ｓｕｃｈ ｓｔａｎｄａｒｄ．
Ｔｅｃｈｎｉｃａｌ Ｓｕｐｐｏｒｔ Ｈｉ ｇｈ Ｌｏｗ Ｔｅｃｈｎｉｃａｌ ｓｕｐｐｏｒｔ ｆｏｒ ＲＤＢＭＳ ｉｓ ｈｉ ｇｈ；Ｔｅｃｈｎｉｃａｌ ｓｕｐｐｏｒｔ ｆｏｒ ＮｏＳＱＬ ｉｓ ｌｏｗ．
Ｍａｉｎｔｅｎａｎｃｅ Ｃｏｍｐｌｅｘ Ｃｏｍｐｌｅｘ
ＲＤＢＭＳ ｓｈｏｕｌｄ ｂｅ ｍａｉｎｔａｉｎｅｄ ｂｙ ＤＢＡ；ＮｏＳＱＬ ｉｓ ｎｏｔ ｓｏｐｈｉｓｔｉｃａｔｅｄ ｎｏｗ，ｓｏ ｉｔｓ ｍａｉｎｔｅｎａｎｃｅ ｉｓ ａｌｓｏ ｄｉｆｆｉｃｕｌｔ．
１５４ 计算机研究与发展 ２０１３，５０（ １）
典型的 ＮｏＳＱＬ数据库分类如表４［４３］所示：
Ｔａｂｌｅ ４ Ｔｙｐｉｃａｌ ＮｏＳＱＬ Ｄａｔａｂａｓｅｓ 表４ 典型ＮｏＳＱＬ数据库
Ｃａｔｅｇｏｒ ｙ Ｍａｔｃｈｉｎｇ Ｄａｔａｂａｓｅｓ Ｐｅｒｆｏｒｍａｎｃｅ Ｓｃａｌａｂｉｌｉｔ ｙ Ｆｌｅｘｉｂｉｌｉｔ ｙ Ｃｏｍｐｌｅｘｉｔ ｙ Ａｄｖａｎｔａｇｅｓ Ｄｉｓａｄｖａｎｔａｇｅｓ
Ｋｅｙ －Ｖａｌｕｅ
Ｒｅｄｉｓ Ｒｉａｋ
Ｈｉ ｇｈ Ｈｉ ｇｈ Ｈｉ ｇｈ Ｎｏｎｅ Ｑｕｅｒ ｙ ｉｓ ｅｆｆｉｃｉｅｎｔ
Ｓｔｏｒｅｄ ｄａｔａ ｌａｃｋ ｓｔｒｕｃｔｕｒｅ
Ｃｏｌｕｍｎ
ＨＢａｓｅ Ｃａｓｓａｎｄｒａ
Ｈｉ ｇｈ Ｈｉ ｇｈ Ｍｏｄｅｒａｔｅ Ｌｏｗ Ｑｕｅｒ ｙ ｉｓ ｅｆｆｉｃｉｅｎｔ
Ｆｕｎｃｔｉｏｎａｌｉｔ ｙ ｉｓ ｍｉｎｉｍａｌ
Ｄｏｃｕｍｅｎｔ
ＣｏｕｃｈＤＢ ＭｏｎｇｏＤＢ
Ｈｉ ｇｈ Ｖａｒｉａｂｌｅ Ｈｉ ｇｈ Ｌｏｗ
Ｌｉｔｔｌｅ ｌｉｍｉｔｓ ｏｎ ｄａｔａ ｓｔｒｕｃｔｕｒｅ
Ｐｅｒｆｏｒｍａｎｃｅ ｏｆ ｑｕｅｒ ｙ ｉｓ ｌｏｗ
Ｇｒａｐｈ
Ｎｅｏ４Ｊ ＯｒｉｅｎｔＤＢ
Ｖａｒｉａｂｌｅ Ｖａｒｉａｂｌｅ Ｈｉ ｇｈ Ｈｉ ｇｈ
Ｇｒａｐｈ ａｌ ｇｏｒｉｔｈｍｓ ａｒｅ ｓｏｐｈｉｓｔｉｃａｔｅｄ
Ｄａｔａ ｓｃａｌｅ ｉｓ ｒｅｌａｔｉｖｅｌ ｙ ｌｏｗ
Ｂｉ ｇ ｔａｂｌｅ的模型简单，但是相较传统的关系数 据库其支持的功能非常有限，不支持 ＡＣＩＤ特性．因 此Ｇｏｏｇｌｅ开发了 Ｍｅｇａｓｔｏｒｅ ［ ４４］系统，虽然其底层数 据存储依赖 Ｂｉ ｇ ｔａｂｌｅ，但是它实现了类似 ＲＤＢＭＳ 的数据模型，同时提供数据的强一致性解决方案． Ｍｅｇａｓｔｏｒｅ将数据进行细粒度的分区，数据更新会 在机 房 间 进 行 同 步 复 制．Ｓｐａｎｎｅｒ ［ ４５］是 已 知 的 Ｇｏｏｇｌｅ的最新的数据库系统，Ｇｏｏｇｌｅ在 ＯＳＤＩ２０１２ 上公开了Ｓｐａｎｎｅｒ的实现．Ｓｐａｎｎｅｒ是第１个可以 实现全球规模扩展（ ｇ ｌｏｂａｌ ｓｃａｌｅ）并且支持外部一致 的事务 （ｓｕｐｐｏｒｔ ｅｘｔｅｒｎａｌｌ ｙ － ｃｏｎｓｉｓｔｅｎｔ ｄｉｓｔｒｉｂｕｔｅｄ ｔｒａｎｓａｃｔｉｏｎｓ）的数据库．通过 ＧＰＳ 和 原 子 时 钟 （ ａｔｏｍｉｃ ｃｌｏｃｋｓ）技术，Ｓｐａｎｎｅｒ实现了一个时间 ＡＰＩ．借助该 ＡＰＩ，数据中心之间的时间同步能够精 确到１０ｍｓ以内．Ｓｐａｎｎｅｒ类似于 Ｂｉ ｇ ｔａｂｌｅ，但是它 具有层次性的目录结构以及细粒度的数据复制．对 于数据中心之间不同操作会分别支持强一致性或弱 一致性，且支持更多的自动操作．Ｓｐａｎｎｅｒ的目标是 控制１００万到１ ０００万台服务器，最多包含大约１０ 万亿目录和１ ０００万亿字节的存储空间．另外在 ＳＩＧＭＯＤ２０１２上，Ｇｏｏｇｌｅ公开了用于其广告系统的 新数据库产品Ｆ１［４６］，作为一种混合型数据库Ｆ１融 合兼有Ｂｉ ｇ ｔａｂｌｅ的高扩展性以及ＳＱＬ数据库的可 用性 和 功 能 性．该 产 品 的 底 层 存 储 正 是 采 用 Ｓｐａｎｎｅｒ，具有很多新的特性，包括全局分布式、同步 跨数据中心复制、可视分片和数据移动、常规事务等． 有些比较激进的观点认为“关系数据库已死”， 我们认为关系数据库和 ＮｏＳＱＬ并不是矛盾的对立 体，而是可以相互补充的、适用于不同应用场景的技 术．例如实际的互联网系统往往都是ＡＣＩＤ 和 ＢＡＳＥ两种系统的结合．近些年来，以Ｓｐａｎｎｅｒ为代 表的若干新型数据库的出现，给数据存储带来了
ＳＱＬ，ＮｏＳＱＬ之外的新思路．这种融合了一致性和 可用性的 ＮｅｗＳＱＬ或许会是未来大数据存储新的 发展方向． ３．１．３ 索引与查询技术 数据查询是数据库最重要的应用之一，而索引 则是解决数据查询问题的有效方案．就Ｇｏｏｇｌｅ自身 而言，索引的构建是提供搜索服务的关键部分． Ｇｏｏｇｌｅ最早的索引系统是利用 Ｍａ ｐＲｅｄｕｃｅ来更新 的．根据更新频率进行层次划分，不同的层次对应不 同的更新频率．每次需要批量更新索引，即使有些数 据并未改变也需要处理掉．这种索引更新方式效率较 低．随后 Ｇｏｏｇｌｅ提出了Ｐｅｒｃｏｌａｔｏｒ ［ ４７］，这是一种增量 式的索引更新器，每次更新不需要替换所有的索引数 据，效率大大提高．虽然不是所有的大数据应用都需 要索引，但是这种增量计算的思想非常值得我们借 鉴．Ｇｏｏｇｌｅ当前正在使用的索引系统为Ｃａｆｆｅｉｎｅ ［ ４８］， 其具体实现尚未公布．但是可以确定 Ｃａｆｆｅｉｎｅ是构 建在Ｓｐａｎｎｅｒ之上，采用Ｐｅｒｃｏｌａｔｏｒ更新索引．效率 相较上一代索引系统而言有大幅度提高． 关系数据库也是利用对数据构建索引的方式较 好地解决了数据查询的问题．不同的索引方案使得 关系数据库可以满足不同场景的要求．索引的建立 以及更新都会耗费较多的时间，在面对传统数据库 的小数据量时这些时间和其所带来的查询便利性相 比是可以接受的，但是这些复杂的索引方案基本无 法直接应用到大数据之上．表５［４９］是对一些索引方 案直接应用在Ｆａｃｅｂｏｏｋ上的性能估计． 从表５可以看出不太可能将已有的成熟索引方 案直接应用于大数据．ＮｏＳＱＬ数据库针对主键的查 询效率一般较高，因此有关的研究集中在ＮｏＳＱＬ 数据库的多值查询优化上．针对 ＮｏＳＱＬ数据库上 的查询优化研究主要有两种思路：
１５５孟小峰等 ：大数据管理：概念、技术与挑战
Ｔａｂｌｅ ５ Ｑｕｅｒ ｙ Ｉｎｄｅｘ Ｅｘａｍｐｌｅｓ 表５ 查询索引的案例
Ａｌ ｇｏｒｉｔｈｍｓ Ｉｎｄｅｘ Ｓｉｚｅ ｆｏｒ Ｆａｃｅｂｏｏｋ Ｉｎｄｅｘ Ｔｉｍｅ ｆｏｒ Ｆａｃｅｂｏｏｋ Ｑｕｅｒ ｙ Ｔｉｍｅ ｏｎ Ｆａｃｅｂｏｏｋ ? ｓ
Ｕｌｌｍａｎｎ － － ＞１ ０００
ＶＦ２ － － ＞１ ０００
ＲＤＦ － ３Ｘ １ＴＢ ＞２０ｄ ＞４８
ＢｉｔＭａｔ ２．４ＴＢ ＞２０ｄ ＞２６９
Ｓｕｂｄｕｅ － ＞６７ｙｅａｒｓ －
ＳｐｉｄｅｒＭｉｎｅ － ＞３ｙｅａｒｓ － Ｒ
－ Ｊｏｉｎ ＞１７５ＴＢ ＞１０１５ ｙｅａｒｓ ＞２００
Ｄｉｓｔａｎｃｅ － Ｊｏｉｎ ＞１７５ＴＢ ＞１０１５ ｙｅａｒｓ ＞４ ０００
ＧｒａｐｈＱＬ ＞１３ＴＢ（ ｒ ＝２） ＞６００ｙｅａｒｓ ＞２ ０００
Ｚｈａｏ ＞１２ＴＢ（ ｒ ＝２） ＞６００ｙｅａｒｓ ＞６００
ＧＡＤＤＩ ＞２×１０ ５ ＴＢ（ Ｌ ＝４） ＞４×１０ ５ ｙｅａｒｓ ＞４００
１）采用 ＭａｐＲｅｄｕｃｅ并行技术优化多值查询： 当利用 ＭａｐＲｅｄｕｃｅ并行查询 ＮｏＳＱＬ数据库时，每 个 ＭａｐＴａｓｋ处理一部分的查询操作，通过实现多个 部分之间的并行查询来提高多值查询的效率．此时
每个部分的内部仍旧需要进行数据的全扫描． ２）采用索引技术优化多值查询：很多的研究工 作尝试从添加多维索引的角度来加速ＮｏＳＱＬ数据库 的查询速度． 表６列举了已有的一些解决方案的对比．
Ｔａｂｌｅ ６ Ｃｏｍｐａｒｉｓｏｎ ｂｅｔｗｅｅｎ Ｍｕｌｔｉ ｐ ｌｅ Ｆｉｅｌｄｓ Ｑｕｅｒ ｙ Ｕｓｉｎｇ Ｉｎｄｅｘ 表６ 采用索引加速多值查询的方案对比
Ｔｙｐｅｓ ｏｆ ｉｎｄｅｘｅｓ Ａｄｖａｎｔａｇｅｓ Ｄｉｓａｄｖａｎｔａｇｅｓ Ｅｘａｍｐｌｅｓ
Ｍｕｌｔｉ ｐ ｌｅ ｏｎｅ －ｄｉｍｅｎｓｉｏｎａｌ Ｉｎｄｅｘｅｓ
Ａｃｈｉｅｖｅｍｅｎｔ ａｎｄ ｍａｉｎｔｅｎａｎｃｅ ａｒｅ ｅａｓ ｙ
Ｌｅｓｓ ｅｆｆｉｃｉｅｎｔ ｍｕｌｔｉｄｉｍｅｎｓｉｏｎａｌ ｑｕｅｒ ｙ ａｎｄ ｈｉ ｇｈ ｓｐａｃｅ ｒｅｄｕｎｄａｎｃ ｙ
ＩＴＨｂａｓｅ ＩＨｂａｓｅ ＣＣＩｎｄｅｘ
Ａｓ ｙｎｃｈｒｏｎｏｕｓ ｖｉｅｗｓ
Ｍｕｌｔｉｄｉｍｅｎｓｉｏｎａｌ Ｉｎｄｅｘ Ｇｏｏｄ ｓｃａｌａｂｉｌｉｔ ｙ
Ａｃｈｉｅｖｅｍｅｎｔ ａｎｄ ｍａｉｎｔｅｎａｎｃｅ ｏｆ ｉｎｄｅｘ ａｒｅ ｃｏｍｐｌｅｘ
ＲＴ－ＣＡＮ ＱＴ－Ｃｈｏｒｄ ＥＭＩＮＣ Ａ－Ｔｒｅｅ
Ｓｐａｔｉａｌ Ｉｎｄｅｘ
Ｈｉ ｇｈ ｗｒｉｔｅ ｔｈｒｏｕｇｈｐｕｔ ａｎｄ ｌｏｗ ｃｏｓｔ ｏｆ ｍａｉｎｔｅｎａｎｃｅ
Ｃｏｎｓｉｓｔｅｎｃ ｙ ｍａｉｎｔｅｎａｎｃｅ ｉｓ ｃｏｍｐｌｅｘ
ＭＤ－ＨＢａｓｅ ＵＱＥ － Ｉｎｄｅｘ
ＩＴＨｂａｓｅ ［ ５０］，ＩＨｂａｓｅ ［ ５１］，ＣＣＩｎｄｅｘ［５２］ 和
Ａｓ ｙｎｃｈｒｏｎｏｕｓ ｖｉｅｗｓ ［ ５３］是典型的采用多个一维二 级索引来加速多值查询优化的实现方案．其中 ＩＴＨｂａｓｅ 和 ＩＨｂａｓｅ 是 两 个 开 源 的 实 现 方 案， ＩＴＨｂａｓｅ主要关注于数据一致性，事务性是其重要 特性．ＩＨｂａｓｅ与ＩＴＨｂａｓｅ类似，从 ＨＢａｓｅ源码级别 进行了扩展，重新定义和实现了Ｓｅｒｖｅｒ，Ｃｌｉｅｎｔ端处 理逻辑．ＣＣＩｎｄｅｘ（ｃｏｍｐｌｅｍｅｎｔａｌ ｃｌｕｓｔｅｒｉｎｇ ｉｎｄｅｘ） 是中国科学院提出的另外一种索引结构，它在索引 中既存储索引项，也存储记录的其他列的数据，以便 在查询时直接在索引表中通过顺序扫描找到相应的 数据，大幅度减少查询时间．该方法本质是以空间代 价来换取查询效率．ＣＣＩｎｄｅｘ的索引更新代价比较
高，会影响系统的吞吐量．索引创建以后不能够动态 增加或修改．Ａｓ ｙｎｃｈｒｏｎｏｕｓ ｖｉｅｗｓ以异步视图的方 式来实现非主键的查询，提出了两种视图方案：远端 视图表（ｒｅｍｏｔｅ ｖｉｅｗ ｔａｂｌｅｓ，ＲＶＴｓ）和局部视图表 （ ｌｏｃａｌ ｖｉｅｗ ｔａｂｌｅｓ，ＬＶＴｓ）． ＲＴ－ＣＡＮ［５４］采用多维索引加速多值查询．其局 部索引采用Ｒ － ｔｒｅｅ，全局索引中采用了能够支持多 维查询的ＣＡＮ覆盖网络．ＱＴ－Ｃｈｏｒｄ［５５］是另一种双 层索引结构，它的局部索引采用的是改进的四叉树
ＩＭＸ－ＣＩＦ ｑｕａｄ － ｔｒｅｅ，全局索引采用的Ｃｈｏｒｄ覆盖网 络．ＥＭＩＮＣ［５６］针对每个局部节点建立一个ＫＤ － ｔｒｅｅ，然后选择 ＫＤ － ｔｒｅｅ的部分节点作为全局索引． 每一个局部索引节点被看成是一个多个维度组成的
１５６ 计算机研究与发展 ２０１３，５０（ １）
立方体，然后在全局索引中用 Ｒ － ｔｒｅｅ对这些立方体 进行索引．Ａ－Ｔｒｅｅ ［ ５７］提出了另外一种方案．基本思 路是：针对每一个存储节点构建Ｒ － ｔｒｅｅ，同时创建一 个Ｂｌｏｏｍ ｆｉｌｔｅｒ（布隆过滤器）．这样在进行点查询 时，首先通过Ｂｌｏｏｍ ｆｉｌｔｅｒ进行验证，如果查询点不 在其中，则不再进行 Ｒ － ｔｒｅｅ查询，否则继续进行 Ｒ － ｔｒｅｅ查询． ＭＤ－ＨＢａｓｅ ［ ５８］提出一种基于空间目标排序的索 引方案．基于空间目标排序的索引方法的基本思想 是：按照一定规则将覆盖整个研究区的范围划分为 大小相等的格子，并给每一格网分配一个编号，用这 些编号为空间目标生成一组具有代表意义的数字． 其实质是将 ｋ 维空间的实体映射到一维空间，因此 可以利用现有数据库管理系统中比较成熟的一维索 引技术．ＵＱＥ － Ｉｎｄｅｘ［５９］主要针对海量物联网应用场 景的时空特性，在时间维度上把数据分成当前数据 和历史数据，对当前数据和历史数据进行不同粒度 的索引，对当前数据，在时间段和子空间上进行索 引，从而减少索引更新的次数，降低索引维护的代 价，提高系统的吞吐量；对历史数据，批量地建立记 录级别的索引；在建立子空间索引时，为了确保数据 分布均匀，采用 ＫＤ Ｔｒｅｅ进行动态划分．但是如果 所有的数据都需要经过 ＫＤ Ｔｒｅｅ来索引也会带来 较高的代价，会影响数据的插入速度，因此可以对数 据进行采样，对采样得到的数据利用 ＫＤ Ｔｒｅｅ进行 索引，从而得到空间上的划分方案． 就已有方案来看，针对 ＮｏＳＱＬ数据库上的查 询优化技术都并不成熟，仍有很多关键性问题亟待 解决． ３．１．４ 数据分析技术 数据分析是Ｇｏｏｇｌｅ最核心业务，每一次简单的 网络点击背后都需要进行复杂的分析过程，因此 Ｇｏｏｇｌｅ对其分析系统进行不断的升级改造之中． ＭａｐＲｅｄｕｃｅ是 Ｇｏｏｇｌｅ最早采用的计算模型，适用 于批处理，其具体内容已在上一节介绍．图是真实社 会中广泛存在的事物之间联系的一种有效表示手 段，因此对图的计算是一种常见的计算模式，而图计 算会涉及到在相同数据上的不断更新以及大量的消 息传递，如果采用 ＭａｐＲｅｄｕｃｅ去实现，会产生大量 不必要的序列化和反序列化开销．现有的图计算系 统并不适用于 Ｇｏｏｇｌｅ的应用场景，因此 Ｇｏｏｇｌｅ设 计并实现了Ｐｒｅｇｅｌ图计算模型．Ｐｒｅｇｅｌ ［ ６０］是 Ｇｏｏｇｌｅ 继 ＭａｐＲｅｄｕｃｅ之后提出的又一个计算模型，与 ＭａｐＲｅｄｕｃｅ的离线批处理模式不同，它主要用于图
的计算．该模型的核心思想源于著名的ＢＳＰ［６１］计算 模型．Ｄｒｅｍｅｌ ［ ６２］是 Ｇｏｏｇｌｅ提出的一个适用于 Ｗｅｂ 数据级别的交互式数据分析系统，通过结合列存储 和多层次的查询树，Ｄｒｅｍｅｌ能够实现极短时间内的 海量数据分析．Ｄｒｅｍｅｌ支持着 Ｇｏｏｇｌｅ内部的一些 重要服务，比如 Ｇｏｏｇｌｅ的云端大数据分析平台Ｂｉ ｇ Ｑｕｅｒ ｙ ［ ６３］．Ｇｏｏｇｌｅ在 ＶＬＤＢ ２０１２发表的文献［６４］ 中介绍了一个内部名称为ＰｏｗｅｒＤｒｉｌｌ的分析工具， ＰｏｗｅｒＤｒｉｌｌ同样采用了列存储，且使用了压缩技术 将尽可能多的数据装载进内存．ＰｏｗｅｒＤｒｉｌｌ与 Ｄｒｅｍｅｌ均是Ｇｏｏｇｌｅ的大数据分析工具，但是其关 注的应用场景不同，实现技术也有很大差异． Ｄｒｅｍｅｌ主要用于多数据集的分析，而ＰｏｗｅｒＤｒｉｌｌ则 主要应用于大数据量的核心数据集分析，数据集的 种类相较于 Ｄｒｅｍｅｌ的应用场景会少很多．由于 ＰｏｗｅｒＤｒｉｌｌ是设计用来处理少量的核心数据集，因 此对数据处理速度要求极高，所以其数据应当尽可 能地驻留在内存，而 Ｄｒｅｍｅｌ的数据则存储在磁盘 中．除此之外，ＰｏｗｅｒＤｒｉｌｌ与Ｄｒｅｍｅｌ在数据模型、数 据分区等方面都有明显的差别．从实际的执行效率 来看，Ｄｒｅｍｅｌ可以在几秒内处理 ＰＢ级的数据查 询，而ＰｏｗｅｒＤｒｉｌｌ则可以在３０～４０ｓ里处理７８２０ 亿个单元格的数据，处理速度快于 Ｄｒｅｍｅｌ．二者的 应用场景不同，可以相互补充． 微软提出了一个类似 ＭａｐＲｅｄｕｃｅ的数据处理 模型，称之为Ｄｒ ｙａｄ［６５］，Ｄｒ ｙａｄ模型主要用来构建支 持有向无环图（ｄｉｒｅｃｔｅｄ ａｃｙｃｌｉｎｅ ｇ ｒａｐｈ，ＤＡＧ）类型 数据流的并行程序．Ｃａｓｃａｄｉｎｇ［６６］通过对 Ｈａｄｏｏｐ ＭａｐＲｅｄｕｃｅ ＡＰＩ的封装，支持有向无环图类型的应 用．Ｓｅｃｔｏｒ ? ｓｐｈｅｒｅ ［ ６７］ 可以视为一种流式的 ＭａｐＲｅｄｕｃｅ，它由分布式文件系统Ｓｅｃｔｏｒ和并行计 算框 架 ｓｐｈｅｒｅ 组 成．Ｎｅｐｈｅｌｅ ?ＰＡＣＴｓ ［ ６８］ 则 包 括 ＰＡＣＴｓ（ ｐａｒａｌｌｅｌｉｚａｔｉｏｎ ｃｏｎｔｒａｃｔｓ）编程模型和并行 计算引擎 Ｎｅｐｈｅｌｅ．ＭａｐＲｅｄｕｃｅ模型基本成为了批 处理类应用的标准处理模型，很多应用开始尝试利 用 ＭａｐＲｅｄｕｃｅ加速其数据处理． 实时数据处理是大数据分析的一个核心需求． 很多研究工作正是围绕这一需求展开的．前面介绍 了大数据处理的两种基本模式，而在实时处理的模 式选择中，主要有３种思路： １）采用流处理模式．虽然流处理模式天然适合 实时处理系统，但其适用领域相对有限．流处理模型 的应用主要集中在实时统计系统、在线状态监控等． ２）采用批处理模式．近几年来，利用批处理模
１５７孟小峰等 ：大数据管理：概念、技术与挑战
型开发实时系统已经成为研究热点并取得了很多成 果．从增量计算的角度出发，Ｇｏｏｇｌｅ提出了增量处 理系统 Ｐｅｒｃｏｌａｔｏｒ ［ ４７］，微软则提出了 Ｎｅｃｔａｒ ［ ６９］和
Ｄｒ ｙａｄＩｎｃ ［ ７０］．三者均实现了大规模数据的增量计 算，但是这些系统和 ＭａｐＲｅｄｕｃｅ并不兼容，因此 Ｉｎｃｏｏｐ［７１］和ＩｎｃＭＲ［７２］实现了 ＭａｐＲｅｄｕｃｅ框架下的 增量计算．Ｙａｈｏｏ的 Ｎｏｖａ［７３］则支持有状态的增量 数据计算模式．ＨＯＰ［７４］在 ＭａｐＲｅｄｕｃｅ处理的过程 中引入管道（ ｐ ｉ ｐｅｌｉｎｅ）的概念．在保证 Ｈａｄｏｏｐ容错 性的前提下，使数据在各个任务间以管道的方式交 互，增加了任务的并发性，提高了数据处理的实时 性．中国人民大学 ＷＡＭＤＭ 实验室在 ＨＯＰ基础上 开发的 ＣＯＬＡ 系统［７５］在 ＨＯＰ系统的基础上增加 了数据采样、结果估计、置信区间计算等功能模块， 一定程度上提高了 ＨＯＰ的实时性．原位分析可以 避免将文件集中传输到分析服务器上的通信开销， 大大提高了实时性．文献［７６ － ７７］从原位分析的角度 出发，分别实现了针对大规模日志分析的原位 ＭａｐＲｅｄｕｃｅ（Ｉｎ － ｓｉｔｕ ＭａｐＲｅｄｕｃｅ）和 Ｃｏｎｔｉｎｕｏｕｓ ＭａｐＲｅｄｕｃｅ．原始的 ＭａｐＲｅｄｕｃｅ模型并不能很好地 支持迭代计算，计算代价很大．而迭代计算是图计 算、数据挖掘、机器学习等领域常见的运算模式，不 少研究工作通过改进 ＭａｐＲｅｄｕｃｅ模型迭代计算的 效率来提高其实时性．ＨａＬｏｏｐ［７８］通过在各个ｔａｓｋ ｔｒａｃｋｅｒ对数据进行缓存（ｃａｃｈｅ）和创建索引（ｉｎｄｅｘ） 的方式来减少磁盘ＩＯ，并提供了一套新的编程接 口．但是 ＨａＬｏｏｐ的动静态数据无法分离，且没有一 个客 观 的 停 止 迭 代 的 标 准．Ｔｗｉｓｔｅｒ ［ ７９］系 统 将 Ｈａｄｏｏｐ的全部数据存放在内存中，采用独立模块 传递所有的消息和数据．但是数据驻留内存的限制 使其难以实用，且其计算模型的抽象度不高，支持的 应用也很有限．Ｔｗｉｓｔｅｒ仍处于初步的研究阶段． ｉＭａｐＲｅｄｕｃｅ ［ ８０］介绍了一种基于 ＭａｐＲｅｄｕｃｅ的迭代 模型，但是它的静态调度策略和粗粒度的ｔａｓｋ可能 会导致资源利用不佳和负载不均．ｉＨａｄｏｏｐ［８１］实现 了 ＭａｐＲｅｄｕｃｅ的异步迭代，但是在ｔａｓｋ之间的复 用上并无太大改进．ＰｒＩｔｅｒ ［ ８２］是在 Ｈａｄｏｏｐ的基础 上开发的，支持带优先级的迭代计算，能够保证迭代 过程的快速收敛，适合ｔｏｐ － ｋ 之类的在线查询．最新 版本的ＰｒＩｔｅｒ已经支持基于内存和基于文件的数 据存储方式．Ｓｐａｒｋ［８３］将中间结果存放在内存中，支 持除 Ｍａｐ和 Ｒｅｄｕｃｅ之外的多种操作类型．但是 Ｓｐａｒｋ不适用异步细粒度更新状态的应用，同时在 容错性方面有待提升．Ｆａｃｅｂｏｏｋ结合自己的应用场
景构建了实时的 Ｈａｄｏｏｐ系统［８４］，主要是实现了高 可用的 ＮａｍｅＮｏｄｅ，对并发读和实时负载性能进行 了优化，改造 ＨＢａｓｅ使其适合真实的实时生产环境． ３）二者的融合．有不少研究人员尝试将流处理 和 批 处 理 模 式 进 行 融 合，主 要 思 路 是 利 用 ＭａｐＲｅｄｕｃｅ模型实现流处理．文献［８５］着重探讨了 将 ＭａｐＲｅｄｕｃｅ模型应用到流处理这种单遍分析 （ ｏｎｅ －ｐａｓｓ ａｎａｌ ｙ ｔｉｃｓ）的应用时在架构上应当进行怎 样的调整．在此分析基础上，文献［８６］介绍了一种利 用 ＭａｐＲｅｄｕｃｅ实现的适用于单遍分析的可扩展平 台．ＤＥＤＵＣＥ 系统［８７］扩展了ＩＢＭ 的流处理软件 Ｓｙｓｔｅｍ Ｓ，使其支持 ＭａｐＲｅｄｕｃｅ．Ｃ－ＭＲ 系统［８８］通 过３个方面的工作实现了支持流处理的持续型 ＭａｐＲｅｄｕｃｅ（Ｃｏｎｔｉｎｕｏｕｓ －ＭａｐＲｅｄｕｃｅ）：①将并行流 处理中的窗口概念透明的扩展到 ＭａｐＲｅｄｕｃｅ模型 中；②有效结合了包括ＣＰＵ 和 ＧＰＵ 在内的多种异 构计算能力；③支持灵活、动态的工作流调度．Ｍ３［８９］ 在 Ｈａｄｏｏｐ系统基础上进行扩展，绕开 ＨＤＦＳ的限 制，实现了一个全内存处理的高效流处理系统．
ＳｔｒｅａｍＭａ ｐＲｅｄｕｃｅ ［ ９０］结合事件流处理（ｅｖｅｎｔ ｓｔｒｅａｍ ｐｒｏｃｅｓｓｉｎｇ）的特点，对 ＭａｐＲｅｄｕｃｅ中的 Ｍａｐｐｅｒ和 Ｒｅｄｕｃｅｒ进行重新定义，增加了持续的、低延迟的 数据处理能力．文献［９１］认为大数据时代快速数 据（ｆａｓｔ ｄａｔａ）的处理是一个非常典型的场景，比如 数据流．在充分调研基础上，作者认为原始的 ＭａｐＲｅｄｕｃｅ框架不适合处理快速数据．结合快速数 据的特点，文中设计了一个类似 ＭａｐＲｅｄｕｃｅ的框 架———ＭａｐＵｐｄａｔｅ，并在该框架基础上实现了一个 原型系统 Ｍｕｐｐｅｔ．和上述这些系统相比，ＳＳＳ［９２］最 大的特点就是在支持快速流处理的同时也能够支持 大规模静态数据的处理，也就是说兼具流处理和批 处理．文献 ［９３］中提出名为离散流（ｄｉｓｃｒｅｔｉｚｅｄ ｓｔｒｅａｍｓ）的编程模型，并在Ｓｐａｒｋ基础上实现了一 个原型系统Ｓｐａｒｋ Ｓｔｒｅａｍｉｎｇ． ３．２ 大数据处理工具 关系数据库在很长的时间里成为数据管理的最 佳选择，但是在大数据时代，数据管理、分析等的需 求多样化使得关系数据库在很多场景不再适用．本 节将对现今主流的大数据处理工具进行一个简单的 归纳和总结． Ｈａｄｏｏｐ是目前最为流行的大数据处理平台． Ｈａｄｏｏｐ 最 先 是 Ｄｏｕｇ Ｃｕｔｔｉｎｇ 模 仿 ＧＦＳ， ＭａｐＲｅｄｕｃｅ实现的一个云计算开源平台，后贡献给 Ａｐａｃｈｅ．Ｈａｄｏｏｐ 已经发展成为包括文件系统
１５８ 计算机研究与发展 ２０１３，５０（ １）
（ＨＤＦＳ）、数据库 （ＨＢａｓｅ、Ｃａｓｓａｎｄｒａ）、数据处理 （ＭａｐＲｅｄｕｃｅ）等功能模块在内的完整生态系统 （ Ｅｃｏｓ ｙｓｔｅｍ）．某种程度上可以说 Ｈａｄｏｏｐ已经成为 大数据处理工具事实上的标准． 对 Ｈａｄｏｏｐ改进并将其应用于各种场景的大数 据处理已经成为新的研究热点．主要的研究成果集 中在对 Ｈａｄｏｏｐ平台性能的改进［９４ －９７］、高效的查询 处理［９８ －１０３］、索引构建和使用［１０４ －１０５］、在 Ｈａｄｏｏｐ之上 构建数据仓库［１０６ －１０８］、Ｈａｄｏｏｐ和数据库系统的连
接［１０９ －１１１］、数据挖掘［１１２ －１１５］、推荐系统［１１６ －１１８］等． 除了 Ｈａｄｏｏｐ，还有很多针对大数据的处理工 具．这些工具有些是完整的处理平台，有些则是专门 针对特定的大数据处理应用． 表７归纳总结了现今一些主流的处理平台和工 具，这些平台和工具或是已经投入商业使用，或是开 源软件．在已经投入商业使用的产品中，绝大部分也 是在 Ｈａｄｏｏｐ基础上进行功能扩展，或者提供与 Ｈａｄｏｏｐ的数据接口．