图1介绍了用MapReduce处理大数据集的过程。一个MapReduce操作分为两个阶段：Map阶段和Reduce阶段。

图1 MapReduce处理大数据集的过程

在映射阶段，MapReduce并行计算架构将用户的输入数据切分为M个数据段，每个数据段对应1个Map任务。每一个Map函数的输入是数据段中的键值对集合， Map函数是用户继承MapReduce并行计算架构而编写的，Map操作调用此函数，输出一组中间结果，即键值对 集合。接下来，按照中间结果集合的K2将中间结果集进行排序，生成一个新的 集合，使得对应同一个K2的所有值的数据都聚集在一起。然后，按照K2的范围将这些元组分割为R个片断，对应Reduce任务的数目。在规约阶段，每一个Reduce操作的输入是一个片断，Reduce操作调用用户定义的Reduce函数，生成用户需要的键值对进行输出。

这种简洁的并行计算模型在系统层面解决了可用性、扩展性、容错性等问题，是非关系数据管理和分析技术的典型代表。MapReduce是面向廉价计算机组成的大规模集群设计的，其非共享结构、松耦合性和较强的容错能力带来了较强的扩展能力，同时，MapReduce在工业界被广泛应用，Google、twitter、Facebook、Yahoo等厂商对其进行了深度的改进和扩展。此外，MapReduce的存储模型能够存储任意格式的数据，Map和Reduce函数可以进行各种复杂的数据处理，这也使得程序员的负担加重，在对上层业务的开发效率上不如SQL简单。在相同的硬件条件下，对于有具体条件的查询来说，并行数据库的性能是远远超过MapReduce的，但是对于在大数据上的复杂统计业务来说，MapReduce在速度上会占有一定优势，MapReduce是为非结构化大数据的复杂处理而设计的，这些业务具有一次性处理的特点，此外由于采取了全数据扫描的模式以及对中间结果逐步汇总的策略，使其在拥有良好扩展能力和容错能力的同时也导致了较高的磁盘和网络I/O的负载以及较高的数据解析代价。

并行数据库技术

在上世纪80年代，数据库流行的同时并行数据库也开始起源，早期并行数据库（例如：Gamma和Grace）的基础架构被沿用至今，当前的并行数据库主要有Oracle的Exdata、EMC的Greenplum、Teradata和，这些数据库都支持标准SQL。并行数据库一般可以分为shared-nothing和shared-disk两种存储架构，如图2所示。这两种架构有各自的优缺点，在shared-nothing系统中，数据集被切分为多个子集，集群中每个节点分别存储。

图2 shared-nothing和shared-disk存储架构

一个子集在本地磁盘上，一般来说，shared-nothing系统可以提供很高的并行I/O和并行计算能力，但是也有多节点事务处理、数据传输以及数据倾斜等问题。在shared-disk系统中，数据被集中存储，所有的数据库节点都可以访问存储系统的任意一个磁盘，因此数据也没有必要被切分，这也避免了数据倾斜的问题，这种系统主要的缺陷在于较低的I/O带宽和扩展能力。

云计算与数据库相结合的技术

与数据库相结合的云计算技术一般指的是MapReduce技术，当前主要有Teradata公司的Aster Data[15]和耶鲁大学提出的HadoopDB。

Aster Data将MapReduce与SQL引擎相结合，针对大数据处理和分析提出了SQL/MapReduce框架，用户可以使用JAVA、C++等多种语言在Aster Data的并行框架上编写MapReduce函数，编写的函数可以作为一个子查询在SQL中使用，从而获得SQL的易用性和MapReduce的开放性。同时Aster Data能够对多结构化数据、原始数据进行处理和分析，并拥有丰富的统计软件包可以讲数据分析推向数据库内进行，提升了数据分析性能。

在HadoopDB 中,系统清晰地分成两层,上层使用 Hadoop 进行任务的分解和调度,下层用 RDBMS(Postgresql)进行数据的查询和处理，在处理查询时，执行的是SQL to mapReduce to SQL操作过程(SMS planner)。该工作的创新之处是:试图利用 Hadoop 的任务调度机制提高系统的扩展性和容错性,以解决大数据分析的横向扩展问题;利用 RDBMS 实现数据存储和查询处理,以解决性能问题.在其性能实验中,HadoopDB 的性能仍然落后于关系数据库系统.如何提升MapReduce的性能,已引起研究人员的高度重视,研究人员提出了MapReduce的各种优化技术,获得了重要的性能改进.Yale 大学 Abadi 领导的小组正在使用包括列存储、持续装载和分析(continuous loading and analysis)等技术,以改进 HadoopDB 的性能。

