《电子商务 E-business》参考资料（大数据）：架构大数据_挑战_现状与展望

第34卷第10期 计算机学报 Vol 34 No. 10 201l年10月 CHINESE JOURNAL OF COM PUTERS Oct. 201 1 架构大数据:挑战、现状与展望 王珊”王会举”覃雄派周烜 数据工程与知识工程教育部重点实验室中国人民大学)北京100872 2(中国人民大学信息学院北京100872) 摘要大数据分析相比于传统的数据仓库应用,具有数据量大、查询分析复杂等特点为了设计适合大数据分析 的数据仓库架构,文中列举了大数据分析平台需要具备的几个重要特性,对当前的主流实现平台一—并行数据库、 M apR educe及基于两者的混合架构进行了分析归纳指出了各自的优势及不足,同时也对各个方向的研究现状及 作者在大数据分析方面的努力进行了介绍,对未来研究做了展望 关键词大数据;大规模可扩展; M maPreduce;并行数据库;深度分析 中图法分类号TP311DOI号:10.3724SP.J.1016.2011.01741 Architecting Big Data: Challenges, Studies and Forecasts WANG Shan"2 WANG HuiJu.2 QIN Xiong-Pai" ZHOU Xuan".2 u(Key Labor atory of Data Eng ineering and Know led ge Eng ineering( Renmin Unirersity f Ch ina)of Ministry of Educat ion, Bey ing 100872) '(Schod of Information, Renmin University of China. Beijing 100872) Abstract Compared w ith traditio nal dat a w arehouse applications, big data analy ties are huge and omplex. To design a favorable architecture for big dat a analy tics, this paper lists some key fear tures for big data analytics, summarizes current main implementation platforms( parallel databas es, M apReduce, and hybrid architectures based on them), and points their pros and cons. Some current resear ches are also inv stig ated, our work are introduced and some challeng ing research pro blems in the future are dis cussed Keywords big dat a; large scale; M apReduce: parallel database: deep analytics 系统实现方案(主要是并行数据库和 M ap Reduce) 1引言 进行重新审视,期望能为设计满足时代需求的数据 仓库系统提供理论参考.限于篇幅,本文主要关注不 最近几年,数据仓库又成为数据管理研究的热同数据仓库实现方案的主体架构及其缺陷在最近几 点领域主要原因是当前数据仓库系统面临的需求年的改进情况.依据研究立足点的不同,本文将该领 在数据源、需提供的数据服务和所处的硬件环境等域的研究归为三大类:并行数据库、 M apReduce、并 方面发生了根本性的变化(详见L1节),这些变化行数据库和 M maPreduce技术的混合架构其中第三 是我们必须面对的 类研究又细分为:并行数据库主导型、 MapReduce 本文在大数据的时代背景下,对现有数据仓库主导型、并行数据库和 Map Reduce集成型三种.本 收稿日期:201}012;最终修改稿收到日期:201-015.本课题得到国家重大科技专项核高基项目(2010ZX0104200-002)、国家自然 科学基金(61070054,61170013)、中国人民大学科学研究基金(中央高校基本科研业务费专项资金,10XN18)、中国人民大学研究生基 金(1XNH120资助王珊,女,1944年生,教授博士生导师中国计算机学会(CCF)高级会员,主要研究领域为高性能数据库、知识工 程、数据仓库.r- mail sw ang@ ruc. edu,m.王会举,男,1979年生,博士研究生,主要研究方向为大規模集群数据库、内存数据库. E mail: w anhui ju@rue.edu.m.覃雄派,男,1971年生,博士,讲师,中国计算机学会(CCF)会员,主要研究方向为数据库查询优化、内存数据库 c何敞据库周,男,1979年生,博种教探主翠研亮方为信检案,商性能数帮库chtsreserved.htp/www.cnki.net

第 34 卷 第 10 期 2011 年 10 月 计 算 机 学 报 CHINESE JOURNA L OF COM PU TERS Vol. 34 No. 10 Oct. 2011 收稿日期: 2011-08-12; 最终修改稿收到日期: 2011-09-15. 本课题得到国家重大科技专项核高基项目( 2010ZX01042-001-002 ) 、国家自然 科学基金( 61070054, 61170013) 、中国人民大学科学研究基金( 中央高校基本科研业务费专项资金, 10XNI018 )、中国人民大学研究生基 金( 11XNH120) 资助. 王 珊, 女, 1944 年生, 教授, 博士生导师,中国计算机学会( CCF) 高级会员, 主要研究领域为高性能数据库、知识工 程、数据仓库. E-mail: sw ang@ ru c. edu . cn. 王会举, 男, 1979 年生, 博士研究生, 主要研究方向为大规模集群数据库、内存数据库. E- mail: w anghuiju@ ruc. edu. cn. 覃雄派, 男, 1971 年生, 博士, 讲师, 中国计算机学会( CCF) 会员, 主要研究方向为数据库查询优化、内存数据库、 并行数据库. 周 烜, 男, 1979 年生, 博士, 副教授,主要研究方向为信息检索、高性能数据库. 架构大数据: 挑战、现状与展望 王 珊 1) , 2) 王会举 1) , 2) 覃雄派 1) , 2) 周 烜 1) , 2) 1) ( 数据工程与知识工程教育部重点实验室( 中国人民大学) 北京 100872) 2) ( 中国人民大学信息学院 北京 100872) 摘 要 大数据分析相比于传统的数据仓库应用, 具有数据量大、查询分析复杂等特点. 为了设计适合大数据分析 的数据仓库架构, 文中列举了大数据分析平台需要具备的几个重要特性, 对当前的主流实现平台) )) 并行数据库、 MapReduce 及基于两者的混合架构进行了分析归纳, 指出了各自的优势及不足, 同时也对各个方向的研究现状及 作者在大数据分析方面的努力进行了介绍, 对未来研究做了展望. 关键词 大数据; 大规模可扩展; MapReduce; 并行数据库; 深度分析 中图法分类号 TP311 DOI 号: 10. 3724/ SP. J. 1016. 2011. 01741 Architecting Big Data: Challenges, Studies and Forecasts WANG Shan 1) , 2) WANG Hu-i Ju 1) , 2) QIN Xiong-Pai 1) , 2) ZHOU Xuan 1) , 2) 1) ( K ey L abor ator y of Data Eng ineering and K now led ge Eng ineering ( Renmin University of Ch ina) of Ministry of E ducation, B eij ing 100872) 2) ( S chool of I nf ormation , R enmin University of Ch ina , B eij ing 100872) Abstract Compar ed w ith traditio nal data w arehouse applications, big data analy tics are huge and complex . T o design a favo rable architecture for big data analy tics, this paper lists some key fea￾tures fo r big data analytics, summarizes current main implementation platfor ms( parallel databas￾es, M apReduce, and hybrid architectures based o n them) , and points their pros and cons. Some current resear ches are also inv estig ated, our w ork ar e introduced and some challeng ing resear ch pro blems in the future are discussed. Keywords big data; large scale; M apReduce; parallel database; deep analytics 1 引 言 最近几年, 数据仓库又成为数据管理研究的热 点领域, 主要原因是当前数据仓库系统面临的需求 在数据源、需提供的数据服务和所处的硬件环境等 方面发生了根本性的变化( 详见 11 1 节) , 这些变化 是我们必须面对的. 本文在大数据的时代背景下, 对现有数据仓库 系统实现方案( 主要是并行数据库和 M apReduce) 进行重新审视, 期望能为设计满足时代需求的数据 仓库系统提供理论参考. 限于篇幅, 本文主要关注不 同数据仓库实现方案的主体架构及其缺陷在最近几 年的改进情况. 依据研究立足点的不同, 本文将该领 域的研究归为三大类: 并行数据库、M apReduce、并 行数据库和 M apReduce 技术的混合架构. 其中第三 类研究又细分为: 并行数据库主导型、MapReduce 主导型、并行数据库和 MapReduce 集成型三种. 本

