是选impala还是presto_Kylin、druid、presto、impala四种即席查询对比

一、什么是即席查询

即席查询是用户根据自己的需求，灵活的选择查询条件，系统根据用户的选择生成相应的统计报表。普通查应用查询是定制开发的，即席查询是用户自定义查询条件

理解：快速的执行自定义SQL(可能无法提前运算和预测)

重点关注：数据存储格式和架构

理解了什么是即席查询之后，下面会从定义、框架原理、优化等几个方面介绍这四个框架、最后会做一个对比，面对不同的业务选择合适的框架

二、Kylin

1、定义：Apache kylin是一个开源分布式分析引擎、提供Hadoop、Spark之上的SQL

查询接口及多维分析(OLAP)能力，可以再亚秒内查询巨大的Hive表

(还可以与BI工具集成ODBC、JDBC、RestAPI、还有自带的Zepplin插件，来访问Kylin服务)

2、架构Kylin架构

a、REST 服务层：应用程序开发的入口点

b、查询引擎层:Cube准备就绪后，与系统中的其他组件进行交互，从而向用户返回对应的结果

c、路由层：将解析的SQL生成的执行计划转换成Cube缓存的查询，cube通过预计算缓存在hbase中，这些操作可以在毫秒级完成，还有一些操作使用的原始查询，这部分延迟较高(麒麟高版本中已删除该层)

d、元数据管理工具：kylin的元数据管理存储在hbase中

e、任务引擎：处理所有离线任务：包括shell脚本、javaAPI以及MapReduce任务等等

3、原理

学习kylin的原理之前我们需要掌握几个名词维度：即观察数据的角度

度量：即被聚合的统计值也就是聚合运算的结果

Cuboid：对于每一种维度的组合，将度量值做聚合计算，然后将结果保存为一个物化视图，称为Cuboid。

Cube：所有维度组合的Cuboid作为一个整体，称为Cube。

Apache Kylin的工作原理本质上是MOLAP(多维立方体分析)，即对数据模型做Cube预计算，并利用计算的结果加速查询

a、指定数据模型，定义维度和度量

b、预计算Cube，计算所有Cuboid并保存为物化视图

预计算过程是kylin读取hive中的数据，按照我们选定的维度进行计算，将结果保存在hbase中，默认计算引擎为MapReduce，其中build一次的结果我们称为一个segment，其中涉及多个算法，由kylin.cube.algorithm参数决定，参数值可选auto，layer和inmen，默认值为auto。

逐层构建算法(layer)逐层算法中，按维度数逐层减少来计算，每个层级的计算(除了第一层，它是从原始数据聚合而来)，是基于它上一层级的结果来计算的。比如，[Group by A, B]的结果，可以基于[Group by A, B, C]的结果，通过去掉C后聚合得来的；这样可以减少重复计算；当 0维度Cuboid计算出来的时候，整个Cube的计算也就完成了。

每一轮的计算都是一个MapReduce任务，且串行执行；一个N维的Cube，至少需要N+1次MapReduce Job。

缺点：该算法的效率较低，尤其是当Cube维度系数较大的时候

快速构建算法(inmem)也被称作“逐段”(By Segment) 或“逐块”(By Split) 算法，从1.5.x开始引入该算法，利用Mapper端计算先完成大部分聚合，再将聚合后的结果交给Reducer，从而降低对网络瓶颈的压力。该算法的主要思想是，对Mapper所分配的数据块，将它计算成一个完整的小Cube 段(包含所有Cuboid)；每个Mapper将计算完的Cube段输出给Reducer做合并，生成大Cube，也就是最终结果；如图所示解释了此流程。

与旧算法相比，快速算法主要有两点不同：

1) Mapper会利用内存做预聚合，算出所有组合；Mapper输出的每个Key都是不同的，这样会减少输出到Hadoop MapReduce的数据量；

2)一轮MapReduce便会完成所有层次的计算，减少Hadoop任务的调配。

c、执行查询，读取Cuboid，运行，产生查询结果

