一、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还没有开始处理这个问题。
三、Kylin
Apache Kylin™是一个开源的分布式分析引擎，提供Hadoop之上的SQL查询接口及在线分析处理（OLAP）能力以支持超大规模数据，可实现超大数据集上的亚秒级查询。
Kylin定位于在Hadoop平台之上实现传统数据仓库，商业智能的能力，提供交互式的，多维分析能力，并提供在传统数据仓库技术所不能做到的超大规模数据集的快速查询
kylin通过预计算的方式缓存了所有需要查询的的数据结果，需要大量的存储空间（原数据量的10+倍）。主要是对hive中的数据进行预计算，利用hadoop的mapreduce框架实现。通过预计算的方式将用户设定的多维立方体缓存到HBase中（目前还仅支持hbase）
系统架构：
kylin的出现就是为了解决大数据系统中TB级别数据的数据分析需求，系统架构如下：
Kylin从Hadoop Hive中获取数据，然后经过Cube Build Engine，将Hive中的数据Build成一个OLAP Cube保存在HBase中。对外暴露JDBC、ODBC、Rest API的查询接口，用户执行SQL查询时，通过Query引擎，将SQL语句解析成OLAP Cube查询，然后将结果返回给用户，实现实时查询。
注：从图中可以看出：1）Kylin 利用 MapReduce/Spark 将原始数据进行聚合计算，转成了 OLAP Cube 并加载到 HBase 中，以 Key-Value 的形式存储。
2）Cube 按照时间范围划分为多个 segment，每个 segment 是一张 HBase 表，每张表会根据数据大小切分成多个 region。
3）Kylin 选择 HBase 作为存储引擎，是因为 HBase 具有延迟低，容量大，使用广泛，API完备等特性，此外它的 Hadoop 接口完善，用户社区也十分活跃。
大数据OLAP引擎对比
Presto：内存计算，mpp架构
Druid：时序，数据放内存，索引，预计算
Spark SQL：基于Spark Core，mpp架构
Kylin：Cube预计算
