查询/分析引擎

一、Phoenix

相当于一个Java中间件，提供jdbc连接，操作hbase数据表。Phoenix是一个HBase的开源SQL引擎。你可以使用标准的JDBC API代替HBase客户端API来创建表，插入数据，查询你的HBase数据。意思是可以用SQL语句来查询Hbase.

Phoenix 架构图

从图中可以看出，Phoenix 分为 client 和 server，其中 client 又分为 thin（本质上是一个 JDBC 驱动，所依赖的第三方类较少）和非 thin （所依赖的第三方类较多）两种；server 是针对 thin client 而言的，为 standalone 模式，是由一台 Java 服务器组成，代表客户端管理 Phoenix 的连接，可以进行横向扩展，启动方式也很简单，通过 bin/queryserver.py start 即可。

特点

1、它只能查Hbase，别的类型都不支持！但是也因为这种专一的态度，让Phoenix在Hbase上查询的性能超过了Hive和Impala
2、Phoenix完全使用Java编写，作为HBase内嵌的JDBC驱动。Phoenix查询引擎会将SQL查询转换为一个或多个HBase扫描，并编排执行以生成标准的JDBC结果集。
3、Phoenix 直接使用 HBase API，以及协处理器和自定义过滤器，从而使得查询的效率更好，更好的保留了HBASE的优点。
4、phoenix-spark插件扩展了Phoenix对MapReduce的支持，以允许Spark将Phoenix表作为DataFrames加载，并允许将其持久化回Phoenix。
注：1、Phoenix下一个主要版本5.0.0已发布，已与其他Hadoop产品（例如Spark，Hive，Pig，Flume和Map Reduce）完全集成
2、对于Phoenix版本4.7和4.8，您必须使用“ phoenix- -client-spark.jar”。
3、从Phoenix 4.10开始，“ phoenix- -client.jar”是针对Spark 2.x编译的。如果需要与Spark 1.x兼容，则必须使用spark16 maven配置文件编译Phoenix 。
配置
(1) 将phoenix目录下的phoenix-4.8.2-HBase-1.2-server.jar、
phoenix-core-4.8.2-HBase-1.2.jar拷贝到各个 hbase的lib目录下。
(2) 将hbase的配置文件hbase-site.xml、 hadoop/etc/hadoop下的core-site.xml 、hdfs-site.xml放到phoenix/bin/下，替换phoenix原来的配置文件。
(3) 重启hbase集群，使Phoenix的jar包生效。
注：1、phoenix 但是跟普通的数据sql有一点差异。phoenix插入与更新都是使用的upsert语句
2、写关联的查询会用in语句直接在里面写查询的嵌套时，phoenix中这样做效率很低。phoenix的查询首先需要查询出你需要数据的主键，再使用in语句进行二次查询，这样查询要快一些

二、presto

Presto是一个分布式的查询引擎，本身并不存储数据，但是可以接入多种数据源，适用于交互式分析查询，并且支持跨数据源的级联查询。Presto用于对大小从GB到PB的各种数据源运行交互式分析查询，擅长对海量数据进行复杂的分析。
被设计为用来专门进行高速、实时的数据分析，支持标准的ANSI SQL，包括复杂查询、聚合（aggregation）、连接（join）和窗口函数（window functions)。
注：presto是facebook开源的，目前很多国内知名企业都在用如唯品会、美团、阿里。

系统架构

presto 查询引擎是一个Master-Slave的拓扑架构

presto以插件形式对数据存储层进行了抽象，它叫做连接器，不仅包含Hadoop相关组件的连接器还包括RDBMS连接器。
注：1、coordinator：中心的查询角色，接收查询请求、解析SQL、 生成执行计划、任务调度、worker管理。coordinator是presto集群的master进程。
2、worker：执行任务的节点
3、connector：提取数据 负责实际执行查询计划
具体访问哪个数据源是通过catalog 中的XXXX.properties文件中connector.name决定的
4、discovery service：将coordinator和worker结合在一起服务；worker节点启动后向discovery service服务注册；coordinator通过discovery service获取注册的worker节点。

特点

1、支持多数据源
Presto支持在线数据查询，包括Hive, Cassandra, 关系数据库以及专有数据存储。 一条Presto查询可以将多个数据源的数据进行合并，可以跨越整个组织进行分析。Presto需要从其他数据源获取数据来进行运算分析，它可以连接多种数据源，包括Hive、RDBMS（Mysql、Oracle、Tidb等）、Kafka、MongoDB、Redis等。
2、完全java开发，后期方便维护和二次开发。
3、Presto适用于期望响应时间从亚秒到数分钟不等的分析。
4、presto 不和 CDH绑定。
注：Presto的接入方式有多种：presto-cli，pyhive，jdbc，http，golang，SQLAlchemy，PHP等，其中presto-cli是Presto官方提供的。
缺点：
1、不适合多个大表的join操作，因为presto是基于内存的，如果一个presto查询查过30分钟，那说明不适合。presto算是hive的一个补充，需要尽快得出结果的用presto，否则用hive。
2、对于presto，他的查询时间是很短的，与其查询这里做容错能力，不如重新执行来的快，来的简单。对于coordinator和discovery server节点的单点故障，presto还没有开始处理这个问题。

