greenplum presto impala选型与测评

数仓框架：

• 商业系统

• InfoBright
• Greenplum（已开源）、HP Vertica、TeraData、Palo、ExaData、RedShift、BigQuery（Dremel）

• 开源实现

• Impala、Presto、Spark SQL、Drill、Hawq
• Druid、Pinot
• Kylin

大体分为三类：

1.基于hbase预聚合的，比如Opentsdb,Kylin,Druid等,需要指定预聚合的指标，在数据接入的时候根据指定的指标进行聚合运算，适合相对固定的业务报表类需求，只需要统计少量维度即可满足业务报表需求

2.基于Parquet列式存储的，比如Presto, Drill，Impala等，基本是完全基于内存的并行计算，Parquet系能降低存储空间，提高IO效率，以离线处理为主，很难提高数据写的实时性，超大表的join支持可能不够好。spark sql也算类似，但它在内存不足时可以spill disk来支持超大数据查询和join

3.基于lucene外部索引的，比如ElasticSearch和Solr,能够满足的的查询场景远多于传统的数据库存储，但对于日志、行为类时序数据，所有的搜索请求都也必须搜索所有的分片，另外，对于聚合分析场景的支持也是软肋

开源大数据查询分析引擎现状2015-06-03 14:39:42 | 编辑：hely | 查看：6758 | 评论：0

大数据查询分析是云计算中核心问题之一，自从Google在2006年之前的几篇论文奠定云计算领域基础，尤其是GFS、Map-Reduce、 Bigtable被称为云计算底层技术三大基石。

文|叶蓬

引言

大数据查询分析是云计算中核心问题之一，自从Google在2006年之前的几篇论文奠定云计算领域基础，尤其是GFS、Map-Reduce、 Bigtable被称为云计算底层技术三大基石。GFS、Map-Reduce技术直接支持了Apache Hadoop项目的诞生。Bigtable和Amazon Dynamo直接催生了NoSQL这个崭新的数据库领域，撼动了RDBMS在商用数据库和数据仓库方面几十年的统治性地位。FaceBook的Hive项目是建立在Hadoop上的数据仓库基础构架，提供了一系列用于存储、查询和分析大规模数据的工具。当我们还浸淫在GFS、Map-Reduce、 Bigtable等Google技术中，并进行理解、掌握、模仿时，Google在2009年之后，连续推出多项新技术，包括：Dremel、 Pregel、Percolator、Spanner和F1。其中，Dremel促使了实时计算系统的兴起，Pregel开辟了图数据计算这个新方向，Percolator使分布式增量索引更新成为文本检索领域的新标准，Spanner和F1向我们展现了跨数据中心数据库的可能。在Google的第二波技术浪潮中，基于Hive和Dremel，新兴的大数据公司Cloudera开源了大数据查询分析引擎Impala，Hortonworks开源了 Stinger，Fackbook开源了Presto。类似Pregel，UC Berkeley AMPLAB实验室开发了Spark图计算框架，并以Spark为核心开源了大数据查询分析引擎Shark。由于某电信运营商项目中大数据查询引擎选型需求，本文将会对Hive、Impala、Shark、Stinger和Presto这五类主流的开源大数据查询分析引擎进行简要介绍以及性能比较，最后进行总结与展望。Hive、Impala、Shark、Stinger和Presto的进化图谱如图1所示。

 

 

图1. Impala、Shark、Stinger和Presto的进化图谱

当前主流引擎简介

基于Map-Reduce模式的Hadoop擅长数据批处理，不是特别符合即时查询的场景。实时查询一般使用MPP (Massively Parallel Processing)的架构，因此用户需要在Hadoop和MPP两种技术中选择。在Google的第二波技术浪潮中，一些基于Hadoop架构的快速 SQL访问技术逐步获得人们关注。现在有一种新的趋势是MPP和Hadoop相结合提供快速SQL访问框架。最近有四个很热门的开源工具出来：Impala、Shark、Stinger和Presto。这也显示了大数据领域对于Hadoop生态系统中支持实时查询的期望。总体来说，Impala、Shark、Stinger和Presto四个系统都是类SQL实时大数据查询分析引擎，但是它们的技术侧重点完全不同。而且它们也不是为了替换Hive而生，Hive在做数据仓库时是非常有价值的。这四个系统与Hive都是构建在Hadoop之上的数据查询工具，各有不同的侧重适应面，但从客户端使用来看它们与Hive有很多的共同之处，如数据表元数据、Thrift接口、ODBC/JDBC驱动、SQL语法、灵活的文件格式、存储资源池等。Hive与Impala、Shark、Stinger、Presto在Hadoop中的关系如图2所示。Hive适用于长时间的批处理查询分析，而Impala、Shark、Stinger和Presto适用于实时交互式SQL查询，它们给数据分析人员提供了快速实验、验证想法的大数据分析工具。可以先使用Hive进行数据转换处理，之后使用这四个系统中的一个在Hive处理后的结果数据集上进行快速的数据分析。下面，从问题域出发简单介绍 Hive、Impala、Shark、Stinger和Presto：

