大数据查询Druid，Impala，Presto，SparkSQL对比

爱吃鱼的俊懒猫 2021-06-30

展开全文

一、OLAP和OLTP的区别

OLAP（On-Line Analytical Processing）联机分析处理，也称为面向交易的处理过程，其基本特征是前台接收的用户数据可以立即传送到计算中心进行处理，并在很短的时间内给出处理结果，是对用户操作快速响应的方式之一。应用在数据仓库，使用对象是决策者。OLAP系统强调的是数据分析，响应速度要求没那么高。

目前市面上主流的开源OLAP引擎包含不限于：Hive、Presto、Kylin、Impala、Sparksql、Druid、等

OLTP（On-Line Transaction Processing）联机事务处理，它使分析人员能够迅速、一致、交互地从各个方面观察信息，以达到深入理解数据的目的。它具有FASMI(Fast Analysis of Shared Multidimensional Information)，即共享多维信息的快速分析的特征。主要应用是传统关系型数据库。OLTP系统强调的是内存效率，实时性比较高。Oracle、Redis、Hbase

按照查询类型划分，OLAP一般分为即席查询和固化查询，

即席查询:通过手写sql完成一些临时的数据分析需求，这类sql形式多变、逻辑复杂，对查询时间没有严格要求
固化查询：指的是一些固化下来的取数、看数需求，通过数据产品的形式提供给用户，从而提高数据分析和运营的效率。这类的sql固定模式，对响应时间有较高要求。

按照架构实现划分，主流的OLAP引擎主要有下面三点：

MPP架构系统(Presto/Impala/SparkSQL/Drill等)。这种架构主要还是从查询引擎入手，使用分布式查询引擎，而不是使用hive+mapreduce架构，提高查询效率。
搜索引擎架构的系统(es，solr等)，在入库时将数据转换为倒排索引，采用Scatter-Gather计算模型，牺牲了灵活性换取很好的性能，在搜索类查询上能做到亚秒级响应。但是对于扫描聚合为主的查询，随着处理数据量的增加，响应时间也会退化到分钟级。
预计算系统（Druid/Kylin等）则在入库时对数据进行预聚合，进一步牺牲灵活性换取性能，以实现对超大数据集的秒级响应。

数据轨迹现有的实现方式，从业务诉求看为:每账期按照指定的查询列取数据，进行分析未结算原因，偏向固化查询的方式。但现有的实现方式为先按照查询列值查询出主表数据，再根据主表附属表的关联字段，获取查询附属表的sql，sql为动态拼接出来，这种方式更偏向于即席查询的实现。

需要从以下三个方面考虑框架选型：数据存储和构建、安装搭建、开发成本。

impala

impala是Cloudera开发开源的，Impala是Cloudera开发并开源的，能查询存储在HDFS和HBase中的数据。同Hive一样，也是一种SQL on Hadoop解决方案。但Impala抛弃了MapReduce,使用更类似于传统的MPP数据库技术来提高查询速度。

impala可以直接查询hdfs或hbase上的数据，可以与现有的存储无缝对接。
impala需要单独安装，公司内paas主推。需要与现场确认。
impala提供jdbc接口和sql执行引擎，可以与现有系统集成

Presto

presto是Facebook开源的大数据查询引擎，为了解决hive查询慢产生。使用java编写，数据全部在内存中处理。

Facebook开源的一个java写的分布式数据查询框架，原生集成了Hive、Hbase和关系型数据库，Presto背后所使用的执行模式与Hive有根本的不同，它没有使用MapReduce，大部分场景下比hive快一个数量级，其中的关键是所有的处理都在内存中完成。

原生集成了Hive、Hbase和关系型数据库。
需要与现场确认是否能提供
提供jdbc接口和sql执行引擎，可以与现有系统集成

druid

druid同kylin一样，是采用预计算的方式。主要解决的是对于大量的基于时序的数据进行聚合查询。数据可以实时摄入，进入到Druid后立即可查，同时数据是几乎是不可变。通常是基于时序的事实事件，事实发生后进入Druid，外部系统就可以对该事实进行查询。

是一个实时处理时序数据的OLAP数据库，因为它的索引首先按照时间分片，查询的时候也是按照时间线去路由索引。

