大数据分析技术研究报告(三-3)_大数据技术研究报告-优快云博客

作者：朱赛凡

3) 存储层

数据存储层主要包括以下几类：

一类是基于MPP数据库集群，这类系统特点是存储层与上层并型计算引擎是紧耦合，属于封闭性的系统。

二是采用分布式文件系统，例如SharK、Stinger、HIVE、Impala、Scope等。Shark、Stinger、Hive、Imapla都采用HDFS文件系统作为存储层，Scope采用微软自己开发的分布式文件系统。此类系统特点是存储层与上层计算引擎层之间是松耦合关系。

三是存储层基于单机版本关系数据库，例如CitusDB采用PostSQL数据库系统、shardquery采用Mysql数据库系统。此类系统类似于一个中间件，也可以认为上层和底层存储层属于松耦合关系。

四是可以支持各种异构的存储系统，例如Presto、Tenzing。Presto设计即支持HDFS也支持存储在Mysql中的数据，但是目前只支持HDFS;Tenzing底层支持：Google File System、MySQL、Bigtable。

不同存储系统对上层计算有一些影响，典型如Tenzing系统会利用底层存储系统的一些特性：

(1)例如如果低层是mysql数据库，则可以直接利用mysql索引来过滤

(2)如果底层是bigtable数据库，则可以直接利用bigtable 范围scan来过滤

(3)如果底层是列存储系统，则可以只扫描需要扫描的列。

(4)如果底层是列存储系统，且头文件里面有该列最大值和最小值，则可以利用该信息直接跳过某些文件的扫描。

另外需要指出的是，目前已上所有系统都有一个趋势就是采用列式存储。例如HIVE开发了行列混合的RCFILE文件格式(先按行划分，保证每行的数据不会垮机器存储，然后再按劣存储)，shark系统开发了内存中的列式存储格式，citusDB开发了专用postSQL数据库的列式存储引擎。

3 Druid等专用系统简单介绍

1) JethroData系统

JethroData的特点是hadoop+index。该系统对存储在HDFS上的结构化数据建立索引，并把索引文件也以普通文件方式存储在HDFS系统，并在查询处理时采取以下过程：

(1) 查询主节点负责分析SQL语句后，针对sql中的where条件部分，利用索引文件来得到符合where过滤条件后的rowid集合。

(2) 该rowid集合涉及各datanode节点，采用并发方式来读取数据。

(3) 所有数据汇总到查询主节点，进行汇总与计算，并将最终结果返回给客户端。

可以看出，由于该系统设计思路是希望通过索引来加速数据选择，因此只适合每次查询处理只涉及少量一部分数据。

2) Druid系统

本系统是美国metamarket公司开发的面向海量数据的实时统计分析系统，以实现针对上亿级别海量数据统计分析的延迟在1秒以内。该系统于2012年10月开源。该系统可以认为是一个分布式的内存OLAP系统。

该系统主要分析的数据为交易记录，每条交易记录包括三个部分：交易发生的时间点、多个维度属性、多个数值型度量属性。例如：

该系统设计用来可以回答以下问题“有多少个针对Justin Bieber的编辑来自San Francisco? ”、“一个月内来自Calgary的增加编辑字数的平均数是多少？”。而且要求：能够在高并发环境下，在1秒以内完成任意维度组合的统计，且保证系统高可用；还系统还要能够具备实时数据分析能力，也就是能够查询分析到最新的数据，延时时间为秒级。

为了达到上述目标，该公司先后通过测试发现关系数据库技术和NOSQL数据库都无法满足其需求。关系型数据库由于磁盘io瓶颈导致性能无法满足需求，而NOSQL数据库虽然可以采用预计算方法来达到高性能，但是预计算无法满足分析需求灵活多变。

为解决该问题，该公司自己开发DRUID系统，主要技术思路如下：

(1)将原始数据(alpha数据)进行一定粒度合并，合并成beta数据。