1) Hive，披着SQL外衣的Map-Reduce。Hive是为方便用户使用Map-Reduce而在外面封装了一层SQL，由于Hive采用了SQL，它的问题域比Map-Reduce更窄，因为很多问题，SQL表达不出来，比如一些数据挖掘算法，推荐算法、图像识别算法等，这些仍只能通过编写Map-Reduce完成。

2) Impala：Google Dremel的开源实现(Apache Drill类似)，因为交互式实时计算需求，Cloudera推出了Impala系统，该系统适用于交互式实时处理场景，要求最后产生的数据量一定要少。

3) Shark/Spark：为了提高Map-Reduce的计算效率，Berkeley的AMPLab实验室开发了Spark，Spark可看做基于内存的Map-Reduce实现，此外，伯克利还在Spark基础上封装了一层SQL，产生了一个新的类似Hive的系统Shark。

4) Stinger Initiative(Tez optimized Hive)：Hortonworks开源了一个DAG计算框架Tez，Tez可以理解为Google Pregel的开源实现，该框架可以像Map-Reduce一样，可以用来设计DAG应用程序，但需要注意的是，Tez只能运行在YARN上。Tez的一个重要应用是优化Hive和PIG这种典型的DAG应用场景，它通过减少数据读写IO，优化DAG流程使得Hive速度提供了很多倍。

5) Presto：FaceBook于2013年11月份开源了Presto，一个分布式SQL查询引擎，它被设计为用来专门进行高速、实时的数据分析。它支持标准的ANSI SQL，包括复杂查询、聚合(aggregation)、连接(join)和窗口函数(window functions)。Presto设计了一个简单的数据存储的抽象层，来满足在不同数据存储系统(包括HBase、HDFS、Scribe等)之上都可以使用SQL进行查询。

 

图2. Hive与Impala、Shark、Stinger、Presto在Hadoop中的关系

当前主流引擎架构

 

Hive

Hive是基于Hadoop的一个数据仓库工具，可以将结构化的数据文件映射为一张数据库表，并提供完整的SQL查询功能，可以将SQL语句转换为 Map-Reduce任务进行运行，十分适合数据仓库的统计分析。其架构如图3所示，Hadoop和Map-Reduce是Hive架构的根基。Hive 架构包括如下组件：CLI(Command Line Interface)、JDBC/ODBC、Thrift Server、Meta Store和Driver(Complier、Optimizer和Executor)。

 

 

图3. Hive架构

Impala架构

Impala是Cloudera在受到Google的Dremel启发下开发的实时交互SQL大数据查询工具，它可以看成是Google Dremel架构和MPP (Massively Parallel Processing)结构的结合体。Impala没有再使用缓慢的Hive&Map-Reduce批处理，而是通过使用与商用并行关系数据库中类似的分布式查询引擎(由Query Planner、Query Coordinator和Query Exec Engine三部分组成)，可以直接从HDFS或HBase中用SELECT、JOIN和统计函数查询数据，从而大大降低了延迟，其架构如图4所示，Impala主要由Impalad，State Store和CLI组成。Impalad与DataNode运行在同一节点上，由Impalad进程表示，它接收客户端的查询请求(接收查询请求的 Impalad为Coordinator，Coordinator通过JNI调用java前端解释SQL查询语句，生成查询计划树，再通过调度器把执行计划分发给具有相应数据的其它Impalad进行执行)，读写数据，并行执行查询，并把结果通过网络流式的传送回给Coordinator，由 Coordinator返回给客户端。同时Impalad也与State Store保持连接，用于确定哪个Impalad是健康和可以接受新的工作。Impala State Store跟踪集群中的Impalad的健康状态及位置信息，由state-stored进程表示，它通过创建多个线程来处理Impalad的注册订阅和与各Impalad保持心跳连接，各Impalad都会缓存一份State Store中的信息，当State Store离线后，因为Impalad有State Store的缓存仍然可以工作，但会因为有些Impalad失效了，而已缓存数据无法更新，导致把执行计划分配给了失效的Impalad，导致查询失败。 CLI提供给用户查询使用的命令行工具，同时Impala还提供了Hue，JDBC，ODBC，Thrift使用接口。

 

 