l742 计算机学报 011年 文第1节分析大数据时代,数据仓库所面临的问题个层次,数据源中的数据首先通过ETL工具被抽取 及挑战;第2节列岀大数据时代的数据仓库平台需到数据仓库中进行集中存储和管理,再按照星型模 具备的几个重要特性;第3节到第5节就这几个特型或雪花模型组织数据,然后OLAP工具从数据仓 性对各类平台进行归纳分析;第6节对最新研究做库中读取数据,生成数据立方体( MOLAP)或者直 跟踪归纳;第7节介绍中国人民大学在大数据分接访问数据仓库进行数据分析( ROLA P).在大数据 析方面的研究工作;第8节对未来研究做出展望;第时代,此种计算模式存在两个问题 9节总结全文 问题1.数据移动代价过高.在数据源层和分 1.1三个变化 析层之间引入一个存储管理层,可以提升数据质量 (1)数据量.由TB级升至PB级,并仍在持续并针对查询进行优化,但也付出了较大的数据迁移 爆炸式增长.根据 Winter Corp的调查显示,最大的代价和执行时的连接代价:数据首先通过复杂且耗 数据仓库中的数据量,每两年增加3倍(年均增长时的ETL过程存储到数据仓库中,在OLAP服务 率为173‰%),其增长速度远超摩尔定律增长速度.器中转化为星型模型或者雪花模型;执行分析时,又 照此增长速度计算,2015年最大数据仓库中的数据通过连接方式将数据从数据库中取出.这些代价在 量将逼近100PB TB级时也许可以接受,但面对大数据,其执行时间 a(2)分析需求.由常规分析转向深度分析(Deep至少会增长几个数量级更为重要的是对于大量的 aly tics).数据分析日益成为企业利润必不可少的即席分析,这种数据移动的计算模式是不可取的 支撑点根据TDW1对大数据分析的报告(如图1 数据仓库 期望能对未来趋势有更多的分析和预测,以增强企 企业已经不满足于对现有数据的分析和监测,而是更 数据查询 业竞争力这些分析操作包括诸如移动平均线分析、白E 报表查询 数据关联关系分析、回归分析、市场篮分析等复杂统 OLAP分析 计分析,我们称之为深度分析.值得补充的是,本文 中的大数据分析不仅仅指基于大数据上的深度分 析,也包括常规分析 数据集市 数据源数据存储与管理OLAP服务!前端展现 图2一个典型的数据仓库架构 问题2.不能快速适应变化.传统的数据仓库 假设主题是较少变化的,其应对变化的方式是对数 据源到前端展现的整个流程中的每个部分进行修 改,然后再重新加载数据,甚至重新计算数据,导致 其适应变化的周期较长.这种模式比较适合对数据 质量和查询性能要求较高、而不太计较预处理代价 的场合.但在大数据时代,分析处在变化的业务环境 图1分析的趋势 中,这种模式将难以适应新的需求 (3)硬件平台.由高端服务器转向由中低端硬1.3一个鸿沟 件构成的大规模机群平台.由于数据量的迅速增加 在大数据时代巨量数据与系统的数据处理能 并行数据库的规模不得不随之增大,从而导致其成力之间将会产生一个鸿沟:一边是至少PB级的数 本的急剧上升.出于成本的考虑越来越多的企业将据量,另一边是面向传统数据分析能力设计的数据 应用由高端服务器转向了由中低端硬件构成的大规仓库和各种BI工具如果这些系统或工具发展缓 模机群平台. 慢,该鸿沟将会随着数据量的持续爆炸式增长而逐 12两个问题 步拉大 图2是一个典型的数据仓库架构.从图中我 虽然,传统数据仓库可以采用舍弃不重要数据 们可以看出,传统的数据食库将整个实现划分为A者建立数据集市的式来级解此问题,但毕竟尽

文第 1 节分析大数据时代, 数据仓库所面临的问题 及挑战; 第 2 节列出大数据时代的数据仓库平台需 具备的几个重要特性; 第 3 节到第 5 节就这几个特 性对各类平台进行归纳分析; 第 6 节对最新研究做 一跟踪归纳; 第 7 节介绍中国人民大学在大数据分 析方面的研究工作; 第 8 节对未来研究做出展望; 第 9 节总结全文. 1. 1 三个变化 ( 1) 数据量. 由 T B 级升至 PB 级, 并仍在持续 爆炸式增长. 根据 WinterCor p 的调查显示, 最大的 数据仓库中的数据量, 每两年增加 3 倍[ 1] ( 年均增长 率为 173%) , 其增长速度远超摩尔定律增长速度. 照此增长速度计算, 2015 年最大数据仓库中的数据 量将逼近 100PB. ( 2) 分析需求. 由常规分析转向深度分析( Deep Analy tics) . 数据分析日益成为企业利润必不可少的 支撑点. 根据 T DWI 对大数据分析的报告 [2] ( 如图 1), 企业已经不满足于对现有数据的分析和监测, 而是更 期望能对未来趋势有更多的分析和预测, 以增强企 业竞争力. 这些分析操作包括诸如移动平均线分析、 数据关联关系分析、回归分析、市场篮分析等复杂统 计分析, 我们称之为深度分析. 值得补充的是, 本文 中的大数据分析不仅仅指基于大数据上的深度分 析, 也包括常规分析. 图 1 分析的趋势 ( 3) 硬件平台. 由高端服务器转向由中低端硬 件构成的大规模机群平台. 由于数据量的迅速增加, 并行数据库的规模不得不随之增大, 从而导致其成 本的急剧上升. 出于成本的考虑, 越来越多的企业将 应用由高端服务器转向了由中低端硬件构成的大规 模机群平台. 11 2 两个问题 图 2 是一个典型的数据仓库架构[ 3] . 从图中我 们可以看出, 传统的数据仓库将整个实现划分为 4 个层次, 数据源中的数据首先通过 ETL 工具被抽取 到数据仓库中进行集中存储和管理, 再按照星型模 型或雪花模型组织数据, 然后 OLAP 工具从数据仓 库中读取数据, 生成数据立方体( M OLAP) 或者直 接访问数据仓库进行数据分析( ROLA P) . 在大数据 时代, 此种计算模式存在两个问题: 问题 1. 数据移动代价过高. 在数据源层和分 析层之间引入一个存储管理层, 可以提升数据质量 并针对查询进行优化, 但也付出了较大的数据迁移 代价和执行时的连接代价: 数据首先通过复杂且耗 时的 ETL 过程存储到数据仓库中, 在 OLA P 服务 器中转化为星型模型或者雪花模型; 执行分析时, 又 通过连接方式将数据从数据库中取出. 这些代价在 T B 级时也许可以接受, 但面对大数据, 其执行时间 至少会增长几个数量级. 更为重要的是, 对于大量的 即席分析, 这种数据移动的计算模式是不可取的. 图 2 一个典型的数据仓库架构 问题 2. 不能快速适应变化. 传统的数据仓库 假设主题是较少变化的, 其应对变化的方式是对数 据源到前端展现的整个流程中的每个部分进行修 改, 然后再重新加载数据, 甚至重新计算数据, 导致 其适应变化的周期较长. 这种模式比较适合对数据 质量和查询性能要求较高、而不太计较预处理代价 的场合. 但在大数据时代, 分析处在变化的业务环境 中, 这种模式将难以适应新的需求. 1. 3 一个鸿沟 在大数据时代, 巨量数据与系统的数据处理能 力之间将会产生一个鸿沟: 一边是至少 PB 级的数 据量, 另一边是面向传统数据分析能力设计的数据 仓库和各种 BI 工具. 如果这些系统或工具发展缓 慢, 该鸿沟将会随着数据量的持续爆炸式增长而逐 步拉大. 虽然, 传统数据仓库可以采用舍弃不重要数据 或者建立数据集市的方式来缓解此问题, 但毕竟只 1742 计 算 机 学 报 2011 年

10期 王珊等:架构大数据:挑战、现状与展望 1743 是权益之策,并非系统级解决方案而且,舍弃的数大量同构的计算机是不可取的,而且也会在未来添 据在未来可能会重新使用,以发掘更大的价值 置异构计算资源.此外,不少企业已经积累了一些闲 置的计算机资源,此种情况下,对异构环境的支持可 2期望特性 以有效地利用这些闲置计算资源,降低硬件成本的 投入.还需特别关注的是,在异构环境下,不同节点 本节我们列出对大数据进行分析时,数据仓库的性能是不一样的,可能出现木桶效应”,即最慢节 系统需具备的几个重要特性(表1所示) 点的性能决定整体处理性能.因此,异构的机群需要 特别关注负载均衡、任务调度等方面的设计 表1大数据分析平台需具备的特性 较低的分析延迟.分析延迟指的是分析前的数 简要说明 高度可扩展性横向大规模可扩展,大规模并行处理 据准备时间.在大数据时代,分析所处的业务环境是 高性能 快速响应复杂查询与分析 变化的,因此也要求系统能动态地适应业务分析需 高度容错性 查询失败时,只需重做部分工作 持异构环境对硬件平台一致性要求不高,适应能力强 求.在分析需求发生变化时,减少数据准备时间,系 较低的分析延迟业务需求变化时,能快速反应 统能尽可能快地做出反应,快速地进行数据分析 易用且开放接口既能方便查询,又能处理复杂分析 较低成本 较高的性价比 易用且开放的接口.SQL的优点是简单易用, 向下兼容性 支持传统的商务智能工具 但其主要用于数据的检索查询,对于大数据上的深 度分析来讲,是不够的.原因在于:(1)其提供的服 高度可扩展性。一个明显的事实是,数据库不务方式依赖于数据移动来实现将数据从数据库中 能依靠一台或少数几台机器的升级( scale-up纵向取出然后传递给应用程序,该实现方式在大数据时 扩展)满足数据量的爆炸式增长,而是希望能方便地代代价过高;(2)复杂的分析功能,如R或 M atlab 做到横向可扩展(scal-out)来实现此目标 中的分析功能SQL是难以胜任的.因此,除对SQL 普遍认为shac+ no thing无共享结构(每个节的支持外,系统还应能提供开放的接口,让用户自己 点拥有私有内存和磁盘,并且通过高速网络同其它开发需要的功能设计该接口时,除了关注其易用性 节点互连)具备较好的扩展性4.分析型操作往往涉和开放性还需要特别注意两点隐藏的要求:(1基 及大规模的并行扫描、多维聚集及星型连接操作,这于接口开发的用户自定义函数能自动在机群上并 些操作也比较适合在无共享结构的网络环境运行.行执行:(2)分析在数据库内进行,即分析尽可能靠 Terada a即采用此结构 Oracle在其新产品 Exadata近数据 中也采用了此结构 较低的成本.在满足需求的前提下,某技术成 高性能.数据量的増长并没有降低对数据库性本越低,其生命力就越强需要指出的是成本是一个 能的要求,反而有所提高.软件系统性能的提升可以综合指标不仅仅是硬件或软件的代价,还应包括日 降低企业对硬件的投入成本、节省计算资源提高系常运维成本(网络费用、电费建筑等)和管理人员成 统吞吐量.巨量数据的效率优化并行是必由之路.本等据报告,数据中心的主要成本不是硬件的购置 IPB数据在50MB/s速度下串行扫描一次,需要成本而是日常运维成本因此在设计系统时需要 230天;而在6000块磁盘上,并行扫描IPB数据只更多地关注此项内容 需要1个小时 向下兼容性.数据仓库发展的30年,产生了大 高度容错.大数据的容错性要求在查询执行过量面向客户业务的数据处理工具(如 Informatica 程中,一个参与节点失效时,不需要重做整个查询. Dat astage等)、分析软件(如SPSR、Malh等)和 而机群节点数的增加会带来节点失效概率的增加.前端展现工具(如水晶报表)等这些软件是一笔宝 在大规模机群环境下,节点的失效将不再是稀有事贵的财富,已被分析人员所熟悉,是大数据时代中小 件( Google报告,平均每个 M maPreduce数据处理任规模数据分析的必要补充因此,新的数据仓库需考 务就有L2个工作节点失效).因此在大规模机群虑同传统商务智能工具的兼容性由于这些系统往 环境下,系统不能依赖于硬件来保证容错性,要更多往提供标准驱动程序,如ODBC、JDBC等,这项需 地考虑软件级容错. 求的实际要求是对SQL的支持 支持异构环境.建设同构系统的大规模机群难 总之,以较低的成本投入、高效地进行数据分 度较木原因在于计算机硬件更新轻,次性胞罩b析,是太数据分析的基本目标hp/ vww. cnkinet

是权益之策, 并非系统级解决方案. 而且, 舍弃的数 据在未来可能会重新使用, 以发掘更大的价值. 2 期望特性 本节我们列出对大数据进行分析时, 数据仓库 系统需具备的几个重要特性( 表 1 所示) . 表 1 大数据分析平台需具备的特性 特性 简要说明 高度可扩展性 横向大规模可扩展, 大规模并行处理 高性能 快速响应复杂查询与分析 高度容错性 查询失败时, 只需重做部分工作 支持异构环境 对硬件平台一致性要求不高, 适应能力强 较低的分析延迟 业务需求变化时, 能快速反应 易用且开放接口 既能方便查询, 又能处理复杂分析 较低成本 较高的性价比 向下兼容性 支持传统的商务智能工具 高度可扩展性. 一个明显的事实是, 数据库不 能依靠一台或少数几台机器的升级( scale-up 纵向 扩展) 满足数据量的爆炸式增长, 而是希望能方便地 做到横向可扩展( scale-out) 来实现此目标. 普遍认为 shared-no thing 无共享结构( 每个节 点拥有私有内存和磁盘, 并且通过高速网络同其它 节点互连) 具备较好的扩展性 [ 4] . 分析型操作往往涉 及大规模的并行扫描、多维聚集及星型连接操作, 这 些操作也比较适合在无共享结构的网络环境运行. Teradata 即采用此结构, Oracle 在其新产品 Ex adata 中也采用了此结构. 高性能. 数据量的增长并没有降低对数据库性 能的要求, 反而有所提高. 软件系统性能的提升可以 降低企业对硬件的投入成本、节省计算资源, 提高系 统吞吐量. 巨量数据的效率优化, 并行是必由之路. 1PB 数据在 50MB/ s 速度下串行扫描一次, 需要 230 天; 而在 6000 块磁盘上, 并行扫描 1PB 数据只 需要 1 个小时. 高度容错. 大数据的容错性要求在查询执行过 程中, 一个参与节点失效时, 不需要重做整个查询. 而机群节点数的增加会带来节点失效概率的增加. 在大规模机群环境下, 节点的失效将不再是稀有事 件( Goo gle 报告, 平均每个 M apReduce 数据处理任 务就有 11 2 个工作节点失效[ 5] ) . 因此在大规模机群 环境下, 系统不能依赖于硬件来保证容错性, 要更多 地考虑软件级容错. 支持异构环境. 建设同构系统的大规模机群难 度较大, 原因在于计算机硬件更新较快, 一次性购置 大量同构的计算机是不可取的, 而且也会在未来添 置异构计算资源. 此外, 不少企业已经积累了一些闲 置的计算机资源, 此种情况下, 对异构环境的支持可 以有效地利用这些闲置计算资源, 降低硬件成本的 投入. 还需特别关注的是, 在异构环境下, 不同节点 的性能是不一样的, 可能出现/ 木桶效应0, 即最慢节 点的性能决定整体处理性能. 因此, 异构的机群需要 特别关注负载均衡、任务调度等方面的设计. 较低的分析延迟. 分析延迟指的是分析前的数 据准备时间. 在大数据时代, 分析所处的业务环境是 变化的, 因此也要求系统能动态地适应业务分析需 求. 在分析需求发生变化时, 减少数据准备时间, 系 统能尽可能快地做出反应, 快速地进行数据分析. 易用且开放的接口. SQL 的优点是简单易用, 但其主要用于数据的检索查询, 对于大数据上的深 度分析来讲, 是不够的. 原因在于: ( 1) 其提供的服 务方式依赖于数据移动来实现: 将数据从数据库中 取出, 然后传递给应用程序, 该实现方式在大数据时 代代价过高; ( 2) 复杂的分析功能, 如 R 或 M atlab 中的分析功能, SQL 是难以胜任的. 因此, 除对 SQL 的支持外, 系统还应能提供开放的接口, 让用户自己 开发需要的功能. 设计该接口时, 除了关注其易用性 和开放性, 还需要特别注意两点隐藏的要求: ( 1) 基 于接口开发的用户自定义函数, 能自动在机群上并 行执行; ( 2) 分析在数据库内进行, 即分析尽可能靠 近数据. 较低的成本. 在满足需求的前提下, 某技术成 本越低, 其生命力就越强. 需要指出的是成本是一个 综合指标, 不仅仅是硬件或软件的代价, 还应包括日 常运维成本( 网络费用、电费、建筑等) 和管理人员成 本等. 据报告, 数据中心的主要成本不是硬件的购置 成本, 而是日常运维成本. 因此, 在设计系统时需要 更多地关注此项内容. 向下兼容性. 数据仓库发展的 30 年, 产生了大 量面向客户业务的数据处理工具( 如 Informactica、 DataStag e 等) 、分析软件( 如 SPSS、R、M atlab 等) 和 前端展现工具( 如水晶报表) 等. 这些软件是一笔宝 贵的财富, 已被分析人员所熟悉, 是大数据时代中小 规模数据分析的必要补充. 因此, 新的数据仓库需考 虑同传统商务智能工具的兼容性. 由于这些系统往 往提供标准驱动程序, 如 ODBC、JDBC 等, 这项需 求的实际要求是对 SQ L 的支持. 总之, 以较低的成本投入、高效地进行数据分 析, 是大数据分析的基本目标. 10 期 王 珊等: 架构大数据: 挑战、现状与展望 1743

l744 计算机学报 011年 模机群在现实中是较难实现的.因而,对异构硬件的 3并行数据库 支持能力影响了其扩展性;(3)并行数据库若做到大 规模可扩展,其代价将会较高(需基于高端硬件来保 并行数据库起源于20世纪80年代,当前主流证可靠性需购买昂贵的软件系统),从而限制了其 的并行数据库都同早期的Gamm和 grace!等扩展性;(4根据CAP理论,在分布式系统中数 并行数据库类似.这些数据库都支持标准SQL,并据一致性( Consistency)、可用性( A vailability)、子 且实现了数据库界过去30年提出的许多先进技术.网可分解性( Network Part itioning)不可同时兼得, 其主要采用 shar hing结构,将关系表在节点选择其中任两项,便会损害另一项.并行数据库追求 间横向划分,并且利用优化器来对执行过程进行调的是数据一致性和系统的可用性,从而影响了它的 度和管理.其目标是高性能和高可用性. 扩展能力 并行数据库的最大优势在于性能.这主要得益 此外,如L2节所讨论的,基于并行数据库实现 于数据库界近几十年的研究成果——许多先进的技的传统数据仓库借助于外围工具(ETL工具、OLAP 术手段及算法,如索引、数据压缩、物化视图、结果缓产品、B报表工具、统计分析软件等)来完成数据的 冲、O共享、优化的数据连接等但是在大数据时预处理和分析展现任务,导致其数据处理及分析过 代如前言所述,数据移动的实现方式将影响其程涉及大量的数据迁移和计算,分析延迟往往较高 性能. 并行数据库通过SQL向外提供数据访问服务,4 Mapreduce SQL因其简单易用的特点而被广泛使用.因此,大 多BI工具都支持基于标准SQL的数据交互方式 M maPreduce是2004年由Gogl提出的面向 使得关系数据库能较好地兼容当前多数BI工具.某大数据集处理的编程模型,起初主要用作互联网数 些数据库,如 IBM DB2还针对一些BI工具进行了据的处理,例如文档抓取、倒排索引的建立等.但由 优化.但在大数据分析面前,SQL接口面临巨大挑于其简单而强大的数据处理接口和对大规模并行执 战SQL的优势源于其对底层数据访问的封装,但行、容错及负载均衡等实现细节的隐藏该技术一经 封装在一定程度上影响了其开放性.而且并行数据推出便迅速在机器学习、数据挖掘、数据分析等领域 库提供的用户自定义函数大都是基于单数据库实例得到广泛应用 设计的,从而不能在机群上并行执行,也即意味着传 M maPreduce将数据处理任务抽象为一系列的 统的实现方式不适合大数据的处理及分析而且,在Map(映射- Reduce(化简)操作对Map主要完成数 并行数据库中实现用户自定义函数往往需要经过复据的过滤操作, Reduce主要完成数据的聚集操作 杂的系统交互,甚至要熟悉数据库的内部结构及系输入输出数据均以4ey, value格式存储.用户在使 统调用等,从而难以使用 用该编程模型时,只需按照自己熟悉的语言实现 并行数据库在扩展性、容错性、成本、对异构环Map函数和 Reduce函即可, M maPreduce框架会自 境的支持等几项上有所欠缺这几项实际是相互影动对任务进行划分以做到并行执行 响的,我们以其最大问题—扩展性为主线展开讨 下面本文将以基于 M maPreduce的开源实现 论.并行数据库大多支持有限扩展,一般可扩至数百 H ado op为主,对其主要特性进行介绍 节点的规模,尚未有数千节点规模的应用案例.并行 M apReduce是面向由数千台中低端计算机组 数据库扩展性有限主要因为如下几点:(1)并行数成的大规模机群而设计的,其扩展能力得益于其 据库软件级容错能力较差并行数据库基于高端硬 shared nothing结构、各个节点间的松耦合性和较 件设计,并且假设査询失败属于稀有事件.因此当查强的软件级容错能力:节点可以被任意地从机群中 询失败时,一般采取重做查询的方式而在大规模机移除,而几乎不影响现有任务的执行.该技术被称为 群环境下,查询失败将会变为一个普通事件极端情RAIN( Redundant/ Reliable Array of Independent 况下,并行数据有可能出现不停重做查询的局面;( and Inex pensive) Nodes). MapReduce卓越的扩展 (2)并行数据库对异构硬件的支持非常有限,且对能力己在工业界(Goge、 Facebook、 Baidu、 Taobao 于处理较慢的节点反应敏感,容易出现“木桶效应 如第2中所论述的完舍基同构硬件搭建木规blishing②:该理论目种尚有设servedhttp:/www.cnki.net

3 并行数据库 并行数据库起源于 20 世纪 80 年代, 当前主流 的并行数据库都同早期的 Gamma [ 6] 和 Grace [ 7] 等 并行数据库类似. 这些数据库都支持标准 SQL, 并 且实现了数据库界过去 30 年提出的许多先进技术. 其主要采用 shar ed-nothing 结构, 将关系表在节点 间横向划分, 并且利用优化器来对执行过程进行调 度和管理. 其目标是高性能和高可用性. 并行数据库的最大优势在于性能. 这主要得益 于数据库界近几十年的研究成果) )) 许多先进的技 术手段及算法, 如索引、数据压缩、物化视图、结果缓 冲、I/ O 共享、优化的数据连接等. 但是在大数据时 代, 如前言所述, 数据移动的实现方式将影响其 性能. 并行数据库通过 SQL 向外提供数据访问服务, SQ L 因其简单易用的特点而被广泛使用. 因此, 大 多 BI 工具都支持基于标准 SQL 的数据交互方式, 使得关系数据库能较好地兼容当前多数 BI 工具. 某 些数据库, 如 IBM DB2 还针对一些 BI 工具进行了 优化. 但在大数据分析面前, SQL 接口面临巨大挑 战. SQL 的优势源于其对底层数据访问的封装, 但 封装在一定程度上影响了其开放性. 而且并行数据 库提供的用户自定义函数大都是基于单数据库实例 设计的, 从而不能在机群上并行执行, 也即意味着传 统的实现方式不适合大数据的处理及分析. 而且, 在 并行数据库中实现用户自定义函数往往需要经过复 杂的系统交互, 甚至要熟悉数据库的内部结构及系 统调用等, 从而难以使用. 并行数据库在扩展性、容错性、成本、对异构环 境的支持等几项上有所欠缺. 这几项实际是相互影 响的, 我们以其最大问题) )) 扩展性为主线展开讨 论. 并行数据库大多支持有限扩展, 一般可扩至数百 节点的规模, 尚未有数千节点规模的应用案例. 并行 数据库扩展性有限主要因为如下几点: ( 1) 并行数 据库软件级容错能力较差. 并行数据库基于高端硬 件设计, 并且假设查询失败属于稀有事件. 因此当查 询失败时, 一般采取重做查询的方式. 而在大规模机 群环境下, 查询失败将会变为一个普通事件. 极端情 况下, 并行数据有可能出现不停重做查询的局面; ( 2) 并行数据库对异构硬件的支持非常有限, 且对 于处理较慢的节点反应敏感, 容易出现/ 木桶效应0. 如第 2 节中所论述的, 完全基于同构硬件搭建大规 模机群在现实中是较难实现的. 因而, 对异构硬件的 支持能力影响了其扩展性; ( 3) 并行数据库若做到大 规模可扩展, 其代价将会较高( 需基于高端硬件来保 证可靠性, 需购买昂贵的软件系统) , 从而限制了其 扩展性; ( 4) 根据CAP理论①[ 8] , 在分布式系统中, 数 据一致性( Consistency ) 、可用性( Availability ) 、子 网可分解性( Netwo rk Partitioning ) 不可同时兼得, 选择其中任两项, 便会损害另一项. 并行数据库追求 的是数据一致性和系统的可用性, 从而影响了它的 扩展能力. 此外, 如 11 2 节所讨论的, 基于并行数据库实现 的传统数据仓库借助于外围工具( ET L 工具、OLAP 产品、BI 报表工具、统计分析软件等) 来完成数据的 预处理和分析展现任务, 导致其数据处理及分析过 程涉及大量的数据迁移和计算, 分析延迟往往较高. 4 MapReduce M apReduce [ 5] 是 2004 年由 Go ogle 提出的面向 大数据集处理的编程模型, 起初主要用作互联网数 据的处理, 例如文档抓取、倒排索引的建立等. 但由 于其简单而强大的数据处理接口和对大规模并行执 行、容错及负载均衡等实现细节的隐藏, 该技术一经 推出便迅速在机器学习、数据挖掘、数据分析等领域 得到广泛应用[ 9] . M apReduce 将数据处理任务抽象为一系列的 M ap( 映射)-Reduce( 化简) 操作对. M ap 主要完成数 据的过滤操作, Reduce 主要完成数据的聚集操作. 输入输出数据均以〈key, value〉格式存储. 用户在使 用该编程模型时, 只需按照自己熟悉的语言实现 M ap 函数和 Reduce 函即可, M apReduce 框架会自 动对任务进行划分以做到并行执行. 下面本文将以基于 M apReduce 的开源实现 Hado op [ 10] 为主, 对其主要特性进行介绍. M apReduce 是面向由数千台中低端计算机组 成的大规模机群而设计的, 其扩展能力得益于其 shared-nothing 结构、各个节点间的松耦合性和较 强的软件级容错能力: 节点可以被任意地从机群中 移除, 而几乎不影响现有任务的执行. 该技术被称为 RA IN ( Redundant/ Reliable Arr ay of Independent ( and Inex pensive) No des) . MapReduce 卓越的扩展 能力已在工业界( Go ogle、Facebook、Baidu、Taobao 1744 计 算 机 学 报 2011 年 ① 该理论目前尚存争议

10期 王珊等:架构大数据:挑战、现状与展望 1745 等)得到了充分验证.M呷 pReduce对硬件的要求较环境下,每个查询都是直接从文件系统中读入原始 低,可以基于异构的廉价硬件来搭建机群,且免费开数据文件,而非传统的从数据库中读入经处理过的 源,因此其构建成本低于并行数据库.但基于文件,因此其元组解析代价远高于关系数据库对 MapReduce的应用软件相对较少,许多数据分析功数据分析领域来说,连接是关键操作(如传统的星型 能需要用户自行开发,从而会导致使用成本的增加.査询和雪花查询均是依赖于连接来处理查询),但 作为开源系统, MapReduce具有完全的开放 M maPreduce处理连接的性能尤其不尽如人意.原因 性:其key, value存储模型具有较强的表现力,可在于 Map Reduce最初是针对单数据集设计的处理 以存储仼意格式的数据;Ma和 Reduce两个基本模型,而连接操作往往涉及多个数据集.在利用 的函数接口也给用户提供了足够的发挥空间,可以 M apReduce实现连接时,最直接的方式是每个任务 实现各种复杂的数据处理功能但这种开放性也带来执行一个属性上的连接操作,然后将多个 MapReduce 一个问题,就是将本来应由数据库管理系统完成的工任务通过物化的中间结果串接起来这种实现方式 作,诸如文件存储格式的设计、模式信息的记录、数据往往涉及中间结果的读写,从而导致大量的Ⅳ/O操 处理算法的实现等,转移给了程序员,从而导致程序作和网络传输 员负担过重程序员水平对系统处理性能起决定性作 M apReduce目前基本不兼容现有的B工具 用在某些情况下,写 MapReduce程序的时间远大于原因在于其初衷并不是要成为数据库系统,因此它 写SQL语句的时间,部分复杂的BI报表分析,可能并未提供SQL接口.但已有研究致力于SQL语句 仅程序的编写和调试就要耗费几天的时间 与 M apReduce任务的转换工作(例如Hive),进而 基于 M maPreduce平台的分析,无需复杂的数据有可能实现 M apReduce与现存BI工具的兼容 预处理和写入数据库的过程,而是可以直接基于平 面文件进行分析,并且其采用的计算模式是移动计5并行数据库和 MapReduce的 算而非移动数据,因此可以将分析延迟最小化. 混合架构 在同等硬件条件下, MapReduce性能远低于并 行数据库,这是由其最初的设计定位决定的 基于以上分析,我们可以清楚地看出,基于并行 MapReduce的设计初衷是面向非结构化数据的处数据库和 Map reduce实现的数据仓库系统都不是 理这些数据具有数据量大,处理复杂等特点,而且大数据分析的理想方案.针对两者哪个更适合时代 往往是一次性处理.为了获得较好的扩展能力和容需求的问题,业界近年展开了激烈争论当前基本达 错能力, M mapreduce采取了基于扫描的处理模式和成如下共识:并行数据库和 Map Reduce是互补关 对中间结果步步物化的执行策略,从而导致较高的系,应该相互学习.基于该观点,大量研究着手 O代价.为了减少数据预处理时间, MapReduce将两者结合起来期望设计出兼具两者优点的数据 没有使用模式、索引、物化视图等技术手段.其数据分析平台.这种架构又可以分为三类:并行数据库主 预处理仅是一次数据加载操作,但由此导致了一个导型、 Map Reduce主导型、 M apRoduct和并行数据 问题一—较高的元组解析代价.在 M mapreduce库集成型(表2对3种架构进行了对比分析) 表2混合架构型解决方案对比分析 解决方案 着眼点 代表系统 并行数据库主导型 利用 MapReduce技术来增强其开放性, Greenplum规模扩展性未改变 M apReduce主导型 学习关系数据库的SQL接口及模式支Hive 持等,改善其易用性 性能问题未改变 H B行各自的某些优点在集成后也丧失了 并行数据库和 MapReduce集成型集成两者,使两者各自做各自擅长的工作 Vertica 性能和扩展性仍不能兼得 规模扩展性未变 5.1并行数据库主导型 (已被EMC收购和 Aster datal(已被 Teradata收购 该种方式关注于如何利用 M maPreduce来增强并 Aster data将SQL和 MapReduce进行结合, 行数据库的数据处理能力代表性系统是 Greenplum针对大数据分析提出了 SQL MapReduce框架1 o1994-2012ChinaAcademicJournalElectronicpUblishingHouse.Allrightsreservedhttp://www.cnki.net

等) 得到了充分验证. M apReduce 对硬件的要求较 低, 可以基于异构的廉价硬件来搭建机群, 且免费开 源, 因此其 构建成 本低于 并行数 据库. 但基 于 MapReduce的应用软件相对较少, 许多数据分析功 能需要用户自行开发, 从而会导致使用成本的增加. 作为开源系统, MapReduce 具有完全的开放 性: 其〈key, v alue〉存储模型具有较强的表现力, 可 以存储任意格式的数据; M ap 和 Reduce 两个基本 的函数接口也给用户提供了足够的发挥空间, 可以 实现各种复杂的数据处理功能. 但这种开放性也带来 一个问题, 就是将本来应由数据库管理系统完成的工 作, 诸如文件存储格式的设计、模式信息的记录、数据 处理算法的实现等, 转移给了程序员, 从而导致程序 员负担过重. 程序员水平对系统处理性能起决定性作 用. 在某些情况下, 写 MapReduce 程序的时间远大于 写SQL 语句的时间, 部分复杂的 BI 报表分析, 可能 仅程序的编写和调试就要耗费几天的时间. 基于 M apReduce 平台的分析, 无需复杂的数据 预处理和写入数据库的过程, 而是可以直接基于平 面文件进行分析, 并且其采用的计算模式是移动计 算而非移动数据, 因此可以将分析延迟最小化. 在同等硬件条件下, MapReduce 性能远低于并 行数据库 [ 11] , 这是由其最初的设计定位决定的. MapReduce 的设计初衷是面向非结构化数据的处 理. 这些数据具有数据量大, 处理复杂等特点, 而且 往往是一次性处理. 为了获得较好的扩展能力和容 错能力, M apReduce 采取了基于扫描的处理模式和 对中间结果步步物化的执行策略, 从而导致较高的 I/ O 代价. 为了减少数据预处理时间, M apReduce 没有使用模式、索引、物化视图等技术手段. 其数据 预处理仅是一次数据加载操作, 但由此导致了一个 问题 ))) 较高的元组解析代价[ 12] . 在 M apReduce 环境下, 每个查询都是直接从文件系统中读入原始 数据文件, 而非传统的从数据库中读入经处理过的 文件, 因此其元组解析代价远高于关系数据库. 对 数据分析领域来说, 连接是关键操作( 如传统的星型 查询和雪花查询均是依赖于连接来处理查询) , 但 M apReduce处理连接的性能尤其不尽如人意. 原因 在于 MapReduce 最初是针对单数据集设计的处理 模型, 而连接操作往往涉及多个数据集. 在利用 M apReduce实现连接时, 最直接的方式是每个任务 执行一个属性上的连接操作, 然后将多个 MapReduce 任务通过物化的中间结果串接起来. 这种实现方式 往往涉及中间结果的读写, 从而导致大量的 I/ O 操 作和网络传输. M apReduce 目前基本不兼容现有的 BI 工具. 原因在于其初衷并不是要成为数据库系统, 因此它 并未提供 SQ L 接口. 但已有研究致力于 SQL 语句 与 M apReduce 任务的转换工作( 例如 Hive) , 进而 有可能实现 M apReduce 与现存 BI 工具的兼容. 5 并行数据库和 MapReduce 的 混合架构 基于以上分析, 我们可以清楚地看出, 基于并行 数据库和 MapReduce 实现的数据仓库系统都不是 大数据分析的理想方案. 针对两者哪个更适合时代 需求的问题, 业界近年展开了激烈争论. 当前基本达 成如下共识: 并行数据库和 MapReduce 是互补关 系, 应该相互学习[ 13-14] . 基于该观点, 大量研究着手 将两者结合起来, 期望设计出兼具两者优点的数据 分析平台. 这种架构又可以分为三类: 并行数据库主 导型、MapReduce 主导型、M apReduce 和并行数据 库集成型( 表 2 对 3 种架构进行了对比分析) . 表 2 混合架构型解决方案对比分析 解决方案 着眼点 代表系统 缺陷 并行数据库主导型 利用 MapReduce 技术来增强其开放性, 以实现处理能力的可扩展 Greenplum Aster Data 规模扩展性未改变 MapReduce 主导型 学习关系数据库的 SQL 接口及模式支 持等, 改善其易用性 H ive Pig Latin 性能问题未改变 并行数据库和MapReduce 集成型 集成两者, 使两者各自做各自擅长的工作 H adoopDB 只有少数查询可以下推至数据库层执 行, 各自的某些优点在集成后也丧失了 Vertica 性能和扩展性仍不能兼得 T eradata 规模扩展性未变 5. 1 并行数据库主导型 该种方式关注于如何利用 M apReduce 来增强并 行数据库的数据处理能力. 代表性系统是 Greenplum ( 已被 EMC 收购) 和Aster Data( 已被T eradata收购) . Aster Data 将 SQL 和 MapReduce 进行结合, 针对大数据分析提出了 SQL/ MapReduce 框架 [ 15] . 10 期 王 珊等: 架构大数据: 挑战、现状与展望 1745