图3是HadooopDB的一个结构图，在原来的hadoop与hive的基础上，增加了一些组件：其中SMS Planner的作用是在hive解析SQL语句生成MapReduce任务树之后，对MapReduce任务树进行优化，指导hadoop去并行数据库中执行SQL。Catalog里面存储了并行数据库的一些信息。Data loader负责把原始数据加载到并行数据库中，需要完成的工作是对原始数据的划分。Database Connector用于向各个节点传递信息，包含了节点里面数据库的链接信息和需要执行的SQL语句。Paralled DataBase用于代替HDFS在各个节点上存储数据。

新一代EB级云计算数据库－－数据立方

通过对MapReduce、并行数据库和两者的混合技术研究，南京云创存储科技有限公司推出了实施云计算数据库－－数据立方，该系统通过引入索引模块、并行执行架构以及读取本地磁盘的执行方式，使查询达到了实时完成、简单易用、高可靠安全的效能，使EB级的数据能够秒级处理，极大地提高了用户执行查询操作后的使用效率，不仅在查询和检索这部分数据的时候具有非常高的性能优势，数据立方还可以支持数据仓库存储、数据深度挖掘和商业智能分析等业务。

数据立方（DataCube）的结构分为用户接口、索引、SQL解析器、作业生成器、元数据管理、并行计算架构、分布式文件系统等部分，如图4所示。用户接口主要有两个：JDBC和Shell。JDBC主要执行数据的定义操作，即建立数据库、建表、建分区，对数据库、表和分区的删改等，同时可执行数据查询的SQL语句，暂不支持单条记录的增删改；数据立方提供友好的shell交互界面，shell支持数据库、表的增删改以及数据查询的SQL语句。

数据在入库的同时与数据对应的索引也在同时建立，索引是一颗B树，数据插入到内存的同时，索引B树也在生成，当达到设置上限时，数据和索引会刷新到分布式文件系统上成为文件。数据立方的元数据存储在数据库中。其中包括，数据库的名字和属性，数据库中的表，表的名字，表的列和分区及其属性，表的属性，表的数据所在目录等等。SQL解析器接收从JDBC和SHELL传来的SQL查询语句，同时对SQL进行词法分析、语法分析、编译、优化。作业生成器根据SQL语法树生成查询作业，分析所要处理的数据表对应的索引文件的所在存储子节点位置，并将作业发送给并行计算架构。并行计算架构接收到作业生成器生成的作业，根据索引文件的位置切分查询作业形成子任务，然后将子任务发送给数据所在的存储子节点，每个节点执行这些子任务查询索引得到结果记录所在的数据文件名与偏移量，并以广播的方式发送查询子任务到数据文件所在的节点，在执行完毕后将结果返回。数据立方可以使用HDFS和cStor作为底层存储系统，cStor是一个主从结构的分布式文件系统，不仅具有HDFS的高吞吐率、高读写性能等特性，还支持HDFS所不具备的对文件修改等功能，并且支持POXIS接口。

分布式并行计算架构（DPCA）

云计算数据库——数据立方的分布式并行架构（DPCA）是典型的主从结构，主Master与从Master分别部署在HDFS的主从NameNode物理节点上，而Slave部署在DataNode物理节点上，主从Master使用Zookeeper同步，并共享系统日志，Master与Slave之间用心跳信息保持信息交换。

相对于MapReduce架构，DPCA具有实时性、计算的数据本地性以及数据平衡性。MapReduce架构的job提交过程较为复杂，客户端将job提交到JobTracker有较长的延迟， JobTracker将job处理为MapReduce task后，通过TaskTracker的心跳信息将task任务返回给TaskTracker，此过程中也存在延迟。MapReduce架构虽然也遵循数据本地性，但仍会有很大比例的数据处理不是本地的，相对于MapReduce架构， DPCA的job提交是实时性的，在提交job之前所需程序jar包已经分发到所有计算节点，在job提交之后，master在初始化处理之后即将task直接分发到所有slave节点上在job提交后， master根据数据文件所在位置分配task，这样在每个计算节点上要处理的HDFS上的数据块就在本地，这样避免了数据的移动，极大地减少了网络IO负载，缩短了计算时间，每个计算节点会根据Task中SQL解析器生成的执行计划对Task执行的结果进行分发，分发的方式有三种：分发所有中间数据到所有计算节点，分发所有中间数据到部分节点，根据数据所在位置分发。并行计算架构能够周期性地对HDFS上的数据表进行维护，保持数据表在所有的DataNode节点上所存储的数据量的平衡，减少因数据负载的不平衡而导致的计算负载的不平衡。