图4. Impala架构

Shark架构

Shark是UC Berkeley AMPLAB开源的一款数据仓库产品，它完全兼容Hive的HQL语法，但与Hive不同的是，Hive的计算框架采用Map-Reduce，而 Shark采用Spark。所以，Hive是SQL on Map-Reduce，而Shark是Hive on Spark。其架构如图4所示，为了最大程度的保持和Hive的兼容性，Shark复用了Hive的大部分组件，如下所示：

1) SQL Parser&Plan generation: Shark完全兼容Hive的HQL语法，而且Shark使用了Hive的API来实现query Parsing和 query Plan generation，仅仅最后的Physical Plan execution阶段用Spark代替Hadoop Map-Reduce;

2) metastore：Shark采用和Hive一样的meta信息，Hive里创建的表用Shark可无缝访问;

3) SerDe: Shark的序列化机制以及数据类型与Hive完全一致;

4) UDF: Shark可重用Hive里的所有UDF。通过配置Shark参数，Shark可以自动在内存中缓存特定的RDD(Resilient Distributed Dataset)，实现数据重用，进而加快特定数据集的检索。同时，Shark通过UDF用户自定义函数实现特定的数据分析学习算法，使得SQL数据查询和运算分析能结合在一起，最大化RDD的重复使用;

5) Driver：Shark在Hive的CliDriver基础上进行了一个封装，生成一个SharkCliDriver，这是shark命令的入口;

6) ThriftServer：Shark在Hive的ThriftServer(支持JDBC/ODBC)基础上，做了一个封装，生成了一个SharkServer，也提供JDBC/ODBC服务。

 

 

图5. Shark架构

Spark是UC Berkeley AMP lab所开源的类Hadoop Map-Reduce的通用的并行计算框架，Spark基于Map-Reduce算法实现的分布式计算，拥有Hadoop Map-Reduce所具有的优点;但不同于Map-Reduce的是Job中间输出和结果可以保存在内存中，从而不再需要读写HDFS，因此Spark 能更好地适用于数据挖掘与机器学习等需要迭代的Map-Reduce的算法。其架构如图6所示：

 

 

图6. Spark架构

与Hadoop的对比，Spark的中间数据放到内存中，对于迭代运算效率更高，因此Spark适用于需要多次操作特定数据集的应用场合。需要反复操作的次数越多，所需读取的数据量越大，受益越大，数据量小但是计算密集度较大的场合，受益就相对较小。Spark比Hadoop更通用，Spark提供的数据集操作类型有很多种(map, filter, flatMap, sample, groupByKey, reduceByKey, union, join, cogroup, mapValues, sort，partionBy等)，而Hadoop只提供了Map和Reduce两种操作。Spark可以直接对HDFS进行数据的读写，同样支持 Spark on YARN。Spark可以与Map-Reduce运行于同集群中，共享存储资源与计算，数据仓库Shark实现上借用Hive，几乎与Hive完全兼容。

Stinger架构

Stinger是Hortonworks开源的一个实时类SQL即时查询系统，声称可以提升较Hive 100倍的速度。与Hive不同的是，Stinger采用Tez。所以，Hive是SQL on Map-Reduce，而Stinger是Hive on Tez。Tez的一个重要作用是优化Hive和PIG这种典型的DAG应用场景，它通过减少数据读写IO，优化DAG流程使得Hive速度提供了很多倍。其架构如图7所示， Stinger是在Hive的现有基础上加了一个优化层Tez(此框架是基于Yarn)，所有的查询和统计都要经过它的优化层来处理，以减少不必要的工作以及资源开销。虽然Stinger也对Hive进行了较多的优化与加强，Stinger总体性能还是依赖其子系统Tez的表现。而Tez是 Hortonworks开源的一个DAG计算框架，Tez可以理解为Google Pregel的开源实现，该框架可以像Map-Reduce一样，用来设计DAG应用程序，但需要注意的是，Tez只能运行在YARN上。

 

 