1746 计算机学报 011年 该框架允许用户使用C++、java、 Python等语言编 nad Use 写 MapReduce函数,编写的函数可以作为一个子查 询在SQL中使用,从而同时获得SQL的易用性和 MapReduce的开放性.不仅如此, Aster d at a基于 Grouped- group MapReduce实现了30多个统计软件包,从而将数 据分析推向数据库内进行(数据库内分析),大大提 升了数据分析的性能 Greenplum也在其数据库中引入了 M maPreduce 处理功能.其执行引擎可以同时处理SQL查询 图3 Pig Latin的一个查询示例(右边为实际脚本) 和 MapReduce任务这种方式在代码级整合了 SQL Stonebraker等人设计的 V erica42数据库和NCR 和 Map reduce:sQL可以直接使用 M apReduce任公司的 Teradata42数据库 务的输出,同时 M apRoduct任务也可以使用SQL H adoopD B的核心思想是利用 H adop作为调 的查询结果作为输入 度层和网络沟通层,关系数据库作为执行引擎,尽可 总的来说这些系统都集中于利用 MapReduce能地将查询压入数据库层处理目标是想借助 来改进并行数据库的数据处理功能,其根本性问 Hado框架来获得较好的容错性和对异构环境的 题——可扩展能力和容错能力并未改变. 支持:通过将査询尽可能推入数据库中执行来获得 52 Mapreduce主导型 关系数据库的性能优势. H ado opD B的思想是深远 该方向的研究主要集中于利用关系数据库的的但目前尚无应用案例,原因在于:(1)其数据预 SQL接口和对模式的支持等技术来改善 M apReduce处理代价过高:数据需要进行两次分解和一次数据 的易用性代表系统是Hive、 Pig lat in1等 库加载操作后才能使用;(2)将查询推向数据库层 Hie是 Facebook提出的基于 Hadoop的大型只是少数情况,大多数情况下,查询仍由Hive完 数据仓库,其目标是简化 H adop上的数据聚集、成因为数据仓库查询往往涉及多表连接,由于连接 adt hoc查询及大数据集的分析等操作,以减轻程序的复杂性,难以做到在保持连接数据局部性的前提 员的负担它借鉴关系数据库的模式管理、SQL接下将参与连接的多张表按照某种模式划分;(3)维 口等技术,把结构化的数据文件映射为数据库表提护代价过高.不仅要维护 H ado op系统还要维护每 供类似于SQL的描述性语言 Hive QL供程序员使个数据库节点:(4目前尚不支持数据的动态划分,需 用可自动将 Hive QL语句解析成一优化的Ma要手工方式将数据一次性划分好总的来说,H pReduce任务执行序列此外,它也支持用户自定义 do opD B在某些情况下,可以同时实现关系数据库 的 Map Reduce函数 的高性能特性和 M maPreduce的扩展性、容错性,但 Pig lat in是Yaoo!提出的类似于Hive的大同时也丧失了关系数据库和 M ap Reduce的某些优 数据集分析平台.两者的区别主要在于语言接口.点,比如 MapReduce较低的预处理代价和维护代 Hie提供了类似sQL的接口, Pig latin提供的是价、关系数据库的动态数据重分布等 种基于操作符的数据流式的接口.图3是Pig Vertica采用的是共存策略:根据 H adop和 Latin在处理查询时的一个操作实例该查询的目的 Vertica各自的处理优势,对数据处理任务进行划 是找出“年龄在18-25周岁之间的用户(Ues)最分.比如Hap负责非结构化数据的处理, Vertica 频繁访问的5个页面( Pages)”从图3可以看出,负责结构化数据的处理:Had Pig提供的操作接口类似于关系数据库的操作符复杂处理,Ⅴ erica负责高性能的交互式查询等,从 (对应图中右侧部分中的每一行命令),用户查询的而将两者结合起来Ⅴ erica实际采用的是两套系统 脚本类似于逻辑查询计划(对应图中左侧部分).因同时支持在M甲Rede任务中直接访问Ⅴ erica数 此也可以说Pig利用操作符来对 Hadoop进行封据库中的数据.由于结构化数据仍在 Vertica中处 装,Hive利用SQL进行封装 理,在处理结构化大数据上的查询分析时,仍面临扩 53 Mapreduce和并行数据库集成型 展性问题:如果将查询推向 Hadoop进行,又将面临 该方向的代表性研究是耶鲁大学提出的性能问题因此Ⅴ erica的扩展性问题和 H adop 1gpge201商出化为H)h的性能间题在该系统中基存uhp/www.cnki.net