下面举一个简单的例子说明，假设有一个电商的销售数据集，其中维度包括时间[time]、商品[item]、地区[location]和供应商[supplier]，度量为销售额。那么所有维度的组合就有2的4次方-1 = 15种一维度(1D)的组合有：[time]、[item]、[location]和[supplier]4种；

二维度(2D)的组合有：[time, item]、[time, location]、[time, supplier]、[item, location]、[item, supplier]、[location, supplier]6种；

三维度(3D)的组合也有4种；

四维度(4D)各有一种，总共15种。

注意：每一种维度组合就是一个Cuboid，16个Cuboid整体就是一个Cube。

4、Cube构建优化

1)检查问题Cube

还有一种更为简单的方法可以帮助我们判断Cube是否已经足够优化。在Web GUI的Model页面选择一个READY状态的Cube，当我们把光标移到该Cube的Cube Size列时，Web GUI会提示Cube的源数据大小，以及当前Cube的大小除以源数据大小的比例，称为膨胀率(Expansion Rate)，如图所示。

一般来说，Cube的膨胀率应该在0%~1000%之间，如果一个Cube的膨胀率超过1000%，那么Cube管理员应当开始挖掘其中的原因。通常，膨胀率高有以下几个方面的原因。

a、Cube中的维度数量较多，且没有进行很好的Cuboid剪枝优化，导致Cuboid数量极多;

b、Cube中存在较高基数的维度，导致包含这类维度的每一个Cuboid占用的空间都很大，这些Cuboid累积造成整体Cube体积变大;

因此，对于Cube膨胀率居高不下的情况，我们需要结合实际数据进行分析，可灵活地运用以下介绍的优化方法对Cube进行优化。

2)优化构建

a、使用聚合组

强制维度：如果一个维度被定义为强制维度，那么这个分组所产生的Cuboid中每一个都会包含该维度

层级维度：每个层级包含两个或更多个维度。假设一个层级中包含D1，D2…Dn这n个维度，那么在该分组产生的任何Cuboid中，这n个维度只会以()，(D1)，(D1，D2)…(D1，D2…Dn)这n+1种形式中的一种出现。

联合维度：每个联合中包含两个或更多个维度，如果某些列形成一个联合，那么在该分组产生的任何Cuboid中，这些联合维度要么一起出现，要么都不出现。

(使用聚合组可以大大减少Cuboid的个数)

b、并发粒度优化

当Segment中某一个Cuboid的大小超出一定的阈值时，系统会将该Cuboid的数据分片到多个分区中，以实现Cuboid数据读取的并行化，从而优化Cube的查询速度。具体的实现方式如下：构建引擎根据Segment估计的大小，以及参数“kylin.hbase.region.cut”的设置决定Segment在存储引擎中总共需要几个分区来存储，如果存储引擎是HBase，那么分区的数量就对应于HBase中的Region数量。kylin.hbase.region.cut的默认值是5.0，单位是GB，也就是说对于一个大小估计是50GB的Segment，构建引擎会给它分配10个分区。用户还可以通过设置kylin.hbase.region.count.min(默认为1)和kylin.hbase.region.count.max(默认为500)两个配置来决定每个Segment最少或最多被划分成多少个分区。

假设将把当前Cube的kylin.hbase.region.count.min设置为2，kylin.hbase.region.count.max设置为100。这样无论Segment的大小如何变化，它的分区数量最小都不会低于2，最大都不会超过100。相应地，这个Segment背后的存储引擎(HBase)为了存储这个Segment，也不会使用小于两个或超过100个的分区。我们还调整了默认的kylin.hbase.region.cut，这样50GB的Segment基本上会被分配到50个分区，相比默认设置，我们的Cuboid可能最多会获得5倍的并发量。

三、impala

1、定义：Cloudera公司推出，提供对HDFS、Hbase数据的高性能、低延迟的交互式SQL查询功能。基于Hive，使用内存计算，兼顾数据仓库、具有实时、批处理、多并发等优点。

2、架构Impala架构

从上图可以看出，Impala自身包含三个模块：Impalad、Statestore和Catalog,除此之外它还依赖hive Metastore和HDFS1) Impalad：