需要预计算，将数据存储在druid的Segment文件中，占用一部分存储资源
需要与现场确认是否能提供
对sql支持不友好，需要用他自己的方言书写

kylin

kylin是一种OLAP数据引擎，支持大数据生态圈的数据分析业务，主要是通过预计算的方式将用户设定的多维度数据立方体(cube)缓存起来，达到快速查询的目的。应用场景应该是针对复杂sql join后的数据缓存。

核心是Cube，cube是一种预计算技术，基本思路是预先对数据作多维索引，查询时只扫描索引而不访问原始数据从而提速。

这种OLAP引擎，一般包括以下几部分：

数据构建存储：cube构建，元数据信息
sql解析执行：Query引擎(sql解释器)，routing模块(sql执行)
上层接口服务；jdbc/odbc接口，rest服务

应用思路：将hive中的数据按照查询列构建成cube，存储到hbase中，数据轨迹连接kylin的jdbc接口实现快速查询。

需要预计算，将数据构建成cube存储到hbase
需要与现场确认是否能提供
提供jdbc接口和rest服务

Spark SQL

基于spark平台上的一个olap框架，本质上也是基于DAG的MPP，基本思路是增加机器来并行计算，从而提高查询速度。

这几种框架各有优缺点，存在就是合理，如何选型个人看法如下：

从成熟度来讲：kylin>spark sql>Druid>presto

从超大数据的查询效率来看：Druid>kylin>presto>spark sql

从支持的数据源种类来讲：presto>spark sql>kylin>Druid

大数据查询目前来讲可以大体分为三类：

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

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

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

与X沟通，建议使用impala或者spark做查询，于是查询对比各种开源的OLAP引擎。

二. Hive、SparkSQL、Impala、Presto性能对比

（1）cloudera公司2014年做的性能基准对比测试，原文链接：http://blog./blog/2014/09/new-benchmarks-for-sql-on-hadoop-impala-1-4-widens-the-performance-gap/

对于单用户查询，Impala比其它方案最多快13倍，平均快6.7倍。
对于多用户查询，差距进一步拉大：Impala比其它方案最多快27.4倍，平均快18倍。

下面看看这个测试是怎么做的。
配置：
所有测试都运行在一个完全相同的21节点集群上，每个节点只配有64G内存。之所以内存不配大，就是为了消除人们对于Impala只有在非常大的内存上才有好性能的错误认识：

双物理CPU，每个12核，Intel Xeon CPU E5-2630L 0 at 2.00GHz
12个磁盘驱动器，每个磁盘932G，1个用作OS，其它用作HDFS
每节点64G内存

对比产品：

Impala 1.4.0
Hive-on-Tez 0.13
Spark SQL 1.1
Presto 0.74

查询：

21个节点上的数据量为15T
测试场景取自TPC-DS，一个开放的决策支持基准（包括交互式、报表、分析式查询）
由于除Impala外，其它引擎都没有基于成本的优化器，本测试使用的查询都使用SQL-92标准的连接
采用统一的Snappy压缩编码方式，各个引擎使用各自最优的文件格式，Impala和Spark SQL使用Parquet，Hive-on-Tez使用ORC，Presto使用RCFile。
对每种引擎多次运行和调优

结果：
单用户如下图所示。

多用户如下图所示。

查询吞吐率如下图所示。

Impala本身就是cloudera公司的主打产品，因此只听其一面之词未免有失偏颇，下面就再看一个SAS公司的测试

（2）SAS2013年做的Impala和Hive的对比测试
硬件：

Dell M1000e server rack
10 Dell M610 blades
Juniper EX4500 10 GbE switch

刀片服务器配置

Intel Xeon X5667 3.07GHz processor
Dell PERC H700 Integrated RAID controller
Disk size: 543 GB
FreeBSD iSCSI Initiator driver
HP P2000 G3 iSCSI dual controller
Memory: 94.4 GB

软件：

Linux 2.6.32
Apache Hadoop 2.0.0
Apache Hive 0.10.0
Impala 1.0
Apache MapReduce 0.20.2

数据：
数据模型如下图所示。