该框架允许用户使用 C+ + 、java、Python 等语言编 写 MapReduce 函数, 编写的函数可以作为一个子查 询在 SQL 中使用, 从而同时获得 SQL 的易用性和 MapReduce 的开放性. 不仅如此, Aster Data 基于 MapReduce 实现了 30 多个统计软件包, 从而将数 据分析推向数据库内进行( 数据库内分析) , 大大提 升了数据分析的性能. Greenplum 也在其数据库中引入了 M apReduce 处理功能 [ 16] . 其执行引擎可以同时处理 SQ L 查询 和 MapReduce 任务. 这种方式在代码级整合了 SQL 和 MapReduce: SQ L 可以直接使用 M apReduce 任 务的输出, 同时 M apReduce 任务也可以使用 SQL 的查询结果作为输入. 总的来说, 这些系统都集中于利用 M apReduce 来改进并行数据库的数据处理功能, 其根本性问 题)) ) 可扩展能力和容错能力并未改变. 5. 2 MapReduce 主导型 该方向的研究主要集中于利用关系数据库的 SQ L 接口和对模式的支持等技术来改善 M apReduce 的易用性, 代表系统是 Hive [ 17] 、Pig Latin [ 18] 等. Hiv e 是 Faceboo k 提出的基于 Hadoop 的大型 数据仓库, 其目标是简化 Hadoo p 上的数据聚集、 ad-hoc 查询及大数据集的分析等操作, 以减轻程序 员的负担. 它借鉴关系数据库的模式管理、SQL 接 口等技术, 把结构化的数据文件映射为数据库表, 提 供类似于 SQL 的描述性语言 HiveQL 供程序员使 用, 可自动将 HiveQL 语句解析成一优化的 Ma￾pReduce 任务执行序列. 此外, 它也支持用户自定义 的 MapReduce 函数. Pig Latin 是 Yahoo ! 提出的类似于 Hiv e 的大 数据集分析平台. 两者的区别主要在于语言接口. Hive 提供了类似 SQL 的接口, Pig Latin 提供的是 一种基于操作符的数据流式的接口. 图 3 是 Pig Latin 在处理查询时的一个操作实例. 该查询的目的 是找出/ 年龄在 18~ 25 周岁之间的用户( U sers) 最 频繁访问的 5 个页面( Pages)0. 从图 3 可以看出, Pig 提供的操作接口类似于关系数据库的操作符 ( 对应图中右侧部分中的每一行命令) , 用户查询的 脚本类似于逻辑查询计划( 对应图中左侧部分) . 因 此, 也可以说 Pig 利用操作符来对 Hadoop 进行封 装, Hive 利用 SQL 进行封装. 5. 3 MapReduce 和并行数据库集成型 该方向 的代 表性 研究 是耶 鲁大 学提 出 的 HadoopDB [ 19] ( 已于 2011 年商业化为 Hadapt [ 20] ) 、 图 3 Pig Latin 的一个查询示例( 右边为实际脚本) Stonebraker 等人设计的 V ertica [ 21] 数据库和 N CR 公司的 T er adata [ 22] 数据库. Hado opDB 的核心思想是利用 H adoop 作为调 度层和网络沟通层, 关系数据库作为执行引擎, 尽可 能地将查询压入数据库层处理. 目标是想借助 Hado op 框架来获得较好的容错性和对异构环境的 支持; 通过将查询尽可能推入数据库中执行来获得 关系数据库的性能优势. Hado opDB 的思想是深远 的, 但目前尚无应用案例, 原因在于: ( 1) 其数据预 处理代价过高: 数据需要进行两次分解和一次数据 库加载操作后才能使用; ( 2) 将查询推向数据库层 只是少数情况, 大多数情况下, 查询仍由 Hive 完 成. 因为数据仓库查询往往涉及多表连接, 由于连接 的复杂性, 难以做到在保持连接数据局部性的前提 下将参与连接的多张表按照某种模式划分; ( 3) 维 护代价过高. 不仅要维护 Hado op 系统, 还要维护每 个数据库节点; ( 4) 目前尚不支持数据的动态划分,需 要手工方式将数据一次性划分好. 总的来说, Ha￾do opDB 在某些情况下, 可以同时实现关系数据库 的高性能特性和 M apReduce 的扩展性、容错性, 但 同时也丧失了关系数据库和 M apReduce 的某些优 点, 比如 M apReduce 较低的预处理代价和维护代 价、关系数据库的动态数据重分布等. Vertica 采用的是共存策略: 根据 Hadoo p 和 Vertica 各自的处理优势, 对数据处理任务进行划 分. 比如 H adoop 负责非结构化数据的处理, Vertica 负责结构化数据的处理; Hadoop 负责耗时的批量 复杂处理, Vertica 负责高性能的交互式查询等, 从 而将两者结合起来. Vertica 实际采用的是两套系统, 同时支持在 M apReduce 任务中直接访问 Vertica 数 据库中的数据. 由于结构化数据仍在 Vertica 中处 理, 在处理结构化大数据上的查询分析时, 仍面临扩 展性问题; 如果将查询推向 Hadoop 进行, 又将面临 性能问题. 因此, Vertica 的扩展性问题和 H adoop 的性能问题在该系统中共存. 1746 计 算 机 学 报 2011 年