接收client的请求、Query执行并返回给中心协调节点。

子节点上的守护进程，负责向statestore保持通信，汇报工作。

2) Catalog：

分发表的元数据信息到各个impalad中；

接收来自statestore的所有请求。

3) Statestore：

负责收集分布在集群中各个impalad进程的资源信息、各节点健康状况，同步节点信息；

负责query的协调调度。

3、存储和架构

注：impala不支持ORC格式

4、Impala的查询

1. 基本的语法跟hive的查询语句大体一样

2. Impala不支持CLUSTER BY, DISTRIBUTE BY, SORT BY

3. Impala中不支持分桶表

4. Impala不支持COLLECT_SET(col)和explode(col)函数

5. Impala支持开窗函数

5、优化1、 尽量将StateStore和Catalog单独部署到同一个节点，保证他们正常通信。

2、 通过对Impala Daemon内存限制(默认256M)及StateStore工作线程数，来提高Impala的执行效率。

3、 SQL优化，使用之前调用执行计划

4、 选择合适的文件格式进行存储，提高查询效率。

5、 避免产生很多小文件(如果有其他程序产生的小文件，可以使用中间表，将小文件数据存放到中间表。然后通过insert…select…方式中间表的数据插入到最终表中)

6、 使用合适的分区技术，根据分区粒度测算

7、 使用compute stats进行表信息搜集，当一个内容表或分区明显变化，重新计算统计相关数据表或分区。因为行和不同值的数量差异可能导致impala选择不同的连接顺序时进行查询。

8、 网络io的优化：

–a.避免把整个数据发送到客户端

–b.尽可能的做条件过滤

–c.使用limit字句

–d.输出文件时，避免使用美化输出

–e.尽量少用全量元数据的刷新

9、 使用profile输出底层信息计划，在做相应环境优化

四、Druid

1、定义

Druid 是一个分布式的支持实时分析的数据存储系统，具有以下几个特点亚秒级 OLAP 查询，包括多维过滤、Ad-hoc 的属性分组、快速聚合数据等等。

实时的数据消费，真正做到数据摄入实时、查询结果实时。

高效的多租户能力，最高可以做到几千用户同时在线查询。

扩展性强，支持 PB 级数据、千亿级事件快速处理，支持每秒数千查询并发。

极高的高可用保障，支持滚动升级。

实时数据分析是 Apache Druid 最典型的使用场景。该场景涵盖的面很广，例如：实时指标监控

推荐模型

广告平台

搜索模型

这些场景的特点都是拥有大量的数据，且对数据查询的时延要求非常高。在实时指标监控中，系统问题需要在出现的一刻被检测到并被及时给出报警。在推荐模型中，用户行为数据需要实时采集，并及时反馈到推荐系统中。用户几次点击之后系统就能够识别其搜索意图，并在之后的搜索中推荐更合理的结果

(注意：阿里巴巴也曾创建过一个开源项目叫作Druid(简称阿里Druid)，它是一个数据库连接池的项目。阿里Druid 和本问讨论的Druid 没有任何关系，它们解决完全不同的问题。)

2、架构和原理Druid架构

Druid总体包含以下5类节点：

1. 中间管理节点(middleManager node)：及时摄入实时数据，已生成Segment数据文件。

2. 历史节点(historical node)：加载已生成好的数据文件，以供数据查询。historical 节点是整个集群查询性能的核心所在，因为historical会承担绝大部分的segment查询。

3. 查询节点(broker node)：接收客户端查询请求，并将这些查询转发给Historicals和MiddleManagers。当Brokers从这些子查询中收到结果时，它们会合并这些结果并将它们返回给调用者。

4. 协调节点(coordinator node)：主要负责历史节点的数据负载均衡，以及通过规则(Rule)管理数据的生命周期。协调节点告诉历史节点加载新数据、卸载过期数据、复制数据、和为了负载均衡移动数据。

5. 统治者(overlord node) ：进程监视MiddleManager进程，并且是数据摄入Druid的控制器。他们负责将提取任务分配给MiddleManagers并协调Segement发布。