查询：
使用了以下5条查询语句

-- What are the most visited top-level directories on the customer support website for a given week and year?  
select top_directory, count(*) as unique_visits     
  from (select distinct visitor_id, split(requested_file, '[\\/]')[1] as top_directory  
          from page_click_flat  
         where domain_nm = 'support.sas.com'   
           and flash_enabled='1'   
           and weekofyear(detail_tm) = 48   
           and year(detail_tm) = 2012  
       ) directory_summary  
 group by top_directory  
 order by unique_visits;  
-- What are the most visited pages that are referred from a Google search for a given month?  
select domain_nm, requested_file, count(*) as unique_visitors, month  
  from (select distinct domain_nm, requested_file, visitor_id, month(detail_tm) as month  
          from page_click_flat  
         where domain_nm = 'support.sas.com'   
           and referrer_domain_nm = 'www.google.com'  
       ) visits_pp_ph_summary  
 group by domain_nm, requested_file, month  
 order by domain_nm, requested_file, unique_visitors desc, month asc;  
-- What are the most common search terms used on the customer support website for a given year?  
select query_string_txt, count(*) as count  
  from page_click_flat  
 where query_string_txt <> ''   
   and domain_nm='support.sas.com'   
   and year(detail_tm) = '2012'  
 group by query_string_txt  
 order by count desc;  
-- What is the total number of visitors per page using the Safari browser?  
select domain_nm, requested_file, count(*) as unique_visitors  
  from (select distinct domain_nm, requested_file, visitor_id  
          from page_click_flat  
         where domain_nm='support.sas.com'   
           and browser_nm like '%Safari%'   
           and weekofyear(detail_tm) = 48   
           and year(detail_tm) = 2012  
       ) uv_summary  
 group by domain_nm, requested_file  
 order by unique_visitors desc;  
-- How many visitors spend more than 10 seconds viewing each page for a given week and year?  
select domain_nm, requested_file, count(*) as unique_visits  
  from (select distinct domain_nm, requested_file, visitor_id  
          from page_click_flat  
         where domain_nm='support.sas.com'   
           and weekofyear(detail_tm) = 48   
           and year(detail_tm) = 2012   
           and seconds_spent_on_page_cnt > 10;  
       ) visits_summary  
 group by domain_nm, requested_file  
 order by unique_visits desc;

结果：
Hive与Impala查询时间对比如下图所示。

可以看到，查询1、2、4Impala比Hive快的多，而查询3、5Impala却比Hive慢很多。这个测试可能更客观一些，而且也从侧面说明了一个问题，不要轻信厂商宣传的数据，还是要根据自己的实际测试情况得出结论。

六、Spark SQL vs Impala, 同样作为大数据SQL查询引擎框架有什么不同之处？

1、Impala

Impala和 presto, pinot, spark sql等相比，确实是查询性能最快的（注意，我单单说的是查询性能）。Impala最大的问题在于catalogd是个单点，元数据多了后会遇到各种问题。

Catalogd进程是Impala中用来传递Impala SQL导致的元数据变化的组件，它把这些变化传递给集群中所有的节点。一个集群中只需要一个节点上有这个守护进程，因为请求是通过Statestore传递的，因此Statestored和Catalogd 服务应当运行在同一节点上。

引入Catalogd进程的目的就是减少执行REFRESH和INVALIDATE METADATA语句，当在Impala中执行 CREATE TABLE 、 INSERT 或其他表修改、数据修改操作时，不再需要执行 REFRESH 或INVALIDATE METADATA 语句，但是在Hive中执行这些操作，或者直接在HDFS操作数据，这两个语句仍然需要，但是只需要在其中一个节点上运行，不再需要在所有节点上都运行。

本质上，Impala是一个MPP engine，各节点不共享资源，每个executor可以独自完成数据的读取和计算，缺点在于怕stragglers，遇到后整个engine的性能下降到该straggler的能力，所谓木桶的短板，这也是为什么MPP架构不适合异构的机器，要求各节点配置一样。

2、Spark SQL

Spark SQL应该还是算做Batching Processing, 中间计算结果需要落地到磁盘，所以查询效率没有MPP架构的引擎（如Impala）高。