10期 王珊等:架构大数据:挑战、现状与展望 1747 与前两者相比, Terada a的集成相对简单.询执行过程中看到部分较早返回的结果.两者的不 Terada a采用了存储层的整合: MapReduce任务可同之处在于前者仍基于sor- merge方式来实现流 以从 Teradata数据库中读取数据, Teradata数据库水线,只是将排序等操作推向了 reducer,部分情况 也可以从 Hadoop分布式文件系统上读取数据.同下仍会出现流水线停顿的情况;而后者利用hash方 样, Terada a和 Hadoop各自的根本性问题都未解决.式来分布数据,能实现更好的并行流水线操作.文 献[30提出了 MRShare架构,对批量查询进行转 6研究现状 换,将可共享扫描、共享Map输出结果等的一组任 务合并为一个,以提升性能新加坡国立大学对影响 对并行数据库来讲,其最大问题在于有限的扩 Hadoop性能的因素做了深入分析,并提出了 展能力和待改进的软件级容错能力; MapReduce的5项有效的优化技术,使得 H adop的性能提升了 最大问题在于性能,尤其是连接操作的性能混合式近3倍,逼近关系数据库的性能 架构的关键是0,如何能尽可能多地把工作推向合 近年的研究热点是基于 M maPreduce的连接操 适的执行引擎(并行数据库或 Map Reduce).本节对作的性能优化.文献31对 M maPreduce平台的两表 近年来在这些问题上的研究做一分析和归纳 连接算法做了总结,提出了Map端连接、 Reduce端 6.1并行数据库扩展性和容错性研究 连接及广播式连接等算法.文献[32]对 MapReduce 华盛顿大学在文献23中提出了可以生成具备框架进行了扩展,在 Reduce步骤后添加了一 Merge 容错能力的并行执行计划优化器.该优化器可以依步骤来完成连接操作,提出的 M aReduce-Merge 靠输入的并行执行计划、各个操作符的容错策略及框架可以同时处理两个异构数据源的数据.对于多 査询失败的期望值等,输出一个具备容错能力的并表连接,当前主流的研究集中于仅通过一个任务来 行执行计划在该计划中,每个操作符都可以采取不完成连接操作.文献3334提出了一对多复制的方 同的容错策略,在失败时仅重新执行其子操作符(在法,在Ma阶段结束后,为保证连接操作的局部性, 某节点上运行的操作符)的任务来避免整个查询的元组会被复制到多个节点.但在节点数和数据量增 重新执行 大的情况下,会带来ⅣO量及网络传输量的巨大增 MIT于2010年设计的 Osprey系统基于维长 Llam a3通过预排序和按连接属性划分数据的 表在各个节点全复制、事实表横向切分并冗余备份方式来降低星型连接的代价,但要付出可观的预处 的数据分布策略,将一星型查询划分为众多独立子理代价和空间代价.不同于以上等值连接优化,文 查询每个子查询在执行失败时都可以在其备份节献[36]提出了针对任意连接条件的优化模型.以上 点上重新执行,而不用重做整个查询,使得数据仓库连接方式都是先执行连接,然后在连接后的数据上 查询获得类似 M maPreduce的容错能力 执行聚集操作而中国人民大学的 Dumbo 371系统 数据仓库扩展性方面的研究较少,中国人民大却用了另一种更适应于 M ap Reduce平台的思路: 学的 LineardB原型属于这方面的研究,详细参见先执行过滤聚集操作,再基于聚集的数据执行连接 详细参考72节 6.2 Mapreduce性能优化研究 6.3 HadoopDB的改进 MapReduce的性能优化研究集中于对关系数 H adoopD B于2011年针对其架构提出了两种 据库的先进技术和特性的移植上 连接优化技术和两种聚集优化技术3 Facebook和俄亥俄州立大学合作,将关系数据 两种连接优化的核心思想都是尽可能地将数据 库的混合式存储模型应用于 H adop平台,提出了的处理推入数据库层执行.第1种优化方式是根据 RCFile存储格式当.与之不同,文献[26将列存储表与表之间的连接关系,通过数据预分解,使参与连 技术引入 H ado op平台. H adop++12系统运用了接的数据尽可能分布在同一数据库内(参照分解 传统数据库的索引技术,并通过分区数据并置法),从而实现将连接操作下压进数据库内执行.该 ( CePart it ion)的方式来提升性能.文献[2829基算法的缺点是应用场景有限,只适用于链式连接.第 于 MapReduce实现了以流水线方式在各个操作符 间传递数据,从而缩短了任务执行时间;在线聚集 ①其最大问题既包括扩展性也包括性能,这两项分别取决 ( on line aggregation)的操作模式使得用启可以蕉章 blishing h种系统间的 行数据库和 M abReu(木桶原理),其改进取决于这

与前两者相比, Teradata 的集成相对简单. Teradata 采用了存储层的整合: M apReduce 任务可 以从 T er adata 数据库中读取数据, T eradata 数据库 也可以从 Hadoop 分布式文件系统上读取数据. 同 样, Teradata 和 Hadoop 各自的根本性问题都未解决. 6 研究现状 对并行数据库来讲, 其最大问题在于有限的扩 展能力和待改进的软件级容错能力; MapReduce 的 最大问题在于性能, 尤其是连接操作的性能; 混合式 架构的关键是①, 如何能尽可能多地把工作推向合 适的执行引擎( 并行数据库或 M apReduce) . 本节对 近年来在这些问题上的研究做一分析和归纳. 6. 1 并行数据库扩展性和容错性研究 华盛顿大学在文献[ 23] 中提出了可以生成具备 容错能力的并行执行计划优化器. 该优化器可以依 靠输入的并行执行计划、各个操作符的容错策略及 查询失败的期望值等, 输出一个具备容错能力的并 行执行计划. 在该计划中, 每个操作符都可以采取不 同的容错策略, 在失败时仅重新执行其子操作符( 在 某节点上运行的操作符) 的任务来避免整个查询的 重新执行. MIT 于 2010 年设计的 Osprey 系统 [ 24] 基于维 表在各个节点全复制、事实表横向切分并冗余备份 的数据分布策略, 将一星型查询划分为众多独立子 查询. 每个子查询在执行失败时都可以在其备份节 点上重新执行, 而不用重做整个查询, 使得数据仓库 查询获得类似 M apReduce 的容错能力. 数据仓库扩展性方面的研究较少, 中国人民大 学的 LinearDB 原型属于这方面的研究, 详细参见 71 1 节. 6. 2 MapReduce 性能优化研究 MapReduce 的性能优化研究集中于对关系数 据库的先进技术和特性的移植上. Facebook 和俄亥俄州立大学合作, 将关系数据 库的混合式存储模型应用于 Hadoop 平台, 提出了 RCFile 存储格式 [ 25] . 与之不同, 文献[ 26] 将列存储 技术引入 Hado op 平台. Hadoop+ + [ 27] 系统运用了 传统数据库的索引技术, 并通过分区数据并置 ( Co-Partition) 的方式来提升性能. 文献[ 28-29] 基 于 MapReduce 实现了以流水线方式在各个操作符 间传递数据, 从而缩短了任务执行时间; 在线聚集 ( online ag gregation) 的操作模式使得用户可以在查 询执行过程中看到部分较早返回的结果. 两者的不 同之处在于前者仍基于 sort-merge 方式来实现流 水线, 只是将排序等操作推向了 r educer, 部分情况 下仍会出现流水线停顿的情况; 而后者利用 hash 方 式来分布数据, 能实现更好的并行流水线操作. 文 献[ 30] 提出了 MRShare 架构, 对批量查询进行转 换, 将可共享扫描、共享 M ap 输出结果等的一组任 务合并为一个, 以提升性能. 新加坡国立大学对影响 Hado op 性能的因素做了深入分析 [ 12] , 并提出了 5 项有效的优化技术, 使得 Hadoop 的性能提升了 近 3 倍, 逼近关系数据库的性能. 近年的研究热点是基于 M apReduce 的连接操 作的性能优化. 文献[ 31] 对 M apReduce 平台的两表 连接算法做了总结, 提出了 M ap 端连接、Reduce 端 连接及广播式连接等算法. 文献[ 32] 对 MapReduce 框架进行了扩展, 在 Reduce 步骤后添加了一 M er ge 步骤来完成连接操作, 提出的 M ap-Reduce-M er ge 框架可以同时处理两个异构数据源的数据. 对于多 表连接, 当前主流的研究集中于仅通过一个任务来 完成连接操作. 文献[ 33-34] 提出了一对多复制的方 法, 在 M ap 阶段结束后, 为保证连接操作的局部性, 元组会被复制到多个节点. 但在节点数和数据量增 大的情况下, 会带来 I/ O 量及网络传输量的巨大增 长. Llama [ 35] 通过预排序和按连接属性划分数据的 方式来降低星型连接的代价, 但要付出可观的预处 理代价和空间代价. 不同于以上等值连接优化, 文 献[ 36] 提出了针对任意连接条件的优化模型. 以上 连接方式都是先执行连接, 然后在连接后的数据上 执行聚集操作. 而中国人民大学的 Dumbo [ 37] 系统 却采用了另一种更适应于 M apReduce 平台的思路: 先执行过滤聚集操作, 再基于聚集的数据执行连接. 详细参考 71 2 节. 6. 3 HadoopDB 的改进 Hado opDB 于 2011 年针对其架构提出了两种 连接优化技术和两种聚集优化技术 [ 38] . 两种连接优化的核心思想都是尽可能地将数据 的处理推入数据库层执行. 第 1 种优化方式是根据 表与表之间的连接关系, 通过数据预分解, 使参与连 接的数据尽可能分布在同一数据库内( 参照分解 法) , 从而实现将连接操作下压进数据库内执行. 该 算法的缺点是应用场景有限, 只适用于链式连接. 第 10 期 王 珊等: 架构大数据: 挑战、现状与展望 1747 ① 其最大问题既包括扩展性也包括性能, 这两项分别取决于 并行数据库和M apRedu ce( 木桶原理) , 其改进取决于这两 种系统问题的改进

计算机学报 011年 2种连接方式是针对广播式连接而设计的在执行为 Transform、 Reduce、Mege3个操作(TRM执行 连接前先在数据库内为每张参与连接的维表建立模型):(1) Transform.主节点对查询进行预处理, 张临时表,使得连接操作尽可能在数据库内执行.将查询中作用于维表的操作(主要是谓词判断, 该算法的缺点是较多的网络传输和磁盘ⅣO操作. groupby聚集操作等)转换为事实表上的操作; 两种聚集优化技术分别是连接后聚集和连接前(2) Reduce每个数据节点并行地扫描、聚集本地数 聚集前者是执行完 Reduce端连接后,直接对符合据,然后将处理结果返回给主节点;(3) Merge.主节 条件的记录执行聚集操作;后者是将所有数据先在点对各个数据节点返回的结果进行合并,并执行后 数据库层执行聚集操作,然后基于聚集数据执行连续的过滤、排序等操作.基于TRM执行模型,查询 接操作,并将不符合条件的聚集数据做减法操作.该可以划分为众多独立的子任务在大规模机群上并行 方式适用的条件有限,主要用于参与连接和聚集的执行执行过程中,任何失败子任务都可以在其备 列的基数相乘后小于表记录数的情况 份节点重新执行,从而获得较好的容错能力 总的来看, H adoopD B的优化技术大都局限性 Linearl的执行代价主要取决于对事实表的 较强对于复杂的连接操作(如环形连接等)仍不能下 Reduce(主要是扫描)操作,因此, LinearL可以获 推至数据库层执行,并未从根本上解决其性能问题.得近乎线性的大规模可扩展能力.实验表明,其性能 比 H adoopD B至少高出一个数量级 7 MapReduce和关系数据库技术的 LineardB的扩展能力、容错能力和高性能在于 融合 其巧妙地结合了关系数据库技术(层次编码技术、泛 关系模式和 M maPreduce处理模式的设计思想,由 综上所述,当前研究大都集中于功能或特性的此,可以看出,结合方式的不同可以导致系统能力的 移植,即从一个平台学习新的技术,到另一平台重新巨大差异 实现和集成,未涉及执行核心,因此也没有从根本上72 Dumbo 解决大数据分析问题.鉴于此,中国人民大学高性能 Dumbo3的核心思想是根据 M Reduce的 数据库实验室的研究小组采取了另一种思路:从数“过滤->聚集”的处理模式,对OLAP查询的处理 据的组织和查询的执行两个核心层次入手,融合关进行改造,使其适应于 M prOduce框架 系数据库和 MapReduce两种技术,设计高性能的可 Dumbo采用了类似于 LinearDB的数据组织模 扩展的抽象数据仓库査询处理框架.该框架在支持式一利用层次编码技术将维表信息压缩进事实 高度可扩展的同时,又具有关系数据库的性能.我们表,区别在于 Dum bo采用了更加有效的编码方式 团队尝试过两个研究方向:(1)借鉴 MapReduce的并针对 H ado op分布式文件系统的特点对数据的存 思想,使OLAP查询的处理能像 M ap Reduce一样储进行了优化 高度可扩展( LineardB原型);(2)利用关系数据库 在执行层次上, Dumbo对 M maPreduce框架进 的技术,使 MapReduce在处理OLAP查询时,逼近行了扩展,设计了新的OLAP查询处理框架— 关系数据库的性能( Dumbo原型) TMRP(Transform->M ap-> Reduce-> Postpro 7.1 LinearDB ces)处理框架(如图5所示).在该框架中,主节点 Lineardb原型系统没有直接采用基于连接首先对查询进行转换,生成一个 MapReduce务来 的星型模型雪花模型,而是对其进行了改造,设计执行査询.该任务在Map阶段以流水线方式扫描、 了扩展性更好的、基于扫描的无连接雪花模型JFSS聚集本地数据,并只将本地的聚集数据传至Re ( Joint Free Snow flake Schema).该模型的设计借鉴duce阶段,来进行数据的合并及聚集、排序等操作 泛关系模型的思想,采用层次编码技术将维表在 Postpro cess阶段,主节点在数据节点上传的聚集 层次信息压缩进事实表,使得事实表可以独立执行数据之上执行连接操作.实验表明, Dumbo性能远 维表上的谓词判断、聚集等操作,从而使连接的数据超 Hadoop和 H ado opD B. 在大规模机群上实现局部性,消除了连接操作.图4 由此我们可以看出,复杂的OLAP查询在 是一个星型模型和无连接雪花模型的对应示意图 在执行层次上, Linear dB吸取了M educe ①又名为 LaSCOLap. ②此数据是基于我们自己实现的key, value列存模型之上 处理模式的设计思想将数据仓库查询的处理抽象 ublishing h测试得用的结果与文越(3中所到性能有所不同 nki.net

2 种连接方式是针对广播式连接而设计的. 在执行 连接前, 先在数据库内为每张参与连接的维表建立 一张临时表, 使得连接操作尽可能在数据库内执行. 该算法的缺点是较多的网络传输和磁盘 I/ O 操作. 两种聚集优化技术分别是连接后聚集和连接前 聚集. 前者是执行完 Reduce 端连接后, 直接对符合 条件的记录执行聚集操作; 后者是将所有数据先在 数据库层执行聚集操作, 然后基于聚集数据执行连 接操作, 并将不符合条件的聚集数据做减法操作. 该 方式适用的条件有限, 主要用于参与连接和聚集的 列的基数相乘后小于表记录数的情况. 总的来看, Hado opDB 的优化技术大都局限性 较强, 对于复杂的连接操作( 如环形连接等) 仍不能下 推至数据库层执行, 并未从根本上解决其性能问题. 7 MapReduce 和关系数据库技术的 融合 综上所述, 当前研究大都集中于功能或特性的 移植, 即从一个平台学习新的技术, 到另一平台重新 实现和集成, 未涉及执行核心, 因此也没有从根本上 解决大数据分析问题. 鉴于此, 中国人民大学高性能 数据库实验室的研究小组采取了另一种思路: 从数 据的组织和查询的执行两个核心层次入手, 融合关 系数据库和 MapReduce 两种技术, 设计高性能的可 扩展的抽象数据仓库查询处理框架. 该框架在支持 高度可扩展的同时, 又具有关系数据库的性能. 我们 团队尝试过两个研究方向: ( 1) 借鉴 MapReduce 的 思想, 使 OLAP 查询的处理能像 M apReduce 一样 高度可扩展( LinearDB 原型) ; ( 2) 利用关系数据库 的技术, 使 MapReduce 在处理 OLAP 查询时, 逼近 关系数据库的性能( Dumbo 原型) . 7. 1 LinearDB LinearDB ①[ 39] 原型系统没有直接采用基于连接 的星型模型( 雪花模型) , 而是对其进行了改造, 设计 了扩展性更好的、基于扫描的无连接雪花模型 JFSS ( Jo in-Free Snow flake Schema) . 该模型的设计借鉴 了泛关系模型的思想, 采用层次编码技术 [ 40] 将维表 层次信息压缩进事实表, 使得事实表可以独立执行 维表上的谓词判断、聚集等操作, 从而使连接的数据 在大规模机群上实现局部性, 消除了连接操作. 图 4 是一个星型模型和无连接雪花模型的对应示意图. 在执行层次上, LinearDB 吸取了 M apReduce 处理模式的设计思想, 将数据仓库查询的处理抽象 为 T ransfo rm、Reduce、M er ge 3 个操作( T RM 执行 模型) : ( 1) T ransform. 主节点对查询进行预处理, 将查询中作用于维表的操作( 主要是谓词判断, g roup-by 聚集操作等) 转换为事实表上的操作; ( 2) Reduce. 每个数据节点并行地扫描、聚集本地数 据, 然后将处理结果返回给主节点; ( 3) M erg e. 主节 点对各个数据节点返回的结果进行合并, 并执行后 续的过滤、排序等操作. 基于 TRM 执行模型, 查询 可以划分为众多独立的子任务在大规模机群上并行 执行. 执行过程中, 任何失败子任务都可以在其备 份节点 重新 执行, 从 而获 得较好 的容 错能 力. LinearDB 的执 行代价 主要 取决 于对 事实 表的 Reduce ( 主要是扫描) 操作, 因此, LinearDB 可以获 得近乎线性的大规模可扩展能力. 实验表明, 其性能 比 HadoopDB 至少高出一个数量级②. LinearDB 的扩展能力、容错能力和高性能在于 其巧妙地结合了关系数据库技术( 层次编码技术、泛 关系模式) 和 M apReduce 处理模式的设计思想, 由 此, 可以看出, 结合方式的不同可以导致系统能力的 巨大差异. 71 2 Dumbo Dumbo [ 37] 的核心思想是根据 M apReduce 的 / 过滤- > 聚集0的处理模式, 对 OLAP 查询的处理 进行改造, 使其适应于 M apReduce 框架. Dumbo 采用了类似于 LinearDB 的数据组织模 式 ))) 利用层次编码技术将维表信息压缩进事实 表, 区别在于 Dumbo 采用了更加有效的编码方式, 并针对 Hado op 分布式文件系统的特点对数据的存 储进行了优化. 在执行层次上, Dumbo 对 M apReduce 框架进 行了扩展, 设计了新的 OLAP 查询处理框架 ))) T MRP( T ransfo rm- > M ap- > Reduce- > Postpro￾cess) 处理框架( 如图 5 所示) . 在该框架中, 主节点 首先对查询进行转换, 生成一个 M apReduce 任务来 执行查询. 该任务在 M ap 阶段以流水线方式扫描、 聚集本地数据, 并只将本地的聚集数据传至 Re￾duce 阶段, 来进行数据的合并及聚集、排序等操作. 在 Postpro cess 阶段, 主节点在数据节点上传的聚集 数据之上执行连接操作. 实验表明, Dumbo 性能远 超 Hadoop 和 Hado opDB. 由此我们可以看 出, 复 杂的 OLA P 查询在 1748 计 算 机 学 报 2011 年 ① ② 又名为 LaS cOLAP. 此数据是基于我们自己实现的〈key, value〉列存模型之上 测试得出的结果, 与文献[ 39] 中所列性能有所不同

