王珊,王会举,覃雄派,周烜-架构大数据-挑战现状与展望

书书 第３４卷　第１０期２０１１年１０月 计　　算　　机　　学　　报ＣＨＩＮＥＳＥＪＯＵＲＮＡＬＯＦＣＯＭＰＵＴＥＲＳ Ｖｏｌ．３４Ｎｏ．１０Ｏｃｔ．２０１１　 收稿日期：２０１１０８１２；最终修改稿收到日期：２０１１０９１５．本课题得到国家重大科技专项核高基项目（２０１０ＺＸ０１０４２００１００２）、国家自然 科学基金（６１０７００５４，６１１７００１３）、中国人民大学科学研究基金（中央高校基本科研业务费专项资金，１０ＸＮＩ０１８）、中国人民大学研究生基 金（１１ＸＮＨ１２０）资助．王　珊，女，１９４４年生，教授，博士生导师，中国计算机学会（ＣＣＦ）高级会员，主要研究领域为高性能数据库、知识工 程、数据仓库．Ｅｍａｉｌ：ｓｗａｎｇ＠ｒｕｃ．ｅｄｕ．ｃｎ．王会举，男，１９７９年生，博士研究生，主要研究方向为大规模集群数据库、内存数据库．Ｅｍａｉｌ： ｗａｎｇｈｕｉｊｕ＠ｒｕｃ．ｅｄｕ．ｃｎ．覃雄派，男，１９７１年生，博士，讲师，中国计算机学会（ＣＣＦ）会员，主要研究方向为数据库查询优化、内存数据库、 并行数据库．周　?，男，１９７９年生，博士，副教授，主要研究方向为信息检索、高性能数据库． 架构大数据：挑战、现状与展望 王　珊１），２）　王会举１），２）　覃雄派１），２）　周　?１），２） １）（数据与知识工程教育部重点实验室（中国人民大学）　北京　１００８７２） ２）（中国人民大学信息学院　北京　１００８７２） 摘　要　大数据分析相比于传统的数据仓库应用，具有数据量大、查询分析复杂等特点．为了适合大数据分析 的数据仓库架构，文中列举了大数据分析平台需要具备的几个重要特性，对当前的主流实现平台———并行数据库、 ＭａｐＲｅｄｕｃｅ及基于两者的混合架构进行了分析归纳，指出了各自的优势及不足，同时也对各个方向的研究现状及 作者在大数据分析方面的努力进行了介绍，对未来研究做了展望． 关键词　大数据；大规模可扩展；ＭａｐＲｅｄｕｃｅ；并行数据库；深度分析 中图法分类号ＴＰ３１１　　　犇犗犐号：１０．３７２４／ＳＰ．Ｊ．１０１６．２０１１．０１７４１ 犃狉犮犺犻狋犲犮狋犻狀犵犅犻犵犇犪狋犪：犆犺犪犾犾犲狀犵犲狊，犛狋狌犱犻犲狊犪狀犱犉狅狉犲犮犪狊狋狊 ＷＡＮＧＳｈａｎ１），２）　ＷＡＮＧＨｕｉＪｕ１），２）　ＱＩＮＸｉｏｎｇＰａｉ１），２）　ＺＨＯＵＸｕａｎ１），２） １）（犓犲狔犔犪犫狅狉犪狋狅狉狔狅犳犇犪狋犪犈狀犵犻狀犲犲狉犻狀犵犪狀犱犓狀狅狑犾犲犱犵犲犈狀犵犻狀犲犲狉犻狀犵（犚犲狀犿犻狀犝狀犻狏犲狉狊犻狋狔狅犳犆犺犻狀犪）狅犳犕犻狀犻狊狋狉狔狅犳犈犱狌犮犪狋犻狅狀，犅犲犻犼犻狀犵１００８７２） ２）（犛犮犺狅狅犾狅犳犐狀犳狅狉犿犪狋犻狅狀，犚犲狀犿犻狀犝狀犻狏犲狉狊犻狋狔狅犳犆犺犻狀犪，犅犲犻犼犻狀犵　１００８７２） 犃犫狊狋狉犪犮狋　Ｃｏｍｐａｒｅｄｗｉｔｈｔｒａｄｉｔｉｏｎａｌｄａｔａｗａｒｅｈｏｕｓｅａｐｐｌｉｃａｔｉｏｎｓ，ｂｉｇｄａｔａａｎａｌｙｔｉｃｓａｒｅｈｕｇｅａｎｄ ｃｏｍｐｌｅｘ．Ｔｏｄｅｓｉｇｎａｆａｖｏｒａｂｌｅａｒｃｈｉｔｅｃｔｕｒｅｆｏｒｂｉｇｄａｔａａｎａｌｙｔｉｃｓ，ｔｈｉｓｐａｐｅｒｌｉｓｔｓｓｏｍｅｋｅｙｆｅａ ｔｕｒｅｓｆｏｒｂｉｇｄａｔａａｎａｌｙｔｉｃｓ，ｓｕｍｍａｒｉｚｅｓｃｕｒｒｅｎｔｍａｉｎｉｍｐｌｅｍｅｎｔａｔｉｏｎｐｌａｔｆｏｒｍｓ（ｐａｒａｌｌｅｌｄａｔａｂａｓ ｅｓ，ＭａｐＲｅｄｕｃｅ，ａｎｄｈｙｂｒｉｄａｒｃｈｉｔｅｃｔｕｒｅｓｂａｓｅｄｏｎｔｈｅｍ），ａｎｄｐｏｉｎｔｓｔｈｅｉｒｐｒｏｓａｎｄｃｏｎｓ．Ｓｏｍｅ ｃｕｒｒｅｎｔｒｅｓｅａｒｃｈｅｓａｒｅａｌｓｏｉｎｖｅｓｔｉｇａｔｅｄ，ｏｕｒｗｏｒｋａｒｅｉｎｔｒｏｄｕｃｅｄａｎｄｓｏｍｅｃｈａｌｌｅｎｇｉｎｇｒｅｓｅａｒｃｈ ｐｒｏｂｌｅｍｓｉｎｔｈｅｆｕｔｕｒｅａｒｅｄｉｓｃｕｓｓｅｄ． 犓犲狔狑狅狉犱狊　ｂｉｇｄａｔａ；ｌａｒｇｅｓｃａｌｅ；ＭａｐＲｅｄｕｃｅ；ｐａｒａｌｌｅｌｄａｔａｂａｓｅ；ｄｅｅｐａｎａｌｙｔｉｃｓ １　引　言 最近几年，数据仓库又成为数据管理研究的热 点领域，主要原因是当前数据仓库系统面临的需求 在数据源、需提供的数据服务和所处的硬件环境等 方面发生了根本性的变化（详见１．１节），这些变化 是我们必须面对的． 本文在大数据的时代背景下，对现有数据仓库 系统实现方案（主要是并行数据库和ＭａｐＲｅｄｕｃｅ） 进行重新审视，期望能为设计满足时代需求的数据 仓库系统提供理论参考．限于篇幅，本文主要关注不 同数据仓库实现方案的主体架构及其缺陷在最近几 年的改进情况．依据研究立足点的不同，本文将该领 域的研究归为三大类：并行数据库、ＭａｐＲｅｄｕｃｅ、并 行数据库和ＭａｐＲｅｄｕｃｅ技术的混合架构．其中第三 类研究又细分为：并行数据库主导型、ＭａｐＲｅｄｕｃｅ 主导型、并行数据库和ＭａｐＲｅｄｕｃｅ集成型三种．本 文第１节分析大数据时代，数据仓库所面临的问题 及挑战；第２节列出大数据时代的数据仓库平台需 具备的几个重要特性；第３节到第５节就这几个特 性对各类平台进行归纳分析；第６节对最新研究做 一跟踪归纳；第７节介绍中国人民大学在大数据分 析方面的研究工作；第８节对未来研究做出展望；第 ９节总结全文． １．１　三个变化 （１）数据量．由ＴＢ级升至ＰＢ级，并仍在持续 爆炸式增长．根据ＷｉｎｔｅｒＣｏｒｐ的调查显示，最大的 数据仓库中的数据量，每两年增加３倍［１］（年均增长 率为１７３％），其增长速度远超摩尔定律增长速度． 照此增长速度计算，２０１５年最大数据仓库中的数据 量将逼近１００ＰＢ． （２）分析需求．由常规分析转向深度分析（Ｄｅｅｐ Ａｎａｌｙｔｉｃｓ）．数据分析日益成为企业利润必不可少的 支撑点．根据ＴＤＷＩ对大数据分析的报告［２］（如图１）， 企业已经不满足于对现有数据的分析和监测，而是更 期望能对未来趋势有更多的分析和预测，以增强企 业竞争力．这些分析操作包括诸如移动平均线分析、 数据关联关系分析、回归分析、市场篮分析等复杂统 计分析，我们称之为深度分析．值得补充的是，本文 中的大数据分析不仅仅指基于大数据上的深度分 析，也包括常规分析． 图１　分析的趋势 （３）硬件平台．由高端服务器转向由中低端硬 件构成的大规模机群平台．由于数据量的迅速增加， 并行数据库的规模不得不随之增大，从而导致其成 本的急剧上升．出于成本的考虑，越来越多的企业将 应用由高端服务器转向了由中低端硬件构成的大规 模机群平台． １２　两个问题 图２是一个典型的数据仓库架构［３］．从图中我 们可以看出，传统的数据仓库将整个实现划分为４ 个层次，数据源中的数据首先通过ＥＴＬ工具被抽取 到数据仓库中进行集中存储和管理，再按照星型模 型或雪花模型组织数据，然后ＯＬＡＰ工具从数据仓 库中读取数据，生成数据立方体（ＭＯＬＡＰ）或者直 接访问数据仓库进行数据分析（ＲＯＬＡＰ）．在大数据 时代，此种计算模式存在两个问题： 问题１．数据移动代价过高．在数据源层和分 析层之间引入一个存储管理层，可以提升数据质量 并针对查询进行优化，但也付出了较大的数据迁移 代价和执行时的连接代价：数据首先通过复杂且耗 时的ＥＴＬ过程存储到数据仓库中，在ＯＬＡＰ服务 器中转化为星型模型或者雪花模型；执行分析时，又 通过连接方式将数据从数据库中取出．这些代价在 ＴＢ级时也许可以接受，但面对大数据，其执行时间 至少会增长几个数量级．更为重要的是，对于大量的 即席分析，这种数据移动的计算模式是不可取的． 图２　一个典型的数据仓库架构 问题２．不能快速适应变化．传统的数据仓库 假设主题是较少变化的，其应对变化的方式是对数 据源到前端展现的整个流程中的每个部分进行修 改，然后再重新加载数据，甚至重新计算数据，导致 其适应变化的周期较长．这种模式比较适合对数据 质量和查询性能要求较高、而不太计较预处理代价 的场合．但在大数据时代，分析处在变化的业务环境 中，这种模式将难以适应新的需求． １．３　一个鸿沟 在大数据时代，巨量数据与系统的数据处理能 力之间将会产生一个鸿沟：一边是至少ＰＢ级的数 据量，另一边是面向传统数据分析能力设计的数据 仓库和各种ＢＩ工具．如果这些系统或工具发展缓 慢，该鸿沟将会随着数据量的持续爆炸式增长而逐 步拉大． 虽然，传统数据仓库可以采用舍弃不重要数据 或者建立数据集市的方式来缓解此问题，但毕竟只 ２４７１ 计　　算　　机　　学　　报 ２０１１年 是权益之策，并非系统级解决方案．而且，舍弃的数 据在未来可能会重新使用，以发掘更大的价值． ２　期望特性 本节我们列出对大数据进行分析时，数据仓库 系统需具备的几个重要特性（表１所示）． 表１　大数据分析平台需具备的特性 特性　 简要说明高度可扩展性 横向大规模可扩展，大规模并行处理 高性能 快速响应复杂查询与分析 高度容错性 查询失败时，只需重做部分工作 支持异构环境 对硬件平台一致性要求不高，适应能力强 较低的分析延迟 业务需求变化时，能快速反应 易用且开放接口 既能方便查询，又能处理复杂分析 较低成本 较高的性价比 向下兼容性 支持传统的商务智能工具 高度可扩展性．一个明显的事实是，数据库不 能依靠一台或少数几台机器的升级（ｓｃａｌｅｕｐ纵向 扩展）满足数据量的爆炸式增长，而是希望能方便地 做到横向可扩展（ｓｃａｌｅｏｕｔ）来实现此目标． 普遍认为ｓｈａｒｅｄｎｏｔｈｉｎｇ无共享结构（每个节 点拥有私有内存和磁盘，并且通过高速网络同其它 节点互连）具备较好的扩展性［４］．分析型操作往往涉 及大规模的并行扫描、多维聚集及星型连接操作，这 些操作也比较适合在无共享结构的网络环境运行． Ｔｅｒａｄａｔａ即采用此结构，Ｏｒａｃｌｅ在其新产品Ｅｘａｄａｔａ 中也采用了此结构． 高性能．数据量的增长并没有降低对数据库性 能的要求，反而有所提高．软件系统性能的提升可以 降低企业对硬件的投入成本、节省计算资源，提高系 统吞吐量．巨量数据的效率优化，并行是必由之路． １ＰＢ数据在５０ＭＢ／ｓ速度下串行扫描一次，需要 ２３０天；而在６０００块磁盘上，并行扫描１ＰＢ数据只 需要１个小时． 高度容错．大数据的容错性要求在查询执行过 程中，一个参与节点失效时，不需要重做整个查询． 而机群节点数的增加会带来节点失效概率的增加． 在大规模机群环境下，节点的失效将不再是稀有事 件（Ｇｏｏｇｌｅ报告，平均每个ＭａｐＲｅｄｕｃｅ数据处理任 务就有１．２个工作节点失效［５］）．因此在大规模机群 环境下，系统不能依赖于硬件来保证容错性，要更多 地考虑软件级容错． 支持异构环境．建设同构系统的大规模机群难 度较大，原因在于计算机硬件更新较快，一次性购置 大量同构的计算机是不可取的，而且也会在未来添 置异构计算资源．此外，不少企业已经积累了一些闲 置的计算机资源，此种情况下，对异构环境的支持可 以有效地利用这些闲置计算资源，降低硬件成本的 投入．还需特别关注的是，在异构环境下，不同节点 的性能是不一样的，可能出现“木桶效应”，即最慢节 点的性能决定整体处理性能．因此，异构的机群需要 特别关注负载均衡、任务调度等方面的设计． 较低的分析延迟．分析延迟指的是分析前的数 据准备时间．在大数据时代，分析所处的业务环境是 变化的，因此也要求系统能动态地适应业务分析需 求．在分析需求发生变化时，减少数据准备时间，系 统能尽可能快地做出反应，快速地进行数据分析． 易用且开放的接口．ＳＱＬ的优点是简单易用， 但其主要用于数据的检索查询，对于大数据上的深 度分析来讲，是不够的．原因在于：（１）其提供的服 务方式依赖于数据移动来实现：将数据从数据库中 取出，然后传递给应用程序，该实现方式在大数据时 代代价过高；（２）复杂的分析功能，如Ｒ或Ｍａｔｌａｂ 中的分析功能，ＳＱＬ是难以胜任的．因此，除对ＳＱＬ 的支持外，系统还应能提供开放的接口，让用户自己 开发需要的功能．设计该接口时，除了关注其易用性 和开放性，还需要特别注意两点隐藏的要求：（１）基 于接口开发的用户自定义函数，能自动在机群上并 行执行；（２）分析在数据库内进行，即分析尽可能靠 近数据． 较低的成本．在满足需求的前提下，某技术成 本越低，其生命力就越强．需要指出的是成本是一个 综合指标，不仅仅是硬件或软件的代价，还应包括日 常运维成本（网络费用、电费、建筑等）和管理人员成 本等．据报告，数据中心的主要成本不是硬件的购置 成本，而是日常运维成本．因此，在设计系统时需要 更多地关注此项内容． 向下兼容性．数据仓库发展的３０年，产生了大 量面向客户业务的数据处理工具（如Ｉｎｆｏｒｍａｃｔｉｃａ、 ＤａｔａＳｔａｇｅ等）、分析软件（如ＳＰＳＳ、Ｒ、Ｍａｔｌａｂ等）和 前端展现工具（如水晶报表）等．这些软件是一笔宝 贵的财富，已被分析人员所熟悉，是大数据时代中小 规模数据分析的必要补充．因此，新的数据仓库需考 虑同传统商务智能工具的兼容性．由于这些系统往 往提供驱动程序，如ＯＤＢＣ、ＪＤＢＣ等，这项需 求的实际要求是对ＳＱＬ的支持． 总之，以较低的成本投入、高效地进行数据分 析，是大数据分析的基本目标． ３４７１１０期 王　珊等：架构大数据：挑战、现状与展望 ３　并行数据库 并行数据库起源于２０世纪８０年代，当前主流 的并行数据库都同早期的Ｇａｍｍａ［６］和Ｇｒａｃｅ［７］等 并行数据库类似．这些数据库都支持标准ＳＱＬ，并 且实现了数据库界过去３０年提出的许多先进技术． 其主要采用ｓｈａｒｅｄｎｏｔｈｉｎｇ结构，将关系表在节点 间横向划分，并且利用优化器来对执行过程进行调 度和管理．其目标是高性能和高可用性． 并行数据库的最大优势在于性能．这主要得益 于数据库界近几十年的研究成果———许多先进的技 术手段及算法，如索引、数据压缩、物化视图、结果缓 冲、Ｉ／Ｏ共享、优化的数据连接等．但是在大数据时 代，如前言所述，数据移动的实现方式将影响其 性能． 并行数据库通过ＳＱＬ向外提供数据访问服务， ＳＱＬ因其简单易用的特点而被广泛使用．因此，大 多ＢＩ工具都支持基于标准ＳＱＬ的数据交互方式， 使得关系数据库能较好地兼容当前多数ＢＩ工具．某 些数据库，如ＩＢＭＤＢ２还针对一些ＢＩ工具进行了 优化．但在大数据分析面前，ＳＱＬ接口面临巨大挑 战．ＳＱＬ的优势源于其对底层数据访问的封装，但 封装在一定程度上影响了其开放性．而且并行数据 库提供的用户自定义函数大都是基于单数据库实例 设计的，从而不能在机群上并行执行，也即意味着传 统的实现方式不适合大数据的处理及分析．而且，在 并行数据库中实现用户自定义函数往往需要经过复 杂的系统交互，甚至要熟悉数据库的内部结构及系 统调用等，从而难以使用． 并行数据库在扩展性、容错性、成本、对异构环 境的支持等几项上有所欠缺．这几项实际是相互影 响的，我们以其最大问题———扩展性为主线展开讨 论．并行数据库大多支持有限扩展，一般可扩至数百 节点的规模，尚未有数千节点规模的应用案例．并行 数据库扩展性有限主要因为如下几点：（１）并行数 据库软件级容错能力较差．并行数据库基于高端硬 件设计，并且假设查询失败属于稀有事件．因此当查 询失败时，一般采取重做查询的方式．而在大规模机 群环境下，查询失败将会变为一个普通事件．极端情 况下，并行数据有可能出现不停重做查询的局面； （２）并行数据库对异构硬件的支持非常有限，且对 于处理较慢的节点反应敏感，容易出现“木桶效应”． 如第２节中所论述的，完全基于同构硬件搭建大规 模机群在现实中是较难实现的．因而，对异构硬件的 支持能力影响了其扩展性；（３）并行数据库若做到大 规模可扩展，其代价将会较高（需基于高端硬件来保 证可靠性，需购买昂贵的软件系统），从而限制了其 扩展性；（４）根据ＣＡＰ理论①［８］，在分布式系统中，数 据一致性（Ｃｏｎｓｉｓｔｅｎｃｙ）、可用性（Ａｖａｉｌａｂｉｌｉｔｙ）、子 网可分解性（ＮｅｔｗｏｒｋＰａｒｔｉｔｉｏｎｉｎｇ）不可同时兼得， 选择其中任两项，便会损害另一项．并行数据库追求 的是数据一致性和系统的可用性，从而影响了它的 扩展能力． 此外，如１．２节所讨论的，基于并行数据库实现 的传统数据仓库借助于外围工具（ＥＴＬ工具、ＯＬＡＰ 产品、ＢＩ报表工具、统计分析软件等）来完成数据的 预处理和分析展现任务，导致其数据处理及分析过 程涉及大量的数据迁移和计算，分析延迟往往较高． ４　犕犪狆犚犲犱狌犮犲 ＭａｐＲｅｄｕｃｅ［５］是２００４年由Ｇｏｏｇｌｅ提出的面向 大数据集处理的编程模型，起初主要用作互联网数 据的处理，例如文档抓取、倒排索引的建立等．但由 于其简单而强大的数据处理接口和对大规模并行执 行、容错及负载均衡等实现细节的隐藏，该技术一经 推出便迅速在机器学习、数据挖掘、数据分析等领域 得到广泛应用［９］． ＭａｐＲｅｄｕｃｅ将数据处理任务抽象为一系列的 Ｍａｐ（映射）Ｒｅｄｕｃｅ（化简）操作对．Ｍａｐ主要完成数 据的过滤操作，Ｒｅｄｕｃｅ主要完成数据的聚集操作． 输入输出数据均以〈ｋｅｙ，ｖａｌｕｅ〉格式存储．用户在使 用该编程模型时，只需按照自己熟悉的语言实现 Ｍａｐ函数和Ｒｅｄｕｃｅ函即可，ＭａｐＲｅｄｕｃｅ框架会自 动对任务进行划分以做到并行执行． 下面本文将以基于ＭａｐＲｅｄｕｃｅ的开源实现 Ｈａｄｏｏｐ［１０］为主，对其主要特性进行介绍． ＭａｐＲｅｄｕｃｅ是面向由数千台中低端计算机组 成的大规模机群而设计的，其扩展能力得益于其 ｓｈａｒｅｄｎｏｔｈｉｎｇ结构、各个节点间的松耦合性和较 强的软件级容错能力：节点可以被任意地从机群中 移除，而几乎不影响现有任务的执行．该技术被称为 ＲＡＩＮ（Ｒｅｄｕｎｄａｎｔ／ＲｅｌｉａｂｌｅＡｒｒａｙｏｆＩｎｄｅｐｅｎｄｅｎｔ （ａｎｄＩｎｅｘｐｅｎｓｉｖｅ）Ｎｏｄｅｓ）．ＭａｐＲｅｄｕｃｅ卓越的扩展 能力已在工业界（Ｇｏｏｇｌｅ、Ｆａｃｅｂｏｏｋ、Ｂａｉｄｕ、Ｔａｏｂａｏ ４４７１ 计　　算　　机　　学　　报 ２０１１年 ①该理论目前尚存争议． 等）得到了充分验证．ＭａｐＲｅｄｕｃｅ对硬件的要求较 低，可以基于异构的廉价硬件来搭建机群，且免费开 源，因此其构建成本低于并行数据库．但基于 ＭａｐＲｅｄｕｃｅ的应用软件相对较少，许多数据分析功 能需要用户自行开发，从而会导致使用成本的增加． 作为开源系统，ＭａｐＲｅｄｕｃｅ具有完全的开放 性：其〈ｋｅｙ，ｖａｌｕｅ〉存储模型具有较强的表现力，可 以存储任意格式的数据；Ｍａｐ和Ｒｅｄｕｃｅ两个基本 的函数接口也给用户提供了足够的发挥空间，可以 实现各种复杂的数据处理功能．但这种开放性也带来 一个问题，就是将本来应由数据库管理系统完成的工 作，诸如文件存储格式的设计、模式信息的记录、数据 处理算法的实现等，转移给了程序员，从而导致程序 员负担过重．程序员水平对系统处理性能起决定性作 用．在某些情况下，写ＭａｐＲｅｄｕｃｅ程序的时间远大于 写ＳＱＬ语句的时间，部分复杂的ＢＩ报表分析，可能 仅程序的编写和调试就要耗费几天的时间． 基于ＭａｐＲｅｄｕｃｅ平台的分析，无需复杂的数据 预处理和写入数据库的过程，而是可以直接基于平 面文件进行分析，并且其采用的计算模式是移动计 算而非移动数据，因此可以将分析延迟最小化． 在同等硬件条件下，ＭａｐＲｅｄｕｃｅ性能远低于并 行数据库［１１］，这是由其最初的设计定位决定的． ＭａｐＲｅｄｕｃｅ的设计初衷是面向非结构化数据的处 理．这些数据具有数据量大，处理复杂等特点，而且 往往是一次性处理．为了获得较好的扩展能力和容 错能力，ＭａｐＲｅｄｕｃｅ采取了基于扫描的处理模式和 对中间结果步步物化的执行策略，从而导致较高的 Ｉ／Ｏ代价．为了减少数据预处理时间，ＭａｐＲｅｄｕｃｅ 没有使用模式、索引、物化视图等技术手段．其数据 预处理仅是一次数据加载操作，但由此导致了一个 问题———较高的元组解析代价［１２］．在ＭａｐＲｅｄｕｃｅ 环境下，每个查询都是直接从文件系统中读入原始 数据文件，而非传统的从数据库中读入经处理过的 文件，因此其元组解析代价远高于关系数据库．对 数据分析领域来说，连接是关键操作（如传统的星型 查询和雪花查询均是依赖于连接来处理查询），但 ＭａｐＲｅｄｕｃｅ处理连接的性能尤其不尽如人意．原因 在于ＭａｐＲｅｄｕｃｅ最初是针对单数据集设计的处理 模型，而连接操作往往涉及多个数据集．在利用 ＭａｐＲｅｄｕｃｅ实现连接时，最直接的方式是每个任务 执行一个属性上的连接操作，然后将多个ＭａｐＲｅｄｕｃｅ 任务通过物化的中间结果串接起来．这种实现方式 往往涉及中间结果的读写，从而导致大量的Ｉ／Ｏ操 作和网络传输． ＭａｐＲｅｄｕｃｅ目前基本不兼容现有的ＢＩ工具． 原因在于其初衷并不是要成为数据库系统，因此它 并未提供ＳＱＬ接口．但已有研究致力于ＳＱＬ语句 与ＭａｐＲｅｄｕｃｅ任务的转换工作（例如Ｈｉｖｅ），进而 有可能实现ＭａｐＲｅｄｕｃｅ与现存ＢＩ工具的兼容． ５　并行数据库和犕犪狆犚犲犱狌犮犲的混合架构 基于以上分析，我们可以清楚地看出，基于并行 数据库和ＭａｐＲｅｄｕｃｅ实现的数据仓库系统都不是 大数据分析的理想方案．针对两者哪个更适合时代 需求的问题，业界近年展开了激烈争论．当前基本达 成如下共识：并行数据库和ＭａｐＲｅｄｕｃｅ是互补关 系，应该相互学习［１３１４］．基于该观点，大量研究着手 将两者结合起来，期望设计出兼具两者优点的数据 分析平台．这种架构又可以分为三类：并行数据库主 导型、ＭａｐＲｅｄｕｃｅ主导型、ＭａｐＲｅｄｕｃｅ和并行数据 库集成型（表２对３种架构进行了对比分析）． 表２　混合架构型解决方案对比分析 解决方案 着眼点 代表系统 缺陷 并行数据库主导型 利用ＭａｐＲｅｄｕｃｅ技术来增强其开放性，以实现处理能力的可扩展 ＧｒｅｅｎｐｌｕｍＡｓｔｅｒＤａｔａ 规模扩展性未改变 ＭａｐＲｅｄｕｃｅ主导型 学习关系数据库的ＳＱＬ接口及模式支持等，改善其易用性 ＨｉｖｅＰｉｇＬａｔｉｎ 性能问题未改变 并行数据库和ＭａｐＲｅｄｕｃｅ集成型 集成两者，使两者各自做各自擅长的工作 ＨａｄｏｏｐＤＢ 只有少数查询可以下推至数据库层执行，各自的某些优点在集成后也丧失了 Ｖｅｒｔｉｃａ 性能和扩展性仍不能兼得 Ｔｅｒａｄａｔａ 规模扩展性未变 ５．１　并行数据库主导型 该种方式关注于如何利用ＭａｐＲｅｄｕｃｅ来增强并 行数据库的数据处理能力．代表性系统是Ｇｒｅｅｎｐｌｕｍ （已被ＥＭＣ收购）和ＡｓｔｅｒＤａｔａ（已被Ｔｅｒａｄａｔａ收购）． ＡｓｔｅｒＤａｔａ将ＳＱＬ和ＭａｐＲｅｄｕｃｅ进行结合， 针对大数据分析提出了ＳＱＬ／ＭａｐＲｅｄｕｃｅ框架［１５］． ５４７１１０期 王　珊等：架构大数据：挑战、现状与展望 该框架允许用户使用Ｃ＋＋、ｊａｖａ、Ｐｙｔｈｏｎ等语言编 写ＭａｐＲｅｄｕｃｅ函数，编写的函数可以作为一个子查 询在ＳＱＬ中使用，从而同时获得ＳＱＬ的易用性和 ＭａｐＲｅｄｕｃｅ的开放性．不仅如此，ＡｓｔｅｒＤａｔａ基于 ＭａｐＲｅｄｕｃｅ实现了３０多个统计软件包，从而将数 据分析推向数据库内进行（数据库内分析），大大提 升了数据分析的性能． Ｇｒｅｅｎｐｌｕｍ也在其数据库中引入了ＭａｐＲｅｄｕｃｅ 处理功能［１６］．其执行引擎可以同时处理ＳＱＬ查询 和ＭａｐＲｅｄｕｃｅ任务．这种方式在代码级整合了ＳＱＬ 和ＭａｐＲｅｄｕｃｅ：ＳＱＬ可以直接使用ＭａｐＲｅｄｕｃｅ任 务的输出，同时ＭａｐＲｅｄｕｃｅ任务也可以使用ＳＱＬ 的查询结果作为输入． 总的来说，这些系统都集中于利用ＭａｐＲｅｄｕｃｅ 来改进并行数据库的数据处理功能，其根本性问 题———可扩展能力和容错能力并未改变． ５．２　犕犪狆犚犲犱狌犮犲主导型该方向的研究主要集中于利用关系数据库的 ＳＱＬ接口和对模式的支持等技术来改善ＭａｐＲｅｄｕｃｅ 的易用性，代表系统是Ｈｉｖｅ［１７］、ＰｉｇＬａｔｉｎ［１８］等． Ｈｉｖｅ是Ｆａｃｅｂｏｏｋ提出的基于Ｈａｄｏｏｐ的大型 数据仓库，其目标是简化Ｈａｄｏｏｐ上的数据聚集、 ａｄｈｏｃ查询及大数据集的分析等操作，以减轻程序 员的负担．它借鉴关系数据库的模式管理、ＳＱＬ接 口等技术，把结构化的数据文件映射为数据库表，提 供类似于ＳＱＬ的描述性语言ＨｉｖｅＱＬ供程序员使 用，可自动将ＨｉｖｅＱＬ语句解析成一优化的Ｍａ ｐＲｅｄｕｃｅ任务执行序列．此外，它也支持用户自定义 的ＭａｐＲｅｄｕｃｅ函数． ＰｉｇＬａｔｉｎ是Ｙａｈｏｏ！提出的类似于Ｈｉｖｅ的大 数据集分析平台．两者的区别主要在于语言接口． Ｈｉｖｅ提供了类似ＳＱＬ的接口，ＰｉｇＬａｔｉｎ提供的是 一种基于操作符的数据流式的接口．图３是Ｐｉｇ Ｌａｔｉｎ在处理查询时的一个操作实例．该查询的目的 是找出“年龄在１８～２５周岁之间的用户（Ｕｓｅｒｓ）最 频繁访问的５个页面（Ｐａｇｅｓ）”．从图３可以看出， Ｐｉｇ提供的操作接口类似于关系数据库的操作符 （对应图中右侧部分中的每一行命令），用户查询的 脚本类似于逻辑查询计划（对应图中左侧部分）．因 此，也可以说Ｐｉｇ利用操作符来对Ｈａｄｏｏｐ进行封 装，Ｈｉｖｅ利用ＳＱＬ进行封装． ５．３　犕犪狆犚犲犱狌犮犲和并行数据库集成型该方向的代表性研究是耶鲁大学提出的 ＨａｄｏｏｐＤＢ［１９］（已于２０１１年商业化为Ｈａｄａｐｔ［２０］）、 图３　ＰｉｇＬａｔｉｎ的一个查询示例（右边为实际脚本） Ｓｔｏｎｅｂｒａｋｅｒ等人设计的Ｖｅｒｔｉｃａ［２１］数据库和ＮＣＲ 公司的Ｔｅｒａｄａｔａ［２２］数据库． ＨａｄｏｏｐＤＢ的核心思想是利用Ｈａｄｏｏｐ作为调 度层和网络沟通层，关系数据库作为执行引擎，尽可 能地将查询压入数据库层处理．目标是想借助 Ｈａｄｏｏｐ框架来获得较好的容错性和对异构环境的 支持；通过将查询尽可能推入数据库中执行来获得 关系数据库的性能优势．ＨａｄｏｏｐＤＢ的思想是深远 的，但目前尚无应用案例，原因在于：（１）其数据预 处理代价过高：数据需要进行两次分解和一次数据 库加载操作后才能使用；（２）将查询推向数据库层 只是少数情况，大多数情况下，查询仍由Ｈｉｖｅ完 成．因为数据仓库查询往往涉及多表连接，由于连接 的复杂性，难以做到在保持连接数据局部性的前提 下将参与连接的多张表按照某种模式划分；（３）维 护代价过高．不仅要维护Ｈａｄｏｏｐ系统，还要维护每 个数据库节点；（４）目前尚不支持数据的动态划分，需 要手工方式将数据一次性划分好．总的来说，Ｈａ ｄｏｏｐＤＢ在某些情况下，可以同时实现关系数据库 的高性能特性和ＭａｐＲｅｄｕｃｅ的扩展性、容错性，但 同时也丧失了关系数据库和ＭａｐＲｅｄｕｃｅ的某些优 点，比如ＭａｐＲｅｄｕｃｅ较低的预处理代价和维护代 价、关系数据库的动态数据重分布等． Ｖｅｒｔｉｃａ采用的是共存策略：根据Ｈａｄｏｏｐ和 Ｖｅｒｔｉｃａ各自的处理优势，对数据处理任务进行划 分．比如Ｈａｄｏｏｐ负责非结构化数据的处理，Ｖｅｒｔｉｃａ 负责结构化数据的处理；Ｈａｄｏｏｐ负责耗时的批量 复杂处理，Ｖｅｒｔｉｃａ负责高性能的交互式查询等，从 而将两者结合起来．Ｖｅｒｔｉｃａ实际采用的是两套系统， 同时支持在ＭａｐＲｅｄｕｃｅ任务中直接访问Ｖｅｒｔｉｃａ数 据库中的数据．由于结构化数据仍在Ｖｅｒｔｉｃａ中处 理，在处理结构化大数据上的查询分析时，仍面临扩 展性问题；如果将查询推向Ｈａｄｏｏｐ进行，又将面临 性能问题．因此，Ｖｅｒｔｉｃａ的扩展性问题和Ｈａｄｏｏｐ 的性能问题在该系统中共存． ６４７１ 计　　算　　机　　学　　报 ２０１１年 与前两者相比，Ｔｅｒａｄａｔａ的集成相对简单． Ｔｅｒａｄａｔａ采用了存储层的整合：ＭａｐＲｅｄｕｃｅ任务可 以从Ｔｅｒａｄａｔａ数据库中读取数据，Ｔｅｒａｄａｔａ数据库 也可以从Ｈａｄｏｏｐ分布式文件系统上读取数据．同 样，Ｔｅｒａｄａｔａ和Ｈａｄｏｏｐ各自的根本性问题都未解决． ６　研究现状 对并行数据库来讲，其最大问题在于有限的扩 展能力和待改进的软件级容错能力；ＭａｐＲｅｄｕｃｅ的 最大问题在于性能，尤其是连接操作的性能；混合式 架构的关键是①，如何能尽可能多地把工作推向合 适的执行引擎（并行数据库或ＭａｐＲｅｄｕｃｅ）．本节对 近年来在这些问题上的研究做一分析和归纳． ６．１　并行数据库扩展性和容错性研究 华盛顿大学在文献［２３］中提出了可以生成具备 容错能力的并行执行计划优化器．该优化器可以依 靠输入的并行执行计划、各个操作符的容错策略及 查询失败的期望值等，输出一个具备容错能力的并 行执行计划．在该计划中，每个操作符都可以采取不 同的容错策略，在失败时仅重新执行其子操作符（在 某节点上运行的操作符）的任务来避免整个查询的 重新执行． ＭＩＴ于２０１０年设计的Ｏｓｐｒｅｙ系统［２４］基于维 表在各个节点全复制、事实表横向切分并冗余备份 的数据分布策略，将一星型查询划分为众多独立子 查询．每个子查询在执行失败时都可以在其备份节 点上重新执行，而不用重做整个查询，使得数据仓库 查询获得类似ＭａｐＲｅｄｕｃｅ的容错能力． 数据仓库扩展性方面的研究较少，中国人民大 学的ＬｉｎｅａｒＤＢ原型属于这方面的研究，详细参见 ７．１节． ６．２　犕犪狆犚犲犱狌犮犲性能优化研究 ＭａｐＲｅｄｕｃｅ的性能优化研究集中于对关系数 据库的先进技术和特性的移植上． Ｆａｃｅｂｏｏｋ和俄亥俄州立大学合作，将关系数据 库的混合式存储模型应用于Ｈａｄｏｏｐ平台，提出了 ＲＣＦｉｌｅ存储格式［２５］．与之不同，文献［２６］将列存储 技术引入Ｈａｄｏｏｐ平台．Ｈａｄｏｏｐ＋＋［２７］系统运用了 传统数据库的索引技术，并通过分区数据并置 （ＣｏＰａｒｔｉｔｉｏｎ）的方式来提升性能．文献［２８２９］基 于ＭａｐＲｅｄｕｃｅ实现了以流水线方式在各个操作符 间传递数据，从而缩短了任务执行时间；在线聚集 （ｏｎｌｉｎｅａｇｇｒｅｇａｔｉｏｎ）的操作模式使得用户可以在查 询执行过程中看到部分较早返回的结果．两者的不 同之处在于前者仍基于ｓｏｒｔｍｅｒｇｅ方式来实现流 水线，只是将排序等操作推向了ｒｅｄｕｃｅｒ，部分情况 下仍会出现流水线停顿的情况；而后者利用ｈａｓｈ方 式来分布数据，能实现更好的并行流水线操作．文 献［３０］提出了ＭＲＳｈａｒｅ架构，对批量查询进行转 换，将可共享扫描、共享Ｍａｐ输出结果等的一组任 务合并为一个，以提升性能．新加坡国立大学对影响 Ｈａｄｏｏｐ性能的因素做了深入分析［１２］，并提出了 ５项有效的优化技术，使得Ｈａｄｏｏｐ的性能提升了 近３倍，逼近关系数据库的性能． 近年的研究热点是基于ＭａｐＲｅｄｕｃｅ的连接操 作的性能优化．文献［３１］对ＭａｐＲｅｄｕｃｅ平台的两表 连接算法做了总结，提出了Ｍａｐ端连接、Ｒｅｄｕｃｅ端 连接及广播式连接等算法．文献［３２］对ＭａｐＲｅｄｕｃｅ 框架进行了扩展，在Ｒｅｄｕｃｅ步骤后添加了一Ｍｅｒｇｅ 步骤来完成连接操作，提出的ＭａｐＲｅｄｕｃｅＭｅｒｇｅ 框架可以同时处理两个异构数据源的数据．对于多 表连接，当前主流的研究集中于仅通过一个任务来 完成连接操作．文献［３３３４］提出了一对多复制的方 法，在Ｍａｐ阶段结束后，为保证连接操作的局部性， 元组会被复制到多个节点．但在节点数和数据量增 大的情况下，会带来Ｉ／Ｏ量及网络传输量的巨大增 长．Ｌｌａｍａ［３５］通过预排序和按连接属性划分数据的 方式来降低星型连接的代价，但要付出可观的预处 理代价和空间代价．不同于以上等值连接优化，文 献［３６］提出了针对任意连接条件的优化模型．以上 连接方式都是先执行连接，然后在连接后的数据上 执行聚集操作．而中国人民大学的Ｄｕｍｂｏ［３７］系统 却采用了另一种更适应于ＭａｐＲｅｄｕｃｅ平台的思路： 先执行过滤聚集操作，再基于聚集的数据执行连接． 详细参考７．２节． ６．３　犎犪犱狅狅狆犇犅的改进 ＨａｄｏｏｐＤＢ于２０１１年针对其架构提出了两种 连接优化技术和两种聚集优化技术［３８］． 两种连接优化的核心思想都是尽可能地将数据 的处理推入数据库层执行．第１种优化方式是根据 表与表之间的连接关系，通过数据预分解，使参与连 接的数据尽可能分布在同一数据库内（参照分解 法），从而实现将连接操作下压进数据库内执行．该 算法的缺点是应用场景有限，只适用于链式连接．第 ７４７１１０期 王　珊等：架构大数据：挑战、现状与展望 ①其最大问题既包括扩展性也包括性能，这两项分别取决于并行数据库和ＭａｐＲｅｄｕｃｅ（木桶原理），其改进取决于这两种系统问题的改进． ２种连接方式是针对广播式连接而设计的．在执行 连接前，先在数据库内为每张参与连接的维表建立 一张临时表，使得连接操作尽可能在数据库内执行． 该算法的缺点是较多的网络传输和磁盘Ｉ／Ｏ操作． 两种聚集优化技术分别是连接后聚集和连接前 聚集．前者是执行完Ｒｅｄｕｃｅ端连接后，直接对符合 条件的记录执行聚集操作；后者是将所有数据先在 数据库层执行聚集操作，然后基于聚集数据执行连 接操作，并将不符合条件的聚集数据做减法操作．该 方式适用的条件有限，主要用于参与连接和聚集的 列的基数相乘后小于表记录数的情况． 总的来看，ＨａｄｏｏｐＤＢ的优化技术大都局限性 较强，对于复杂的连接操作（如环形连接等）仍不能下 推至数据库层执行，并未从根本上解决其性能问题． ７　犕犪狆犚犲犱狌犮犲和关系数据库技术的融合 综上所述，当前研究大都集中于功能或特性的 移植，即从一个平台学习新的技术，到另一平台重新 实现和集成，未涉及执行核心，因此也没有从根本上 解决大数据分析问题．鉴于此，中国人民大学高性能 数据库实验室的研究小组采取了另一种思路：从数 据的组织和查询的执行两个核心层次入手，融合关 系数据库和ＭａｐＲｅｄｕｃｅ两种技术，设计高性能的可 扩展的抽象数据仓库查询处理框架．该框架在支持 高度可扩展的同时，又具有关系数据库的性能．我们 团队尝试过两个研究方向：（１）借鉴ＭａｐＲｅｄｕｃｅ的 思想，使ＯＬＡＰ查询的处理能像ＭａｐＲｅｄｕｃｅ一样 高度可扩展（ＬｉｎｅａｒＤＢ原型）；（２）利用关系数据库 的技术，使ＭａｐＲｅｄｕｃｅ在处理ＯＬＡＰ查询时，逼近 关系数据库的性能（Ｄｕｍｂｏ原型）． ７．１　犔犻狀犲犪狉犇犅 ＬｉｎｅａｒＤＢ①［３９］原型系统没有直接采用基于连接 的星型模型（雪花模型），而是对其进行了改造，设计 了扩展性更好的、基于扫描的无连接雪花模型ＪＦＳＳ （ＪｏｉｎＦｒｅｅＳｎｏｗｆｌａｋｅＳｃｈｅｍａ）．该模型的设计借鉴 了泛关系模型的思想，采用层次编码技术［４０］将维表 层次信息压缩进事实表，使得事实表可以独立执行 维表上的谓词判断、聚集等操作，从而使连接的数据 在大规模机群上实现局部性，消除了连接操作．图４ 是一个星型模型和无连接雪花模型的对应示意图． 在执行层次上，ＬｉｎｅａｒＤＢ吸取了ＭａｐＲｅｄｕｃｅ 处理模式的设计思想，将数据仓库查询的处理抽象 为Ｔｒａｎｓｆｏｒｍ、Ｒｅｄｕｃｅ、Ｍｅｒｇｅ３个操作（ＴＲＭ执行 模型）：（１）Ｔｒａｎｓｆｏｒｍ．主节点对查询进行预处理， 将查询中作用于维表的操作（主要是谓词判断， ｇｒｏｕｐｂｙ聚集操作等）转换为事实表上的操作； （２）Ｒｅｄｕｃｅ．每个数据节点并行地扫描、聚集本地数 据，然后将处理结果返回给主节点；（３）Ｍｅｒｇｅ．主节 点对各个数据节点返回的结果进行合并，并执行后 续的过滤、排序等操作．基于ＴＲＭ执行模型，查询 可以划分为众多独立的子任务在大规模机群上并行 执行．执行过程中，任何失败子任务都可以在其备 份节点重新执行，从而获得较好的容错能力． ＬｉｎｅａｒＤＢ的执行代价主要取决于对事实表的 Ｒｅｄｕｃｅ（主要是扫描）操作，因此，ＬｉｎｅａｒＤＢ可以获 得近乎线性的大规模可扩展能力．实验表明，其性能 比ＨａｄｏｏｐＤＢ至少高出一个数量级②． ＬｉｎｅａｒＤＢ的扩展能力、容错能力和高性能在于 其巧妙地结合了关系数据库技术（层次编码技术、泛 关系模式）和ＭａｐＲｅｄｕｃｅ处理模式的设计思想，由 此，可以看出，结合方式的不同可以导致系统能力的 巨大差异． ７２　犇狌犿犫狅 Ｄｕｍｂｏ［３７］的核心思想是根据ＭａｐＲｅｄｕｃｅ的 “过滤－＞聚集”的处理模式，对ＯＬＡＰ查询的处理 进行改造，使其适应于ＭａｐＲｅｄｕｃｅ框架． Ｄｕｍｂｏ采用了类似于ＬｉｎｅａｒＤＢ的数据组织模 式———利用层次编码技术将维表信息压缩进事实 表，区别在于Ｄｕｍｂｏ采用了更加有效的编码方式， 并针对Ｈａｄｏｏｐ分布式文件系统的特点对数据的存 储进行了优化． 在执行层次上，Ｄｕｍｂｏ对ＭａｐＲｅｄｕｃｅ框架进 行了扩展，设计了新的ＯＬＡＰ查询处理框架——— ＴＭＲＰ（Ｔｒａｎｓｆｏｒｍ－＞Ｍａｐ－＞Ｒｅｄｕｃｅ－＞Ｐｏｓｔｐｒｏ ｃｅｓｓ）处理框架（如图５所示）．在该框架中，主节点 首先对查询进行转换，生成一个ＭａｐＲｅｄｕｃｅ任务来 执行查询．该任务在Ｍａｐ阶段以流水线方式扫描、 聚集本地数据，并只将本地的聚集数据传至Ｒｅ ｄｕｃｅ阶段，来进行数据的合并及聚集、排序等操作． 在Ｐｏｓｔｐｒｏｃｅｓｓ阶段，主节点在数据节点上传的聚集 数据之上执行连接操作．实验表明，Ｄｕｍｂｏ性能远 超Ｈａｄｏｏｐ和ＨａｄｏｏｐＤＢ． 由此我们可以看出，复杂的ＯＬＡＰ查询在 ８４７１ 计　　算　　机　　学　　报 ２０１１年 ①② 又名为ＬａＳｃＯＬＡＰ．此数据是基于我们自己实现的〈ｋｅｙ，ｖａｌｕｅ〉列存模型之上测试得出的结果，与文献［３９］中所列性能有所不同． 图４　对比：一个典型星型模型与其对应的无连接雪花模型 ＭａｐＲｅｄｕｃｅ框架下也可以获得接近甚至超越关系 数据库的性能，其关键在于如何有效地结合关系数 据库和ＭａｐＲｅｄｕｃｅ两种技术．仅仅停留于表层的移 植和集成是难以从根本上解决大数据分析问题的． 我们在文献［４１］的研究中也展示了如何基于这种新 的数据组织方式来实现复杂分析操作———百分位数 的高效计算问题． ＬｉｎｅａｒＤＢ和Ｄｕｍｂｏ虽然基本可以达到预期 的设计目标，但两者都需要对数据进行预处理，其 预处理代价是普通加载时间的７倍左右．因此其 应对变化的能力还较弱，这是我们未来的工作内 容之一． ８　研究展望 当前３个方向的研究都不能完美地解决大数据 分析问题，也就意味着每个方向都有极具挑战性的 工作等待着我们． 对并行数据库来说，其扩展性近年虽有较大改 善（如Ｇｒｅｅｎｐｌｕｍ和ＡｓｔｅｒＤａｔａ都是面向ＰＢ级数 据规模设计开发的），但距离大数据的分析需求仍 有较大差距．因此，如何改善并行数据库的扩展能 力是一项非常有挑战的工作，该项研究将同时涉 及数据一致性协议、容错性、性能等数据库领域的 ９４７１１０期 王　珊等：架构大数据：挑战、现状与展望 图５　Ｄｕｍｂｏ架构（深灰色部分是新增模块， 剩余部分是Ｈａｄｏｏｐ自带模块） 诸多方面． 混合式架构方案可以复用已有成果，开发量较 小．但只是简单的功能集成似乎并不能有效解决大 数据的分析问题，因此该方向还需要更加深入的研 究工作，比如从数据模型及查询处理模式上进行研 究，使两者能较自然地结合起来，这将是一项非常有 意义的工作．中国人民大学的Ｄｕｍｂｏ［３７］系统即是 在深层结合方向上努力的一个例子． 相比于前两者，ＭａｐＲｅｄｕｃｅ的性能优化进展迅 速，其性能正逐步逼近关系数据库．该方向的研究又 分为两个方向：理论界侧重于利用关系数据库技术 及理论改善ＭａｐＲｅｄｕｃｅ的性能；工业界侧重于基于 ＭａｐＲｅｄｕｃｅ平台开发高效的应用软件．针对数据仓 库领域，我们认为如下几个研究方向比较重要，且目 前研究还较少涉及： （１）多维数据的预计算．ＭａｐＲｅｄｕｃｅ更多针对 的是一次性分析操作．大数据上的分析操作虽然难 以预测，但传统的分析，如基于报表和多维数据的分 析仍占多数．因此，ＭａｐＲｅｄｕｃｅ平台也可以利用预 计算等手段加快数据分析的速度．基于存储空间的 考虑（可以想象，在爆炸数据之上计算数据立方体需 要付出昂贵的存储空间代价），ＭＯＬＡＰ是不可取 的，混合式ＯＬＡＰ（ＨＯＬＡＰ）应该是ＭａｐＲｅｄｕｃｅ平 台的优选ＯＬＡＰ实现方案．具体研究如：①基于 ＭａｐＲｅｄｕｃｅ框架的高效Ｃｕｂｅ计算算法；②物化视 图的选择问题，即物化哪些数据；③不同分析操作 的物化手段（比如预测分析操作的物化）及如何基于 物化的数据进行复杂分析操作（如数据访问路径的 选择问题）． （２）各种分析操作的并行化实现．大数据分析 需要高效的复杂统计分析功能的支持．ＩＢＭ将开源 统计分析软件Ｒ集成进Ｈａｄｏｏｐ平台［４２］，增强了 Ｈａｄｏｏｐ的统计分析功能．但更具挑战性的问题是， 如何基于ＭａｐＲｅｄｕｃｅ框架设计可并行化的、高效的 分析算法．尤其需要强调的是，鉴于移动数据的巨大 代价，这些算法应基于移动计算的方式来实现． （３）查询共享．ＭａｐＲｅｄｕｃｅ采用步步物化的处 理方式，导致其Ｉ／Ｏ代价及网络传输代价较高．一 种有效的降低该代价的方式是在多个查询间共享物 化的中间结果，甚至原始数据，以分摊代价并避免重 复计算．因此如何在多查询间共享中间结果将是一 项非常有实际应用价值的研究． （４）用户接口．如何较好地实现数据分析的展 示和操作，尤其是复杂分析操作的直观展示． （５）Ｈａｄｏｏｐ可靠性研究．当前Ｈａｄｏｏｐ采用主 从结构，由此决定了主节点一旦失效，将会出现整个 系统失效的局面．因此，如何在不影响Ｈａｄｏｏｐ现有 实现的前提下，提高主节点的可靠性，将是一项切实 的研究． （６）数据压缩．ＭａｐＲｅｄｕｃｅ的执行模型决定了 其性能取决于Ｉ／Ｏ和网络传输代价．文献［１１］在比 较并行数据库和ＭａｐＲｅｄｕｃｅ基于压缩数据的性能 时，发现压缩技术并没有改善Ｈａｄｏｏｐ的性能①．但 实际情况是，压缩不仅可以节省空间，节省Ｉ／Ｏ及 网络带宽，还可以利用当前ＣＰＵ的多核并行计算 能力，平衡Ｉ／Ｏ和ＣＰＵ的处理能力，从而提高性 能．比如并行数据库利用数据压缩后，性能往往可以 大幅提升．此后，文献［２５２６］的研究成功地利用压 缩技术提升了Ｈａｄｏｏｐ的性能．但这些研究都基于 各自的存储模型，而非Ｈａｄｏｏｐ的默认存储模式（行 存模型）．因此，ＭａｐＲｅｄｕｃｅ上的压缩是一个尚待研 究的重要问题． （７）多维索引研究．如何基于ＭａｐＲｅｄｕｃｅ框架 实现多维索引，加快多维数据的检索速度． ０５７１ 计　　算　　机　　学　　报 ２０１１年 ①原因未知． 当然，仍有许多其它研究工作，比如基于 Ｈａｄｏｏｐ的实时数据分析、弹性研究、数据一致性研 究等，都是非常有挑战和意义的研究，限于篇幅我们 不再赘述． ９　总　结 本文对大数据分析的主流实现平台（并行数据 库、ＭａｐＲｅｄｕｃｅ及两者的混合架构）进行了评价、归 纳与对比分析，介绍了中国人民大学在大数据分析 方面的研究，并对当前的研究进行了归纳．从文中可 以看出，每种分析平台都不是完美的，在大数据面 前，都有很长的路要走．大数据分析迫使我们传 统的数据仓库架构，虚心地研究ＭａｐＲｅｄｕｃｅ等新生 平台，以站在更高的层次来思考问题，从而找到适应 时代需求的数据仓库架构． 参考文献 ［１］ＷｉｎｔｅｒＣｏｒｐ：２００５ＴｏｐＴｅｎＰｒｏｇｒａｍＳｕｍｍａｒｙ．ｈｔｔｐ：／／ ｗｗｗ．ｗｉｎｔｅｒｃｏｒｐ．ｃｏｍ／ＷｈｉｔｅＰａｐｅｒｓ／ＷＣ＿ＴｏｐＴｅｎＷＰ．ｐｄｆ ［２］ＴＤＷＩＣｈｅｃｋｌｉｓｔＲｅｐｏｒｔ：ＢｉｇＤａｔａＡｎａｌｙｔｉｃｓ．ｈｔｔｐ：／／ｔｄｗｉ． ｏｒｇ／ｒｅｓｅａｒｃｈ／２０１０／０８／ＢｉｇＤａｔａＡｎａｌｙｔｉｃｓ．ａｓｐｘ ［３］ＣｈａｕｄｈｕｒｉＳ，ＤａｙａｌＵ．Ａｎｏｖｅｒｖｉｅｗｏｆｄａｔａｗａｒｅｈｏｕｓｉｎｇａｎｄ ＯＬＡＰｔｅｃｈｎｏｌｏｇｙ．ＳＩＧＭＯＤＲｅｃ，１９９７，２６（１）：６５７４ ［４］ＭａｄｄｅｎＳ，ＤｅＷｉｔｔＤＪ，ＳｔｏｎｅｂｒａｋｅｒＭ．Ｄａｔａｂａｓｅｐａｒａｌｌｅｌ ｉｓｍｃｈｏｉｃｅｓｇｒｅａｔｌｙｉｍｐａｃｔｓｃａｌａｂｉｌｉｔｙ．ＤａｔａｂａｓｅＣｏｌｕｍｎＢｌｏｇ． ｈｔｔｐ：／／ｗｗｗ．ｄａｔａｂａｓｅｃｏｌｕｍｎ．ｃｏｍ／２００７／１０／ｄａｔａｂａｓｅｐａｒａｌ ｌｅｌｉｓｍｃｈｏｉｃｅｓ．ｈｔｍｌ ［５］ＤｅａｎＪ，ＧｈｅｍａｗａｔＳ．ＭａｐＲｅｄｕｃｅ：Ｓｉｍｐｌｉｆｉｅｄｄａｔａｐｒｏｃｅｓｓ ｉｎｇｏｎｌａｒｇｅｃｌｕｓｔｅｒｓ／／Ｐｒｏｃｅｅｄｉｎｇｓｏｆｔｈｅ６ｔｈＳｙｍｐｏｓｉｕｍｏｎ ＯｐｅｒａｔｉｎｇＳｙｓｔｅｍＤｅｓｉｇｎａｎｄＩｍｐｌｅｍｅｎｔａｔｉｏｎ（ＯＳＤＩ’０４）． ＳａｎＦｒａｎｃｉｓｃｏ，Ｃａｌｉｆｏｒｎｉａ，ＵＳＡ，２００４：１３７１５０ ［６］ＤｅＷｉｔｔＤＪ，ＧｅｒｂｅｒＲＨ，ＧｒａｅｆｅＧ，ＨｅｙｔｅｎｓＭＬ，Ｋｕｍａｒ ＫＢ，ＭｕｒａｌｉｋｒｉｓｈｎａＭ．ＧＡＭＭＡ—Ａｈｉｇｈｐｅｒｆｏｒｍａｎｃｅｄａｔ ａｆｌｏｗｄａｔａｂａｓｅｍａｃｈｉｎｅ／／Ｐｒｏｃｅｅｄｉｎｇｓｏｆｔｈｅ１２ｔｈＩｎｔｅｒｎａ ｔｉｏｎａｌＣｏｎｆｅｒｅｎｃｅｏｎＶｅｒｙＬａｒｇｅＤａｔａＢａｓｅｓ（ＶＬＤＢ’８６）． Ｋｙｏｔｏ，Ｊａｐａｎ，１９８６：２２８２３７ ［７］ＦｕｓｈｉｍｉＳ，ＫｉｔｓｕｒｅｇａｗａＭ，ＴａｎａｋａＨ．Ａｎｏｖｅｒｖｉｅｗｏｆｔｈｅ ｓｙｓｔｅｍｓｏｆｔｗａｒｅｏｆａｐａｒａｌｌｅｌｒｅｌａｔｉｏｎａｌｄａｔａｂａｓｅｍａｃｈｉｎｅ／／ Ｐｒｏｃｅｅｄｉｎｇｓｏｆｔｈｅ１２ｔｈＩｎｔｅｒｎａｔｉｏｎａｌＣｏｎｆｅｒｅｎｃｅｏｎＶｅｒｙ ＬａｒｇｅＤａｔａＢａｓｅｓ（ＶＬＤＢ’８６）．Ｋｙｏｔｏ，Ｊａｐａｎ，１９８６：２０９２１９ ［８］ＢｒｅｗｅｒＥＡ．Ｔｏｗａｒｄｓｒｏｂｕｓｔｄｉｓｔｒｉｂｕｔｅｄｓｙｓｔｅｍｓ／／Ｐｒｏｃｅｅｄ ｉｎｇｓｏｆｔｈｅ１９ｔｈＡｎｎｕａｌＡＣＭＳｙｍｐｏｓｉｕｍｏｎＰｒｉｎｃｉｐｌｅｓｏｆ ＤｉｓｔｒｉｂｕｔｅｄＣｏｍｐｕｔｉｎｇ（ＰＯＤＣ’００）．Ｐｏｒｔｌａｎｄ，Ｏｒｅｇｏｎ， ＵＳＡ，２０００：７ ［９］ｈｔｔｐ：／／ｗｗｗ．ｄｂｍｓ２．ｃｏｍ／２００８／０８／２６／ｋｎｏｗｎａｐｐｌｉｃａｔｉｏｎｓ ｏｆｍａｐｒｅｄｕｃｅ／ ［１０］ｈｔｔｐ：／／ｈａｄｏｏｐ．ａｐａｃｈｅ．ｏｒｇ ［１１］ＰａｖｌｏＡ，ＰａｕｌｓｏｎＥ，ＲａｓｉｎＡ，ＡｂａｄｉＤＪ，ＤｅＷｉｔｔＤＪ，Ｍａｄ ｄｅｎＳ，ＳｔｏｎｅｂｒａｋｅｒＭ．Ａｃｏｍｐａｒｉｓｏｎｏｆａｐｐｒｏａｃｈｅｓｔｏｌａｒｇｅ ｓｃａｌｅｄａｔａａｎａｌｙｓｉｓ／／ＰｒｏｃｅｅｄｉｎｇｓｏｆｔｈｅＡＣＭＳＩＧＭＯＤＩｎｔｅｒ ｎａｔｉｏｎａｌＣｏｎｆｅｒｅｎｃｅｏｎＭａｎａｇｅｍｅｎｔｏｆＤａｔａ（ＳＩＧＭＯＤ’０９）． Ｐｒｏｖｉｄｅｎｃｅ，ＲｈｏｄｅＩｓｌａｎｄ，ＵＳＡ，２００９：１６５１７８ ［１２］ＪｉａｎｇＤ，ＯｏｉＢＣ，ＳｈｉＬ，ＷｕＳ．ＴｈｅｐｅｒｆｏｒｍａｎｃｅｏｆＭａｐＲｅ ｄｕｃｅ：Ａｎｉｎｄｅｐｔｈｓｔｕｄｙ．ＰＶＬＤＢ，２０１０，３（１）：４７２４８３ ［１３］ＳｔｏｎｅｂｒａｋｅｒＭ，ＡｂａｄｉＤＪ，ＤｅＷｉｔｔＤＪ，ＭａｄｄｅｎＳ，Ｐａｕｌｓｏｎ Ｅ，ＰａｖｌｏＡ，ＲａｓｉｎＡ．ＭａｐＲｅｄｕｃｅａｎｄｐａｒａｌｌｅｌＤＢＭＳｓ： Ｆｒｉｅｎｄｓｏｒｆｏｅｓ？ＣｏｍｍｕｎｉｃａｔｉｏｎｓｏｆｔｈｅＡＣＭ，２０１０，５３（１）： ６４７１ ［１４］ＤｅａｎＪ，ＧｈｅｍａｗａｔＳ．ＭａｐＲｅｄｕｃｅ：Ａｆｌｅｘｉｂ