同时，Druid还包含3类外部依赖：

1. 数据文件存储库(DeepStorage)：存放生成的Segment数据文件，并供历史服务器下载，对于单节点集群可以是本地磁盘，而对于分布式集群一般是HDFS。

2. 元数据库(Metastore)，存储Druid集群的元数据信息，比如Segment的相关信息，一般用MySQL或PostgreSQL。

3. Zookeeper：为Druid集群提供以执行协调服务。如内部服务的监控，协调和领导者选举。

3、 Druid的数据结构

与Druid架构相辅相成的是其基于DataSource与Segment的数据结构，它们共同成就了 Druid的高性能优势。

3.1. DataSource结构

若与传统的关系型数据库管理系统( RDBMS)做比较，Druid的DataSource可以理解为 RDBMS中的表(Table)。DataSource的结构包含以下几个方面。

1. 时间列( TimeStamp)：表明每行数据的时间值，默认使用 UTC时间格式且精确到毫秒级别。这个列是数据聚合与范围查询的重要维度。

2. 维度列(Dimension)：维度来自于 OLAP的概念，用来标识数据行的各个类别信息。

3. 指标列( Metric)：指标对应于 OLAP概念中的 Fact，是用于聚合和计算的列。这些指标列通常是一些数字，计算操作通常包括 Count、Sum和 Mean等。

DataSource结构

​无论是实时数据消费还是批量数据处理， Druid在基于DataSource结构存储数据时即可选择对任意的指标列进行聚合( RollUp)操作。该聚合操作主要基于维度列与时间范围两方面的情况。

下图显示的是执行聚合操作后 DataSource的数据情况。

DataSource聚合后的数

相对于其他时序数据库， Druid在数据存储时便可对数据进行聚合操作是其一大特点，该特点使得 Druid不仅能够节省存储空间，而且能够提高聚合查询的效率。

3.2. Segment结构

DataSource是一个逻辑概念， Segment却是数据的实际物理存储格式， Druid正是通过 Segment实现了对数据的横纵向切割( Slice and Dice)操作。从数据按时间分布的角度来看，通过参数 segmentGranularity的设置，Druid将不同时间范围内的数据存储在不同的 Segment数据块中，这便是所谓的数据横向切割。

这种设计为 Druid带来一个显而易见的优点：按时间范围查询数据时，仅需要访问对应时间段内的这些 Segment数据块，而不需要进行全表数据范围查询，这使效率得到了极大的提高。

通过 Segment将数据按时间范围存储，同时，在 Segment中也面向列进行数据压缩存储，这便是所谓的数据纵向切割。而且在 Segment中使用了 Bitmap等技术对数据的访问进行了优化。

五、Presto

1、定义

Presto是一个开源的分布式SQL查询引擎，适用于交互式分析查询，数据量支持GB到PB字节。注：虽然Presto可以解析SQL，但它不是一个标准的数据库。不是MySQL、Oracle的代替品，也不能用来处理在线事务(OLTP)

应用场景

Presto支持在线数据查询，包括Hive，关系数据库(MySQL、Oracle)以及专有数据存储。一条Presto查询可以将多个数据源的数据进行合并，可以跨越整个组织进行分析。

Presto主要用来处理响应时间小于1秒到几分钟的场景。

2、架构

Presto有两类服务器：Coordinator和Worker。1)Coordinator

Coordinator服务器是用来解析语句，执行计划分析和管理Presto的Worker结点。Presto安装必须有一个Coordinator和多个Worker。如果用于开发环境和测试，则一个Presto实例可以同时担任这两个角色。

Coordinator跟踪每个Work的活动情况并协调查询语句的执行。Coordinator为每个查询建立模型，模型包含多个Stage，每个Stage再转为Task分发到不同的Worker上执行。

Coordinator与Worker、Client通信是通过REST API。

2)Worker

Worker是负责执行任务和处理数据。Worker从Connector获取数据。Worker之间会交换中间数据。Coordinator是负责从Worker获取结果并返回最终结果给Client。

