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