查询优化

1、数据存储
（1）合理设置分区：与Hive类似，Presto会根据元信息读取分区数据，合理的分区能减少Presto数据读取量，提升查询性能。
（2）使用列式存储：Presto对ORC文件读取做了特定优化，因此在Hive中创建Presto使用的表时，建议采用ORC格式存储。相对于Parquet，Presto对ORC支持更好。
（3）使用压缩：数据压缩可以减少节点间数据传输对IO带宽压力，对于即席查询需要快速解压，建议采用snappy压缩
（4）预先排序：对于已经排序的数据，在查询的数据过滤阶段，ORC格式支持跳过读取不必要的数据。比如对于经常需要过滤的字段可以预先排序。
2、SQL优化
（1）只选择使用必要的字段： 由于采用列式存储，选择需要的字段可加快字段的读取、减少数据量。避免采用*读取所有字段；
（2）过滤条件必须加上分区字段；
（3）Group By语句优化： 合理安排Group by语句中字段顺序对性能有一定提升。将Group By语句中字段按照每个字段distinct数据多少进行降序排列， 减少GROUP BY语句后面的排序一句字段的数量能减少内存的使用；
（4）Order by时使用Limit， 尽量避免ORDER BY： Order by需要扫描数据到单个worker节点进行排序，导致单个worker需要大量内存；
（5）使用近似聚合函数： 对于允许有少量误差的查询场景，使用这些函数对查询性能有大幅提升。比如使用approx_distinct() 函数比Count(distinct x)有大概2.3%的误差；
（6）用regexp_like代替多个like语句： Presto查询优化器没有对多个like语句进行优化，使用regexp_like对性能有较大提升；
（7）使用Join语句时将大表放在左边： Presto中join的默认算法是broadcast join，即将join左边的表分割到多个worker，然后将join右边的表数据整个复制一份发送到每个worker进行计算。如果右边的表数据量太大，则可能会报内存溢出错误；
（8）使用Rank函数代替row_number函数来获取Top N；
（9）UNION ALL 代替 UNION ：不用去重；
（10）使用WITH语句： 查询语句非常复杂或者有多层嵌套的子查询，请试着用WITH语句将子查询分离出来.

三、Kylin

Apache Kylin™是一个开源的分布式分析引擎，提供Hadoop之上的SQL查询接口及在线分析处理（OLAP）能力以支持超大规模数据，可实现超大数据集上的亚秒级查询。
Kylin定位于在Hadoop平台之上实现传统数据仓库，商业智能的能力，提供交互式的，多维分析能力，并提供在传统数据仓库技术所不能做到的超大规模数据集的快速查询
kylin通过预计算的方式缓存了所有需要查询的的数据结果，需要大量的存储空间（原数据量的10+倍）。主要是对hive中的数据进行预计算，利用hadoop的mapreduce框架实现。通过预计算的方式将用户设定的多维立方体缓存到HBase中（目前还仅支持hbase）

系统架构

Kylin从Hadoop Hive中获取数据，然后经过Cube Build Engine，将Hive中的数据Build成一个OLAP Cube保存在HBase中。对外暴露JDBC、ODBC、Rest API的查询接口，用户执行SQL查询时，通过Query引擎，将SQL语句解析成OLAP Cube查询，然后将结果返回给用户，实现实时查询。
kylin的出现就是为了解决大数据系统中TB级别数据的数据分析需求，系统架构如下：

注：从图中可以看出：1）Kylin 利用 MapReduce/Spark 将原始数据进行聚合计算，转成了 OLAP Cube 并加载到 HBase 中，以 Key-Value 的形式存储。
2）Cube 按照时间范围划分为多个 segment，每个 segment 是一张 HBase 表，每张表会根据数据大小切分成多个 region。
3）Kylin 选择 HBase 作为存储引擎，是因为 HBase 具有延迟低，容量大，使用广泛，API完备等特性，此外它的 Hadoop 接口完善，用户社区也十分活跃。
4、数据请求可以利用基于SQL的工具由SQL提交而产生，或者利用第三方应用程序通过Kylin的RESTful服务来实现。
（1）RESTful服务会调用Query Engine，后者则检测对应的目标数据集是否真实存在。如果确实存在，该引擎会直接访问目标数据并以次秒级延迟返回结果。
（2）如果目标数据集并不存在，该引擎则会根据设计将无匹配数据集的查询路由至Hadoop上的SQL处、即交由Hive等Hadoop集群负责处理