图7. Stinger架构

Presto架构

2013年11月Facebook开源了一个分布式SQL查询引擎Presto，它被设计为用来专门进行高速、实时的数据分析。它支持标准的 ANSI SQL子集，包括复杂查询、聚合、连接和窗口函数。其简化的架构如图8所示，客户端将SQL查询发送到Presto的协调器。协调器会进行语法检查、分析和规划查询计划。调度器将执行的管道组合在一起，将任务分配给那些里数据最近的节点，然后监控执行过程。客户端从输出段中将数据取出，这些数据是从更底层的处理段中依次取出的。Presto的运行模型与Hive有着本质的区别。Hive将查询翻译成多阶段的Map-Reduce任务，一个接着一个地运行。每一个任务从磁盘上读取输入数据并且将中间结果输出到磁盘上。然而Presto引擎没有使用Map-Reduce。它使用了一个定制的查询执行引擎和响应操作符来支持SQL的语法。除了改进的调度算法之外，所有的数据处理都是在内存中进行的。不同的处理端通过网络组成处理的流水线。这样会避免不必要的磁盘读写和额外的延迟。这种流水线式的执行模型会在同一时间运行多个数据处理段，一旦数据可用的时候就会将数据从一个处理段传入到下一个处理段。这样的方式会大大的减少各种查询的端到端响应时间。同时，Presto设计了一个简单的数据存储抽象层，来满足在不同数据存储系统之上都可以使用SQL进行查询。存储连接器目前支持除Hive/HDFS外，还支持HBase、Scribe和定制开发的系统。

 

 

图8. Presto架构

性能评测总结

 

通过对Hive、Impala、Shark、Stinger和Presto的评测和分析，总结如下：

1) 列存储一般对查询性能提升明显，尤其是大表是一个包含很多列的表。例如，从Stinger(Hive 0.11 with ORCFile)VS Hive，以及Impala的Parquet VS Text file;

2) 绕开MR计算模型，省去中间结果的持久化和MR任务调度的延迟，会带来性能提升。例如，Impala，Shark，Presto要好于Hive和Stinger，但这种优势随着数据量增加和查询变复杂而减弱;

3) 使用MPP数据库技术对连接查询有帮助。例如，Impala在两表，多表连接查询中优势明显;

4) 充分利用缓存的系统在内存充足的情况下性能优势明显。例如，Shark，Impala在小数据量时性能优势明显;内存不足时性能下降严重，Shark会出现很多问题;

5) 数据倾斜会严重影响一些系统的性能。例如，Hive、Stinger、Shark对数据倾斜比较敏感，容易造成倾斜;Impala受这方面的影响似乎不大;

对于Hive、Impala、Shark、Stinger和Presto这五类开源的分析引擎，在大多数情况下，Imapla的综合性能是最稳定的，时间性能也是最好的，而且其安装配置过程也相对容易。其他分别为Presto、Shark、Stinger和Hive。在内存足够和非Join操作情况下，Shark的性能是最好的。

总结与展望

对大数据分析的项目来说，技术往往不是最关键的，关键在于谁的生态系统更强，技术上一时的领先并不足以保证项目的最终成功。对于Hive、 Impala、Shark、Stinger和Presto来讲，最后哪一款产品会成为事实上的标准还很难说，但我们唯一可以确定并坚信的一点是，大数据分析将随着新技术的不断推陈出新而不断普及开来，这对用户永远都是一件幸事。举个例子，如果读者注意过下一代Hadoop(YARN)的发展的话就会发现，其实YARN已经支持Map-Reduce之外的计算范式(例如Shark，Impala等)，因此将来Hadoop将可能作为一个兼容并包的大平

greenplum安装配置：

http://www.cnblogs.com/zzjhn/p/5912386.html

http://www.cnblogs.com/liuyungao/p/5689588.html

https://blog.csdn.net/u013181216/article/details/72605362

https://blog.csdn.net/gnail_oug/article/details/46945283

Greenplum入门——基础知识、安装、常用函数
greenplum数据库学习笔记
Greenplum详解
详解开源大数据引擎Greenplum的架构和技术特点
开源大数据引擎：Greenplum 数据库架构分析
Greenplum优化--数据库配置篇
Greenplum优化--SQL调优篇
聊聊Greenplum的那些事
Greenplum概述及架构

impala安装配置：