(2)将beta数据全部放入内存，并通过分布式内存方式解决单台服务器内存

上限问题。

(3) 针对纬度属性建立索引，以加速数据的选取。

(4) 采用分布式方式进行并行统计，为了保证分布式统计高效，该系统不支持join，而且对聚合计算不支持中位数等无法分布计算的聚合计算函数。

(5) 利用数据复制解决系统高可靠性问题。

4 本章总结

1) MPP并行数据库得益于流水线的执行以及基于统计优化等方面，使得MPP并行数据库的执行效率是最高的。但缺点包括：

n 数据导入时间长，导入时要做各种预处理，例如一些统计信息；

n 执行引擎和存储紧耦合导致数据难以被其他分析引擎进行分析；

n 基于树型结构执行计划，导致MPP并行数据库表达能力有限，更适合做统计与查询，而不适合数据分析处理；

n 容错性差，特别是一个任务涉及数据量越大，该缺陷越明显。

2)HIVE、Tenzing、Shark、SCOPE、Stinger等系统可以认为基本属于同一类系统。这类系统共同特点是：”通用并行计算引擎框架+SQL解析层”。并且可以将HIVE、Tenzing看成是基于第一代系统，而Shark、Scope、Stinger是第二代系统。这一类系统特点如下：

n 存储层、执行引擎层、SQL解析层三者分离，可以方便替换执行引擎，对使用者而言，同一份数据可以采用不同并行执行引擎来分析。

n 在执行效率方面，由于存储和上层分离因此一半只能具备逻辑优化能力，另外由于Tree结构执行计划更容易采用流水线执行方式，因此这类系统执行效率总体来讲不如MPP关系数据库，它们之间排序是MPP数据库 > 第二代系统 > 第一代系统。

n 在执行效率方面，另外一点是这类系统一般内置对索引的支持不是太好或者不支持。

n 在大规模计算容错方面，这类系统要优于MPP关系数据库。

3)Impala、Dremel等可以认为属于同一类系统，此类系统介于前两者系统之间。这类系统特点是：

n 和MPP数据库类似，基于Tree结构执行计划，专注于查询统计，因此效率高于第二类系统，但是可能和第二类系统的第二代相当。

n 与MPP数据库不同的是这类系统只是一个引擎，与存储系统松耦合。也就是SQL解析层与执行层紧偶合，然后和存储层松藕合。

n 只适合做中间结果越来越小查询分析，中间结果都放内存，对内存要求较高，例如无法实现大表之间的join。

因此，在大型互联网企业中，数据量太大，就会出现所谓“高价值、低密度”情况，反映到数据处理上，互联网企业不会长期存储原始数据，而是会把原始数据先经过一部分预处理，经过部分提炼后，把提炼后数据进行长期存储和分析。也就是如下流程:

例如淘宝，把每天数据直接写入Hadoop平台，然后通过每天运行相对固定mapreduce作业来做ETL，然后在计算结果基础上为提供各种分析功能。其中海量原始数据经过固定ETL后被删除，由于只使用一次，因此没有必要花很大精力把这些数据整理成适合分析与挖掘格式。例如在这种场景下，索引也没有太大的价值，因此没有必要花费大量代价来建立索引。

MPP并行数据库，适合存储高密度价值数据，并且是长期存储和多次使用，所以MPP并行数据库会花大量经历在Load阶段，把数据处理成适合分析格式。

通过上述系统地介绍与比较，我们可以得出一个这样结论：在大数据领域，没有一个通用的解决方案，而需要根据具体业务场景，选择合适的技术！

4)通过上述系统研究，我们可以发现一点就是Join操作，特别是大表之间join操作是最消耗资源，也是最优化难度较高的操作，特别是在并行join的实现难度较大。例如Druid和Dremel等都基本放弃了join操作。

因此个人认为应该从业务上和从数据预处理方面，通过适当数据冗余来尽量避免在分析过程过程中执行join操作。