组件介绍

1、核心组件：Kylin的OLAP引擎框架包括元数据引擎、查询引擎、作业引擎、存储引擎以及用来处理客户端请求的REST服务器
2、元数据管理工具（Metadata Manager）: Kylin是一款元数据驱动型应用程序。元数据管理工具是一大关键性组件，用于对保存在Kylin当中的所有元数据进行管理，其中包括最为重要的cube元数据。其它全部组件的正常运作都需以元数据管理工具为基础，包括cube的定义，星状模型的定义、job的信息、job的输出信息、维度的directory信 息等等，元数据和cube都存储在hbase中，存储的格式是json字符串，除此之外，还可以选择将元数据存储在本地文件系统
3、任务引擎（Job Engine）: 这套引擎的设计目的在于处理所有离线任务，其中包括shell脚本、Java API以及Map Reduce任务等等。任务引擎对Kylin当中的全部任务加以管理与协调，从而确保每一项任务都能得到切实执行并解决其间出现的故障
4、存储引擎（Storage Engine）: 这套引擎负责管理底层存储——特别是cuboid，其以键-值对的形式进行保存。存储引擎使用的是HBase——这是目前Hadoop生态系统当中最理想的键-值系统使用方案。Kylin还能够通过扩展实现对其它键-值系统的支持，例如Redis
5、REST Server: REST Server是一套面向应用程序开发的入口点，旨在实现针对Kylin平台的应用开发工作。 此类应用程序可以提供查询、获取结果、触发cube构建任务、获取元数据以及获取用户权限等等。
6、ODBC驱动程序:为了支持第三方工具与应用程序——例如Tableau——我们构建起了一套ODBC驱动程序并对其进行了开源。我们的目标是让用户能够更为顺畅地采用这套Kylin平台
7、jdbc驱动程序：kylin提供了jdbc的驱动，驱动的classname为org.apache.kylin.jdbc.Driver，使用 的url的前缀jdbc:kylin:，使用jdbc接口的查询走的流程和使用RESTFul接口查询走的内部流程是相同的。这类接口也使得kylin很 好的兼容tebleau甚至mondrian。
8、查询引擎（Query Engine）:当cube准备就绪后，查询引擎就能够获取并解析用户查询。它随后会与系统中的其它组件进行交互，从而向用户返回对应的结果，kylin使用一个开源的Calcite框架实现SQL的解析，相当于SQL引擎层
9、Routing：该模块负责将解析SQL生成的执行计划转换成cube缓存的查询，cube是通过预计算缓存在hbase中，这部分查询是可以再秒级甚至 毫秒级完成，而还有一些操作使用过查询原始数据（存储在hadoop上通过hive上查询），这部分查询的延迟比较高。
10、Cube构建引擎：这个模块是所有模块的基础，它负责预计算创建cube，创建的过程是通过hive读取原始数据然后通过一些mapreduce计算生成Htable然后load到hbase中。

大数据OLAP引擎对比

Presto：内存计算，mpp架构
Druid：时序，数据放内存，索引，预计算
Spark SQL：基于Spark Core，mpp架构
Kylin：Cube预计算
Cube预处理和MPP架构
SparkSQL本质上是基于DAG模型的MPP。而Kylin核心是Cube(多维立方体)。关于MPP和Cube预处理的差异，重复如下：
MPP的基本思路是增加机器来并行计算，从而提高查询速度。比如扫描8亿记录一台机器要处理1小时，但如果用100台机器来并行处理，就只要一分钟不到。再配合列式存储和一些索引，查询可以更快返回。要注意这里在线运算量并没有减小，8亿条记录还是要扫描一次，只是参与的机器多了，所以快了。
MOLAP Cube是一种预计算技术，基本思路是预先对数据作多维索引，查询时只扫描索引而不访问原始数据从而提速。8亿记录的一个3维索引可能只有几万条记录，规模大大缩小，所以在线计算量大大减小，查询可以很快。索引表也可以采用列存储，并行扫描等MPP常用的技术。但多维索引要对多维度的各种组合作预计算，离线建索引需要较大计算量和时间，最终索引也会占用较多磁盘空间。
注：除了有无预处理的差异外，SparkSQL与Kylin对数据集大小的偏好也不一样。如果数据可以基本放入内存，Spark的内存缓存会让SparkSQL有好的表现。但对于超大规模的数据集，Spark也不能避免频繁的磁盘读写，性能会大幅下降。反过来Kylin的Cube预处理会大幅减小在线数据规模，对于超大规模数据更有优势。