大数据分析技术研究报告(三-1)

作者：朱赛凡

 三大数据背景下数据统计分析技术介绍

随数据量变大，和事务处理不同的是，单个统计分析涉及数据量会非常大，单个统计分析任务涉及数据会分散在多台服务器上，且由于计算量大，采用单台服务器进行计算，会导致计算时间非常长，单个统计分析任务必须采用并行计算方式来加快单个统计分析任务执行速度。

1并行查询与并行计算技术介绍

在大数据背景下的数据统计分析技术门类很多，常见的有：

n  MPP并行数据库 : TeraData、GreenPlum、Vertica等。

n  基于MapReduce并行计算框架的数据仓库：

HIVE(Hadoop平台) 、Tenzing（Google公司）

n  基于Hbase的Phoenix系统

n  HadoopDB系统

n  EMC公司的hapt系统

n  MPP分布式查询引擎： Dremel、Impala、Presto、Shard query、Citusdb。

n  基于SPARK的Shark、基于Dryad的SCOPE、基于Tez的stinger。

n  基于hadoop+index的JethroData系统

n  基于内存计算的Druid系统

这些系统都解决了海量数据下的数据统计分析的问题，并且这些系统另外一个共同特点是都提供了SQL或者类SQL接口。

为了能够较好研究这些系统，我们需要对并行查询与并行计算的相关技术做一个简要的介绍。

首先所有的系统都可以分为三个层次: 语义层、并行计算引擎层、分布式存储层。语义层提供一个编程接口让用户表达所需要计算，并负责把该计算翻译成底层并行计算引擎可以执行的执行计划，并由并行计算引擎来执行，最下面一层是分布式存储层。

对于提供类SQL接口并行计算系统，语义层可以认为是SQL解析层。

1) 语义层

SQL语言是一种声名式语言，SQL只是表达了要做什么，而没有表达怎么做。为此，SQL解析层主要作用是：将用户提交的基于SQL的统计分析请求，转化为底层计算引擎层可以执行的执行计划。也就是解决“怎么做”的问题。

SQL解析层工作主要包括两个大方面:

(1) 通过语法分析技术来理解要做什么。在关系数据库中，一般会把SQL语言分析后，形成树型结构的执行计划。

(2) 在语法分析技术上，利用各种优化技术和算法，找出一种最经济物理执行计划。

优化可以分为两个方面：一是逻辑层面优化、二是物理执行层面优化。

(1) 逻辑层优化

逻辑层面个人认为主要是因为同样表达一个分析请求，有的人SQL写的好，有的人SQL写的烂，因此在逻辑层面可以通过一些等价关系代数变换，实现查询重写，将写的比较烂的sql变换为好的写法。

比较典型优化是：“把投影和过滤下沉，先执行过滤和投影操作”，减少中间结果。

(2) 物理层优化

物理层面优化是在逻辑优化后，结合实际物理执行过程，找出最优的物理执行计划。生成物理查询计划的工作包括:

ü  增加一些操作符： 包括扫描和排序等。

ü  确定各个操作符实现算法。例如扫描是全表扫描还是利用索引；Join是采用HASH连接、索引连接、合并排序等实现算法中的那一种。

ü  确定操作符之间的数据流转方法：物化还是流水线方式。

ü  采用基于代价估算方法确定最优的物理执行计划，目前代价估算主要是以估算该物理计划需要的IO量。另外对于并行数据库，则还要考虑通讯代价，即尽量减少数据在各个机器之间的传递。

     在物理层优化的代价估算过程中，代价估算需要依靠很多统计信息，如表有多大，表中相关列的值分布是什么样子等。传统数据库在数据Load过程中会事先计算好这些统计信息。并行计算中还需要考虑通讯代价。

     需要指出是，由于imapla、Presto、HIVE等系统只是一个查询引擎，它们可以直接查询以普通文件方式存储在HDFS系统上的文件，因此这些系统一般无法使用索引和各种统计信息来进行物理执行计划的优化，这些系统一般只能在逻辑层进行一些基于规则静态优化。根据SHARK论文，SHARK系统支持根据前面一些节点计算获得的信息，来动态优化后面执行计划。

 

 (3) 物化与流水线执行方法

    一条SQL语句对开发人员而言，感觉只是一次调用，但是实际上在数据库内部，一条SQL语句执行其实是有多个操作符组合而成的的树型结构计算流。如下图：

 

针对该计算流有两种执行方式：一是基于物化或者是实体化执行方式，另外一种是基于数据流的执行方式。

第一种方法的过程是： 把各个操作运算排序，并把每个操作运算的输出的中间结果存储在磁盘上，直到被另外一个操作运算所读取。

另外一种方法是同时交错进行多个运算，由一个运算产生每个元组直接传递给下一个运算，而不将中间结果存储到磁盘，也不用等到前一个运算全部运算完毕。

例如： 两个表连接后，再进行投影操作。如果采用第一种方法，则需要

把两表连接中间结果临时写入磁盘，然后再读取该结果执行投影操作。而如果采用第二种方法，则连接操作一旦产生一个元组就可以立刻送到投影操作去进行投影操作。

流水线方法可以极大避免大量的中间结果磁盘IO。因此数据库一般会采取流水线方法来执行。流水执行方法有两种模式：一种是需求驱动流水线，也就是从上层主动向下层要求元组，另外一种是生产者驱动流水线执行方式，由低层主动产生元组，由下层向上层推。

目前大部分数据库引擎采用的是需求驱动流水线，实现方式采用基于Graefe提出的迭代器模型。该模型把每个操作都表达为由三个接口： open() ,  getnext(), close()。每个操作被调用open() 进行准备工作，然后通过反复迭代被调用getnext来获取下一个元组，最后被调用close来进行清理工作。 通过构建迭代器网络，也就是迭代器之间的互相调用，就可以实现需求驱动流水线。

 当然不是任何操作都可以流水执行，流水执行条件是：操作要满足在接收输入元组时可以输出元组。例如排序操作就无法进行流水操作，在执行排序操作前都必须进行实体化。

(4) SQL解析层与并行计算引擎层

由于不同并行计算引擎层的执行计划表达不同，因此不同系统需要将SQL解析成不同的形式物理执行计划，例如：

MPP关系数据库一般是把SQL解析成树状结构的物理执行计划。

HIVE、Tezning数据库是把SQL解析成DAG结构的多个MAPREDUCE组合。

DRemel等则类似MPP关系数据库，把SQL解析成一个树状结构执行计划。

微软SCOPE则需要把类SQL解析成DAG结构的Dryad可执行的执行计划。

SHARK则需要把SQL解析成基于scala语言的DAG结构执行计划。