举一个典型的小表与大表join连接的实例，Master解析Job中的执行计划，判断小表的位置后，将Task0发送给了Slave0，指令Slave0发送小表到所有节点，而其他节点接收到的子任务是等待接受小表的数据，接收到数据后将小表与大表连接并将数据返回给Master，当所有数据返回完成则这个job完成。

分布式索引

MapReduce是对每个查询都是直接从分布式文件系统中读入原始数据文件，I/O代价远高于数据库，相对于MapReduce架构以及在其之上的SQL解析器Hive，数据立方引入了一种高效的分布式索引机制，不同于并行数据库的 shared-nothing和shared-disk架构，数据立方的数据文件与索引文件都存放在分布式文件系统之上。

图8 B树索引

数据在入库的同时B树索引在内存中同步生成，B树中的叶子节点存储的是数据文件路径与记录在文件中的偏移量，如图8所示，在B树中的叶子节点达到设置上限后，索引将被序列化到分布式文件系统之上，在根据条件进行单表查询的时，job被提交到并行计算框架，master节点首先分析该表的索引文件根据索引文件所在的节点将task发送到相应的节点，每个节点在查询本地的索引文件之后将符合条件的数据文件路径+偏移量打包成task根据数据文件位置进行再次分发，在数据文件中的记录查询出来之后将结果返回，如图8所示。

实验环境搭建在两个机架的12台物理机组成的集群上。每台物理机使用Ubuntu9.04 server系统，JDK版本为1.6.0.18,使用的Hadoop版本为2.0.0，将HDFS作为分布式存储环境。软硬件配置如表1、表2所示。

当前与数据立方类似的产品有分布式数据库和数据仓库，如：开源的HIVE、HadoopDB等，因此我们在数据入库、查询、查询的并发量以及线性扩展等多方面对数据立方、HIVE和HadoopDB做了对比实验。

数据立方能够快速进行数据入库同时实时建立索引，相对于基于传统数据库的HadoopDB来说具有天然的优势，而对于HIVE来说，虽然入库速度相差不大，但由于HIVE在数据入库的同时并没有建立索引使其在查询的过程中没有优势。

实验结果如下图所示：

单表查询实验：

数据立方的每个节点支持200个并发查询，同时每个查询均是秒级响应，HadoopDB由于是SMS的中间层，由于MapReduce架构本身的心跳机制而导致了较大的延迟，所以是很难达到秒级响应的，HIVE的任务并发数取决于MapReduce的并发任务数，所以会更低。

实验结果如图9所示：

线性扩展实验：

数据立方、HadoopDB和HIVE均支持线性扩展，而数据立方的扩展效率更高，即对系统的软硬件做扩展后，性能也能够达到类似线性的增长。

实验结果如图10所示：

意义：

Hadoop是一种流行的MapReduce计算模型的开源实现，用于大规模数据集的并行化分析处理，并行数据库是在单机数据库基础之上发展而来的数据库集群，通过研究MapReduce技术、并行数据库技术以及混合技术探讨了一系列相关的大数据处理技术，更深一步探索了基于分布式文件系统的并行计算架构和分布式海量数据实时索引机制，以此为基础并辅以其他技术形成了一个支持非结构化、结构化和半结构化数据高效存储，支持离线数据分析和在线专题应用，支持结构化数据与非结构化、半结构化数据之间的复杂计算的实时云计算数据库数据立方。

数据立方大数据一体机是一种处理海量数据的高效分布式软硬件集合的云处理平台，该平台可以从TB乃至PB级的数据中挖掘出有用的信息，并对这些海量信息进行快捷、高效的处理。平台支持100GBps以上量级的数据流实时索引，秒级响应客户请求，秒级完成数据处理、查询和分析工作。平台可以对入口数据进行实时索引，对数据进行分析、清理、分割，并将其存储在云存储系统上，不仅在入库和检索时具有非常高的性能优势,还可以支持数据深度挖掘和商业智能分析等业务。

cProc云处理平台是搭建在云存储系统上，对业务层直接提供对外开发接口和数据传输接口的分布式数据处理平台。cProc云处理平台是一种处理海量数据的并行编程模型和计算框架，用于对大规模数据集的并行计算。