http://lxw1234.com/archives/2017/06/862.htm

presto安装配置：

http://lxw1234.com/archives/2017/09/879.htm

Presto、Impala性能比较

2018年01月22日 01:32:09

阅读数：4347

下面是Presto、Impala这两种典型的内存数据库的简单测试比较，当然这种内存数据库类似的还有spark sql,这种数据库在大数据量，多表关联查询时，会展现出自己的优势，下面是一组impala和presto的性能对比图：

 

环境准备：1台32G内存、2台16G内存，没有完全把内存配置饱和

测试数据：hive中3张2000W数据量的表

集群：impala和presro部署在3台机器上

 

presto版本：presto-server-0.191 (presto安装：http://blog.csdn.net/u012551524/article/details/79013194)

impala版本：2.8.0-cdh5.11.0

 

1、单表的聚合操作

 

Presto：count

 

 

1s(presto目前只精确到整数，所以小于1s也是显示1s)

 

 

Impala：count

 

0.24s

 

 

Presto：count、distinct

 

取了3次，分别是：4、3、3 （s）

 

 

Impala：count、distinct

 

取了3次：0.74、0.75、0.76（s）

 

 

2、单值查询

 

Presto :查询一个ID的记录

3次：6、5、6（s）

 

 

Impala:

 

3次都在1.7s左右

 

 

3、两表关联（2张2000W的表做join）

Presto:

 

3次结果：9、11、9

 

 

Impala：

 

3次结果在7s左右

 

 

4、3表关联（3张2000W的表做join）

Presto:

 

4次结果：13、11、15、12（s)

 

 

Impala:

 

 

3次结果在8.9s左右

 

 

总结：这是一些场景下的查询效率的比较，数据量不是很大，但是能看出一些问题，他们的共同点就是吃内存，当然在内存充足的情况下，并且有规模适当的集群，性能应该会更可观，从上图可以看出Impala性能稍领先于presto,但是presto在数据源支持上非常丰富，包括hive、图数据库、传统关系型数据库、Redis等

 

缺点：这两种对hbase支持的都不好，presto 不支持，但是对hdfs、hive兼容性很好，其实这也是顺理成章的，所以数据源的处理很重要，针对hbase的二级索引查询可以用phoenix，效果也不错

 

作者：Greg Rahn和Mostafa Mokhtar

与传统的分析数据库(Greenplum)相比，未经修改的基于TPC-DS的性能基准测试表现出了Impala的领导地位，特别是对于多用户并发工作负载而言。此外，基准测试还进一步证明了分析数据库与Hive LLAP、Spark SQL和Presto等SQL-on-Hadoop引擎之间存在的显著性能差距。

过去一年是Apache Impala(正在孵化中)发展变化最大的一年。Impala团队不仅继续努力不断扩大其规模和稳定性，而且还推出了一系列的关键功能，进一步巩固了Impala作为高性能商务智能(BI)和SQL分析的开放标准地位。对于云计算和混合部署而言，Impala现在可以提供云端-本地部署弹性、灵活性，以及直接从Amazon S3对象存储中(以及为未来一年制定的其他对象存储)读取/写入的能力。随着Apache Kudu的GA，用户现在可以使用Impala对接收到或更新的数据立即进行高性能分析。另外，也很容易将现有的商务智能(BI)工作负载从传统分析数据库或数据仓库迁移至由Impala构建的Cloudera分析数据库中，同时可以使用Navigator Optimizer优化其性能。而且如同以往一样，对于更大的并发性工作负载的性能改进仍然是全年工作的重中之重。

除了这些性能改进之外，随着越来越多的企业机构(例如纽约证券交易所(NYSE)和奎斯特诊断公司(Quest Diagnostics))已经注意到Cloudera现代分析数据库(而不是传统分析数据库)的灵活性、可扩展性和支持SQL及非SQL工作负载(例如数据科学、机器学习和操作性工作负载)的开放式架构，Impala的采用率也在不断增长。

对于该基准测试而言，我们使用未经修改的多用户TPC-DS查询对具有Impala的Cloudera现代分析数据库与传统分析数据库(Greenplum)进行了性能比较。我们还研究了分析数据库与SQL-on-Hadoop引擎，例如：Hive LLAP、Spark SQL和Presto的对比。总的来说，我们发现：

● Impala相对于传统分析数据库而言性能更为先进，包括超过8倍的高并发工作负载性能。