10期 王珊等:架构大数据:挑战、现状与展望 1749 (a) Star Schema 199612 Bei jing te Sch 图4对比:一个典型星型模型与其对应的无连接雪花模型 MapReduce框架下也可以获得接近甚至超越关系 数据库的性能其关键在于如何有效地结合关系数8研究展望 据库和 MapReduce两种技术仅仅停留于表层的移 植和集成是难以从根本上解决大数据分析问题的 当前3个方向的研究都不能完美地解决大数据 我们在文献41的研究中也展示了如何基于这种新分析问题,也就意味着每个方向都有极具挑战性的 的数据组织方式来实现复杂分析操作——百分位数工作等待着我们 的高效计算问题 对并行数据库来说,其扩展性近年虽有较大改 LineardB和 Dum bo虽然基本可以达到预期善(如 Greenplum和 Aster dat a都是面向PB级数 的设计目标,但两者都需要对数据进行预处理,其据规模设计开发的),但距离大数据的分析需求仍 预处理代价是普通加载时间的7倍左右.因此其有较大差距.因此,如何改善并行数据库的扩展能 应对变化的能力还较弱,这是我们未来的工作内力是一项非常有挑战的工作,该项研究将同时涉 容之94-2012 China academic Journal electronic publ及数据致性协议容错性性能等数据库颔域的