云存储层包括cStor云存储和apache开源云储存系统HDFS;而在数据管理层中，包含数据立方、Hbase;数据处理层包含JobKeeper和MapReduce;最后的监控协调层则包括zookeeper和Chukwa来实现对整个系统的实时监控和数据管理。

cProc云计算平台通过把对数据集的大规模操作分发给网络上的每个节点实现数据处理,每个节点会周期性的把完成的工作和状态的更新报告回来。随着节点的增多，cProc云计算平台的处理能力将成倍数增长。cProc支持100GBps以上量级的数据流实时索引，1s内响应客户请求，秒级完成数据处理、查询和分析工作。

JobKeeper调度平台是建立于虚拟化资源层之上，统一调度，统一配置的管理平台，用于对集群中任务实时的处理调度，实时结果集的反馈，集群的负载均衡，失败调度，集中管理，集中配置的平台。用来保证整个集群的超低人员干预。同时，提供完善的集群伸缩机制为整个服务提供更高的可靠性。

应用层是一组用于管理和结果反馈的显示组件，用于显示任务的处理情况以及集群中机器的活动情况，同时其也是一个上层应用和底层服务的对接平台，是整个系统面向用户和开发人员的基础承载。

业务层是对于应用层的相关功能的业务化，数字化处理，用于将应用层的需求任务进行规则化划分，形成统一的处理化模式。

数据处理层是独立的数据处理程序，是对不同需求数据的统一处理方案，它的运行与监控的工作将由JobKeeper调度平台进行统一的配置管理。

存储层是用来存储数据存储层的处理结果集或者其它中间结果集的单元。

虚拟化资源层是将实体的机器进行虚拟化，形成更大范围的服务集群。

JobKeeper调度平台是由一组管理节点(Master Node)和一组处理节点(Task Node)组成，管理节点组是一组基于Webserver的RPC(RPC采用客户机/服务器模式。请求程序就是一个客户机，而服务提供程序就是一个服务器。首先，客户机调用进程发送一个有进程参数的调用信息到服务进程，然后等待应答信息。在服务器端，进程保持睡眠状态直到调用信息的到达为止。当一个调用信息到达，服务器获得进程参数，计算结果，发送答复信息，然后等待下一个调用信息，最后，客户端调用进程接收答复信息，获得进程结果，然后调用执行继续进行。)服务器，负责对处理节点的系统信息以及任务处理信息进行实时的跟踪和保存，对应的信息镜像存储在基于cStor或者NFS服务的存储系统上，保证每个管理节点中的镜像信息的实时同步。同时架设在管理节点上的ZooKeeper服务(ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，包含一个简单的原语集。分布式应用可以使用它来实现诸如：统一命名服务、配置管理、分布式锁服务、集群管理等功能。)用于对整个管理节点组进行统一的配置化管理。处理节点组通过RPC的远程调用获取各自节点的任务处理目标，并实时的和处理节点上的任务处理目标进行对比，控制程序的执行和结束。(注：这里的程序，可以是任何语言任何形式的独立程序，但是必须提供执行脚本，和运行参数选项)处理节点组会在一个设定的心跳间隔内主动的和管理节点组联系一次，报告节点存活状态。如果在若干个心跳间隔后管理节点组仍然没有获取到处理节点心跳报告，那么该处理节点将会被踢出处理节点组，同时该节点处理的所有处理任务也会被重新调度。随着集群处理数据量的不断增大，处理节点组提供了简单高效的自动化部署方案，当新机器加入处理集群后，会主动的与管理节点组同步心跳信息，从同一配置服务器ZooKeeper上获取相关配置信息，通过WebServer服务获取任务列表，开始执行数据处理工作。

JobKeeper调度平台提供了一套基于Web的管理化界面，可以实时的观察各个处理节点的任务运行状态，以及任务列表的分配情况，机器的负载情况等。用户在管理系统界面上可以完成所有的工作，如新任务的添加，任务的手动调度以及集群日志的查看与分析等。

使用ZooKeeper的选举机制解决MapReduce的单点故障，当JobTracker节点宕机时，能够在一台备用的JobTracker节点上启动JobTracker进程，并使用虚拟IP机制将虚拟IP指向备用JobTracker节点。在JobTracker进程启动后，ZooKeeper将未完成的MapReduce作业提交给备用JobTracker节点重新执行。