● 分析数据库和其他SQL-on-Hadoop引擎之间存在显著的性能差异，使用Impala可以使多用户工作负载的性能提高近22倍。

● 其他SQL-on-Hadoop引擎也无法完成大规模基准测试来与分析数据库进行比较，因此需要一个简化的、规模较小的基准测试(Hive甚至还需要修改，Presto无法完成多用户测试)。

比较集分析数据库(采用10TB和1TB级别的数据进行测试，未经修改的查询)。● Impala 2.8 from CDH 5.10;

● Greenplum Database 4.3.9.1。

附加的SQL-on-Hadoop引擎(采用1TB级别的数据进行测试，并对Hive进行了一些查询修改)。

● Spark SQL 2.1;

● Presto 0.160;

● Hive 2.1 with LLAP from HDP 2.5。

配置每一个集群由七个工作节点组成，每个节点采用以下配置：● CPU：2 块E5-2698 v4 @ 2.20GHz;

● 存储器：8 块2TB硬盘;

● 内存：256GB内存。

我们配置了三个由相同硬件组成的集群，其中一个用于Impala、Spark和Presto(负责运行CDH)，另一个用于Greenplum，还有一个用于具有LLAP(负责运行HDP)的Hive。每个集群都装载了相同的TPC-DS数据：针对Impala和Spark的Parquet/Snappy，以及针对Hive和Presto的ORCFile/Zlib，而Greenplum使用内部的柱状格式与QuickLZ压缩文件。

查询工作负载：● 数据：TPC-DS 10TB和1TB(比例系数);

● 查询：TPC-DS v2.4查询模板(未经修改的TPC-DS)。

我们运行了77个查询，所有引擎的运行都具有语言支持，无需修改TPC-DS规范(Hive除外)。1其中22个已排除的查询都使用以下几个不常见的SQL功能：

● 使用ROLLUP进行的11个查询(TPC-DS允许的变体在本测试中未使用);

● 3个INTERSECT或EXCEPT查询;

● 8个具有高级子查询位置的查询(例如HAVING子句中的子查询等)。

由于Hive对子查询位置的更大限制，我们被迫进行了一些修改以创建语义上等同的查询。我们针对Hive运行了这些经过修改的查询。

虽然Greenplum、Presto和Spark SQL也声称支持所有99个未经修改的查询，但是即使没有并发执行，Spark SQL和Presto也无法成功完成10TB级别的99个查询。Greenplum随着多用户并发性的增加而出现越来越多的查询失败(详见下文)。

分析数据库基准测试结果10 TB级别上Impala与Greenplum的比较我们使用常见的77个未修改的TPC-DS查询在10TB级别数据下对Impala和Greenplum进行了测试。在单用户测试和更实际的多用户测试集上比较了两个、四个和八个并发流。总结如下：● 总体来说，Impala在单用户和多用户并发测试方面优于Greenplum。

● 相比Greenplum而言，Impala 线性扩展表现更优异，随着并发度增加，Impala与Greenplum的性能比率从2倍上升到了8.3倍，，同时保持了更高的成功率。

在单用户测试中，当比较查询中的几何平均值时，Impala的性能是Greenplum的2.8倍;完成查询流的总时间是Greenplum的1.8倍：

对于多用户吞吐量比较，我们使用TPC-DS dsqgen工具运行同一组77个未修改的查询来生成并发查询流。每个查询流由随机排序的77个通用查询组成，并且每个查询流使用不同的查询替换值。我们运行了多个测试，增加了超过系统饱和点的查询流数量，并且测量了各个并发级别的所有后续查询的吞吐量。

如下图所示，与Greenplum相比，Impala的性能指标随着并发速度从2个查询流2倍的速度提升加速到8个查询流8.3倍的速度提升。

鉴于集群的规模与数据集大小和并发性相比较而言较小，对于Impala和Greenplum这两个系统而言，预期在并发性增加时会发现一些查询失败。Impala和Greenplum这两个系统在两个查询流测试中达到了100%的成功率。对于四个和八个查询流测试，Impala系统的平均成功率为97%，而Greenplum系统的成功率下降到50%。如果这些测试在大于7节点集群的集群上运行，则可以预期这两个系统的成功率都会相应提高。分析数据库与SQL-on-Hadoop引擎1TB基准测试我们已经尝试针对SQL-on-Hadoop引擎使用相同的77个查询和10TB级别基准测试，但是，Hive、Presto和Spark SQL都无法成功完成77个未修改查询中的大多数查询，甚至仅仅是单用户结果也未能成功，因此无法在10TB级上进行比较。因此，我们在1TB规模下运行了单独的比较，将分析数据库引擎与其余的SQL-on-Hadoop引擎进行比较。除了Hive之外，所有的引擎都使用相同的77个TPC-DS查询，但是需要进行一些修改，以寻找方法去绕过这些限制条件，从而解决无法解析的子查询。