当Worker启动时，会广播自己去发现 Coordinator，并告知 Coordinator它是可用，随时可以接受Task。

Worker与Coordinator、Worker通信是通过REST API。

3)数据源

贯穿全文，你会看到一些术语：Connector、Catelog、Schema和Table。这些是Presto特定的数据源

(1)Connector

Connector是适配器，用于Presto和数据源(如Hive、RDBMS)的连接。你可以认为类似JDBC那样，但却是Presto的SPI的实现，使用标准的API来与不同的数据源交互。

Presto有几个内建Connector：JMX的Connector、System Connector(用于访问内建的System table)、Hive的Connector、TPCH(用于TPC-H基准数据)。还有很多第三方的Connector，所以Presto可以访问不同数据源的数据。

每个Catalog都有一个特定的Connector。如果你使用catelog配置文件，你会发现每个文件都必须包含connector.name属性，用于指定catelog管理器(创建特定的Connector使用)。一个或多个catelog用同样的connector是访问同样的数据库。例如，你有两个Hive集群。你可以在一个Presto集群上配置两个catelog，两个catelog都是用Hive Connector，从而达到可以查询两个Hive集群。

(2)Catelog

一个Catelog包含Schema和Connector。例如，你配置JMX的catelog，通过JXM Connector访问JXM信息。当你执行一条SQL语句时，可以同时运行在多个catelog。

Presto处理table时，是通过表的完全限定(fully-qualified)名来找到catelog。例如，一个表的权限定名是hive.test_data.test，则test是表名，test_data是schema，hive是catelog。

Catelog的定义文件是在Presto的配置目录中。

(3)Schema

Schema是用于组织table。把catelog好schema结合在一起来包含一组的表。当通过Presto访问hive或Mysq时，一个schema会同时转为hive和mysql的同等概念。

(4)Table

Table跟关系型的表定义一样，但数据和表的映射是交给Connector。

数据模型1)Presto采取三层表结构：

Catalog：对应某一类数据源，例如Hive的数据，或MySql的数据

Schema：对应MySql中的数据库

Table：对应MySql中的表

2)Presto的存储单元包括：

Page：多行数据的集合，包含多个列的数据，内部仅提供逻辑行，实际以列式存储。

Block：一列数据，根据不同类型的数据，通常采取不同的编码方式，了解这些编码方式，有助于自己的存储系统对接presto。

3)不同类型的Block：

(1)Array类型Block，应用于固定宽度的类型，例如int，long，double。block由两部分组成：

boolean valueIsNull[]表示每一行是否有值。

T values[] 每一行的具体值。

(2)可变宽度的Block，应用于String类数据，由三部分信息组成

Slice：所有行的数据拼接起来的字符串。

int offsets[]：每一行数据的起始便宜位置。每一行的长度等于下一行的起始便宜减去当前行的起始便宜。

boolean valueIsNull[] 表示某一行是否有值。如果有某一行无值，那么这一行的便宜量等于上一行的偏移量。

(3)固定宽度的String类型的block，所有行的数据拼接成一长串Slice，每一行的长度固定。

(4)字典block：对于某些列，distinct值较少，适合使用字典保存。主要有两部分组成：

字典，可以是任意一种类型的block(甚至可以嵌套一个字典block)，block中的每一行按照顺序排序编号。

int ids[]表示每一行数据对应的value在字典中的编号。在查找时，首先找到某一行的id，然后到字典中获取真实的值。

总结:

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

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

3.Presto:它没有使用Mapreduce，大部分场景下比HIVE块一个数量级，其中的关键是所有的处理都在内存中完成。

4.Impala:基于内存计算，速度快，支持的数据源没有Presto多。

5.SparkSQL：是spark用来处理结构化的一个模块，它提供一个抽象的数据集DataFrame,并且是作为分布式SQL查询引擎的应用。它还可以实现Hive on Spark,hive里的数据用sparksql查询。

6.框架选型：(1)从超大数据的查询效率来看：

Druid>Kylin>Presto>SparkSQL

(2)从支持的数据源种类来讲：

Presto>SparkSQL>Kylin>Druid