背景

  近年来，随着计算机技术的发展，各领域数据的增长越来越快。这些数据来自方方面面，从搜集天气情况的感测器，接入社交媒体网站的指令，数码图片，在线的视频资料，到网络购物的交易记录，手机的定位系统信号等等。随着数据规模的急剧膨胀，各行业累积的数据量越来越巨大，数据类型也越来越多、越来越复杂，已经超越了传统数据管理系统、处理模式的能力范围，传统的串行数据库系统已经难以适应这种飞速增长的应用需求。在这种需求的驱动下，云计算中的MapReduce[1]技术、并行数据库技术以及云计算与数据库相结合的技术应运而生。font>

  我们在大数据的背景下，对大数据处理技术进行了探讨，将其分为三类：MapReduce技术、并行数据库技术和云计算与数据库相结合的技术。通过研究这些技术的架构、适用环境，提出了一种云计算数据库--数据立方。font>

产品介绍

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

数据立方的体系架构

  数据立方（DataCube）的结构分为用户接口、索引、SQL解析器、作业生成器、元数据管理、并行计算架构、分布式文件系统等部分，如图4所示。用户接口主要有两个：JDBC和Shell。JDBC主要执行数据的定义操作，即建立数据库、建表、建分区，对数据库、表和分区的删改等，同时可执行数据查询的SQL语句，暂不支持单条记录的增删改；数据立方提供友好的shell交互界面，shell支持数据库、表的增删改以及数据查询的SQL语句。数据在入库的同时与数据对应的索引也在同时建立，索引是一颗B树，数据插入到内存的同时，索引B树也在生成，当达到设置上*，数据和索引会刷新到分布式文件系统上成为文件。数据立方的元数据存储在数据库中。其中包括，数据库的名字和属性，数据库中的表，表的名字，表的列和分区及其属性，表的属性，表的数据所在目录等等。SQL解析器接收从JDBC和SHELL传来的SQL查询语句，同时对SQL进行词法分析、语法分析、编译、优化。作业生成器根据SQL语法树生成查询作业，分析所要处理的数据表对应的索引文件的所在存储子节点位置，并将作业发送给并行计算架构。并行计算架构接收到作业生成器生成的作业，根据索引文件的位置切分查询作业形成子任务，然后将子任务发送给数据所在的存储子节点，每个节点执行这些子任务查询索引得到结果记录所在的数据文件名与偏移量，并以广播的方式发送查询子任务到数据文件所在的节点，在执行完毕后将结果返回。数据立方可以使用HDFS和cStor[19]作为底层存储系统，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连接的实例，如图7所示，Master解析Job中的执行计划，判断小表的位置后，将Task0发送给了Slave0，指令Slave0发送小表到所有节点，而其他节点接收到的子任务是等待接受小表的数据，接收到数据后将小表与大表连接并将数据返回给Master，当所有数据返回完成则这个job完成。

分布式索引

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

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

测试与评估

测试环境

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

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

数据入库测试

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

单表查询测试

  对于简单的单表查询来说，数据量较小时，HadoopDB与数据立方的查询速度都是比较快的，但在大数据量下，数据立方的高效分布式查询更有优势，而HIVE的底层是基于MapReduce，所以速度较慢。测试结果如下图所示：

多表查询测试

  在多表查询方面，在小表与小表、大表与小表之间的关联查询，数据立方和HadoopDB都是较快的，但在大表与大表之间做关联查询时，数据立方相对于HadoopDB更快，而HIVE是很慢的。测试结果如下图所示：

并发查询测试

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

线性扩展测试

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