第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 features fo r big data analytics, summarizes current main implementation platfor ms( parallel databases, 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