图 4 对比: 一个典型星型模型与其对应的无连接雪花模型 MapReduce框架下也可以获得接近甚至超越关系 数据库的性能, 其关键在于如何有效地结合关系数 据库和 MapReduce 两种技术. 仅仅停留于表层的移 植和集成是难以从根本上解决大数据分析问题的. 我们在文献[ 41] 的研究中也展示了如何基于这种新 的数据组织方式来实现复杂分析操作) )) 百分位数 的高效计算问题. LinearDB 和 Dumbo 虽然基本可以达到预期 的设计目标, 但两者都需要对数据进行预处理, 其 预处理代价是普通加载时间的 7 倍左右. 因此其 应对变化的能力还较弱, 这是我们未来的工作内 容之一. 8 研究展望 当前 3 个方向的研究都不能完美地解决大数据 分析问题, 也就意味着每个方向都有极具挑战性的 工作等待着我们. 对并行数据库来说, 其扩展性近年虽有较大改 善( 如 Greenplum 和 Aster Data 都是面向 PB 级数 据规模设计开发的) , 但距离大数据的分析需求仍 有较大差距. 因此, 如何改善并行数据库的扩展能 力是一项非常有挑战的工作, 该项研究将同时涉 及数据一致性协议、容错性、性能等数据库领域的 10 期 王 珊等: 架构大数据: 挑战、现状与展望 1749