通过这些简化的标准(对于其他SQL-on-Hadoop引擎来说是非常必要的)，我们再次对所有五个引擎进行了单用户测试和更为真实环境的多用户测试。测试结果汇总如下：

● 分析数据库 – Impala和Greenplum系统在各个并发级别展现出的性能都优于所有的SQL-on-Hadoop引擎。

● 随着并发性的提高，再次看到Impala在性能方面拔得头筹，是其他引擎的8.5倍 – 21.6倍。

● 在所有引擎中，Presto在单用户测试中表现出最慢的性能，甚至无法完成多用户测试。

在该单用户测试中，我们再次看到，在几何平均值方面相较而言Impala仍然保持了其性能优势，但是，Greenplum在总时间上略有下降。这两个分析数据库的性能显着优于其他引擎，与其他SQL-on-Hadoop引擎相比，Impala在几何平均值方面性能优势在3.6倍至13倍之间，在总时间方面性能优势在2.8倍-8.3倍之间。

Presto对除了过滤、分组和聚合的简单单表扫描之外的其他常见的 SQL 查询表现的很挣扎。对于非常简单的查询类型，它更符合Spark SQL的性能，但是如上所述，对于使用更多标准SQL(包括连接)的更典型的商务智能(BI)查询，是执行效果最差的SQL-on-Hadoop集群。

使用TPC-DS通过四个、八个和十六个并发流运行更具代表性的多用户比较测试，以生成与上述的10TB分析数据库比较一样的随机查询流。除Presto之外，所有引擎都能够在三个并发级别的1TB级别下完成流，而不会出现任何查询失败。即使只运行四个并发查询，Presto也可能由于内存不足错误而使大多数查询失败。

对于能够成功完成多用户并发测试的引擎，分析数据库组群和SQL-on-Hadoop组群之间的性能差异变得更加明显。Impala在每一个并发级别上都展示出了优异的吞吐量 – 不仅比Greenplum快1.3-2.8倍，与Spark SQL相比，其速度快达6.5-21.6倍，并且比Hive快8.5-19.9倍。

结论各企业机构越来越期待现代化改造其系统架构，但是不愿意牺牲重要商务智能(BI)和SQL分析所需的交互式、多用户性能。Impala作为Cloudera公司平台的一部分，能够独特地提供一个现代化分析数据库。通过设计，Impala可以灵活地支持更多种类的数据和使用案例，而无需任何前期建模工作;Impala可以有弹性地和成本高效地在公司内部部署和云端部署方式下按需进行扩展;并且，作为共享平台的一部分，这些相同的数据可用于其他团队和工作负载，而不仅仅只是SQL分析，因此可以进一步拓展其价值。此外，从上述基准测试结果可以看出，与传统分析数据库相比，Impala还提供了领先的性能。无论整体性能还是大规模运算以及不断激增的并发性工作负载能力方面，分析数据库群(Impala、Greenplum)和SQL-on-Hadoop组群(Hive，Presto，Spark)之间的差异也变得非常明显。虽然其他SQL-on-Hadoop引擎不能满足分析数据库工作负载的要求，但这并不意味着对其他工作负载没有价值。事实上，绝大多数Cloudera客户充分利用平台的开放架构，通过Hive准备数据，通过Spark建立和测试模型，通过Impala运行商务智能(BI)并提供报告，而无需在不同的孤岛中复制数据。

在接下来的一年中，我们将以Impala为核心继续推动现代化分析数据库的重大性能改进，包括增加商务智能(BI)体验的智能化和自动化，并且不断扩大云计算支持，进一步提高多租户能力和可扩展性。请点击此博客了解更多详情。

像往常一样，我们鼓励您通过基于开放式基准测试工具包运行您自己的基准测试以独立验证这些结果。

via： Cloudera中国

End.

 转载至链接:https://my.oschina.net/hblt147/blog/1843028