1750 计算机学报 011年 Internal Data Transfer Relational Function 的,混合式OLAP( HOLAP)应该是 M apReduce平 一 Remote Data Transfer Hadoop Function 台的优选OLAP实现方案.具体研究如:①基于 M apReduce框架的高效Cube计算算法;②物化视 Relational Data Store Command Transfer 图的选择问题,即物化哪些数据;③不同分析操作 sQI 的物化手段(比如预测分析操作的物化)及如何基于 Maste 物化的数据进行复杂分析操作(如数据访问路径的 选择问题) (2)各种分析操作的并行化实现.大数据分析 Job Tracker 需要高效的复杂统计分析功能的支持.IBM将开源 统计分析软件R集成进 H ado op平台,增强了 H ado op的统计分析功能但更具挑战性的问题是, 如何基于 MapReduce框架设计可并行化的、高效的 分析算法.尤其需要强调的是,鉴于移动数据的巨大 代价,这些算法应基于移动计算的方式来实现 (3)查询共享. MapReduce采用步步物化的处 stRack 理方式,导致其ⅣO代价及网络传输代价较高 ask Tracker 种有效的降低该代价的方式是在多个查询间共享物 化的中间结果,甚至原始数据,以分摊代价并避免重 复计算.因此如何在多查询间共享中间结果将是 图5 Dumbo架构(深灰色部分是新增模块 项非常有实际应用价值的研究. 剩余部分是 Hadoop自带模块) 用户接口.如何较好地实现数据分析的展 示和操作,尤其是复杂分析操作的直观展示 诸多方面 混合式架构方案可以复用已有成果,开发量较 5) H ado op可靠性研究当前 H adoo p采用主 小但只是简单的功能集成似乎并不能有效解决大从结构由此决定了主节点一旦失效,将会出现整个 系统失效的局面因此,如何在不影响 Hadoop现有 数据的分析问题,因此该方向还需要更加深入的研 实现的前提下,提高主节点的可靠性,将是一项切实 究工作,比如从数据模型及查询处理模式上进行研的研究 究,使两者能较自然地结合起来,这将是一项非常有 (6)数据压缩. MapReduce的执行模型决定了 意义的工作中国人民大学的Dumb3n系统即是其性能取决于O和网络传输代价.文前川在比 在深层结合方向上努力的一个例子 较并行数据库和 MapReduce基于压缩数据的性能 相比于前两者, M apReduce的性能优化进展迅时,发现压缩技术并没有改善Hadp的性能但 速,其性能正逐步逼近关系数据库.该方向的研究又 实际情况是,压缩不仅可以节省空间,节省IO及 分为两个方向理论界侧重于利用关系数据库技术网络带宽,还可以利用当前CPU的多核并行计算 及理论改善 MapReduce的性能;工业界侧重于基于能力,平衡vo和CPU的处理能力,从而提高性 MapReduce平台开发高效的应用软件.针对数据仓能比如并行数据库利用数据压缩后,性能往往可以 库领域我们认为如下几个研究方向比较重要,且目大幅提升此后,文献[2526]的研究成功地利用压 前研究还较少涉及: 缩技术提升了 Hadoop的性能但这些研究都基于 )多维数据的预计算. M ap Reduce更多针对各自的存储模型,而非 Hadoop的默认存储模式(行 的是一次性分析操作大数据上的分析操作虽然难存模型).因此, M apReduce上的压缩是一个尚待研 以预测,但传统的分析如基于报表和多维数据的分究的重要问题 析仍占多数因此, M maPreduce平台也可以利用预 7)多维索引研究,如何基于 Mapreduce框架 计算等手段加快数据分析的速度基于存储空间的实现多维索引加快多维数据的检索速度 考虑(可以想象,在爆炸数据之上计算数据立方体需 要付出贵的存储窑间代价: MOLAP是不豆取 ublishing②:周本知 rights reserved.hup/ vww. cnkinet

图 5 Dumbo 架构( 深灰色部分是新增模块, 剩余部分是 Hadoo p 自带模块) 诸多方面. 混合式架构方案可以复用已有成果, 开发量较 小. 但只是简单的功能集成似乎并不能有效解决大 数据的分析问题, 因此该方向还需要更加深入的研 究工作, 比如从数据模型及查询处理模式上进行研 究, 使两者能较自然地结合起来, 这将是一项非常有 意义的工作. 中国人民大学的 Dumbo [ 37] 系统即是 在深层结合方向上努力的一个例子. 相比于前两者, M apReduce 的性能优化进展迅 速, 其性能正逐步逼近关系数据库. 该方向的研究又 分为两个方向: 理论界侧重于利用关系数据库技术 及理论改善 MapReduce 的性能; 工业界侧重于基于 MapReduce 平台开发高效的应用软件. 针对数据仓 库领域, 我们认为如下几个研究方向比较重要, 且目 前研究还较少涉及: ( 1) 多维数据的预计算. M apReduce 更多针对 的是一次性分析操作. 大数据上的分析操作虽然难 以预测, 但传统的分析, 如基于报表和多维数据的分 析仍占多数. 因此, M apReduce 平台也可以利用预 计算等手段加快数据分析的速度. 基于存储空间的 考虑( 可以想象, 在爆炸数据之上计算数据立方体需 要付出昂贵的存储空间代价) , MOLAP 是不可取 的, 混合式 OLAP( HOLAP) 应该是 M apReduce 平 台的优选 OLAP 实现方案. 具体研究如: ① 基于 M apReduce 框架的高效 Cube 计算算法; ②物化视 图的选择问题, 即物化哪些数据; ③ 不同分析操作 的物化手段( 比如预测分析操作的物化) 及如何基于 物化的数据进行复杂分析操作( 如数据访问路径的 选择问题) . ( 2) 各种分析操作的并行化实现. 大数据分析 需要高效的复杂统计分析功能的支持. IBM 将开源 统计分析软件 R 集成进 Hado op 平台[ 42] , 增强了 Hado op 的统计分析功能. 但更具挑战性的问题是, 如何基于 MapReduce 框架设计可并行化的、高效的 分析算法. 尤其需要强调的是, 鉴于移动数据的巨大 代价, 这些算法应基于移动计算的方式来实现. ( 3) 查询共享. M apReduce 采用步步物化的处 理方式, 导致其 I/ O 代价及网络传输代价较高. 一 种有效的降低该代价的方式是在多个查询间共享物 化的中间结果, 甚至原始数据, 以分摊代价并避免重 复计算. 因此如何在多查询间共享中间结果将是一 项非常有实际应用价值的研究. ( 4) 用户接口. 如何较好地实现数据分析的展 示和操作, 尤其是复杂分析操作的直观展示. ( 5) Hado op 可靠性研究. 当前 Hadoo p 采用主 从结构, 由此决定了主节点一旦失效, 将会出现整个 系统失效的局面. 因此, 如何在不影响 Hadoop 现有 实现的前提下, 提高主节点的可靠性, 将是一项切实 的研究. ( 6) 数据压缩. M apReduce 的执行模型决定了 其性能取决于 I/ O 和网络传输代价. 文献[ 11] 在比 较并行数据库和 M apReduce 基于压缩数据的性能 时, 发现压缩技术并没有改善 Hado op 的性能①. 但 实际情况是, 压缩不仅可以节省空间, 节省 I/ O 及 网络带宽, 还可以利用当前 CPU 的多核并行计算 能力, 平衡 I/ O 和 CPU 的处理能力, 从而提高性 能. 比如并行数据库利用数据压缩后, 性能往往可以 大幅提升. 此后, 文献[ 25-26] 的研究成功地利用压 缩技术提升了 Hadoop 的性能. 但这些研究都基于 各自的存储模型, 而非 Hadoop 的默认存储模式( 行 存模型) . 因此, M apReduce 上的压缩是一个尚待研 究的重要问题. ( 7) 多维索引研究. 如何基于 MapReduce 框架 实现多维索引, 加快多维数据的检索速度. 1750 计 算 机 学 报 2011 年 ① 原因未知