Apache Kylin
一个采用多维立方体预计算技术的 OLAP 引擎框架，简单来说就是做大数据查询的。
Apache Kylin 的工作原理本质上是 MOLAP（Multidimensional Online Analytical Processing）Cube，也就是多维立方体分析。
特性
SQL 接口
标准查询 SQL 支持
支持海量数据集，增量更新
不会随着数据量的增长导致查询时间线性增长，查询时间只跟维度的个数和基数
亚秒级响应
因为预计算，所以查询时间就是一个查询结果的时间
水平扩展
扩展查询性能，预计算性能扩展需要根据底层计算引擎分别扩展
可视化集成
提供了 ODBC/JDBC 接口和 RESTful API ，方便集成
计算引擎可插拔
目前主要的两个引擎是 MR 和 Spark
存储后端可插拔
目前主要是 基于HBase 的查询后端，也可以基于 Druid 等。
缺点
不支持随机和明细查询
因为预计算的都是多维度的聚合结果，因为随机和明细的查询是不支持的
只支持星型模型
雪花模型和星座模型可以转为星型模型
空间换时间
因为预计算的原因，结果数据会因为维度和度量的个数和基数而直线膨胀
数据结构发生变化需要重新 build cube
因为预计算的原因，导致历史结果数据无法更新只能重写覆盖
Apache Druid
是一个为在大数据集之上做实时统计分析而设计的开源数据存储。这个系统集合了一个面向列存储的层，一个分布式、shared-nothing的架构，和一个高级的索引结构，来达成在秒级以内对十亿行级别的表进行任意的探索分析。
特性
- 亚秒级响应
- 实时导入-kafka
- 支持复杂的聚合
- 不支持大表join
- lookup功能可以join维表
- 预计算-使用 MR 导入数据
缺点
集群复杂
各个节点的配置太多，难以管理
SQL支持不完善
集成 BI 只能 superset 等几个
无法精确计算
Presto
特性
多数据源
MySQL、Hive、Kafka、PostgreSQL、Cassandra等多种connector，并且支持分库分表。
支持 SQL
完全支持标准 SQL
扩展性强
很容易自定义特定数据源的 connector
混合计算
同一个类型数据源可以配多个 catalog，多个catalog之间能直接进行 join 查询和计算
高性能
平均性能是 Hive 的 10 倍。
BI 集成
ODBC和JDBC进行 BI 集成，无 REST API
缺点
性能不稳定，延迟不稳定
受数据量和查询维度的影响较大，到达一定数量级，性能直线下降。
并发不高
受内存资源影响，查询并发不够高
选型要求
总体来说，多维分析有两类场景：
随机查询：临时性的数据分析需求，手写 SQL，形式多变，逻辑也不定，这种场景一般对响应时间没有具体要求，越快越好
固化查询：已经固定的维度分析以及报表分析等场景，对响应时间要求高，聚合查询的 SQL 较多
随机查询选型
正常情况下，随机查询没有捷径可走。只能通过优化计算来提高查询速度，同时保证数据准确度和用户友好即SQL支持好，因此，此类场景下的选型比较简单，以下选择：
Hive
原生的Hadoop生态的数据仓库，相对来说，用于存数据比较好，查询用MR计算，比较耗时。
SparkSQL
Spark体系的，完全支持读 Hive数据，内存计算，内存不够磁盘来凑。
Presto
纯内存计算，并发读不够，支持跨数据源 join
Impala
CDH粘合度较高，不支持跨库查询
固化查询选型
一般来说，适用固化查询的有两类，一个是MPP架构，一个是基于预计算的。在 MPP架构方面，Impala 和 Presto 等性能还不错，但是随着数据量的增加，查询性能直线下降。预计算方面，只要有 Kylin 和 Druid 两个开源组件，各有优劣。通过表格来进行比较。
| 对比项 | Presto | Apache Druid | SparkSQL | Apache Kylin |
|---|---|---|---|---|
| 亚秒级响应 | N | Y | N | Y |
| 高并发 | N | Y | N | Y |
| 百亿数据集 | N | Y | Y | Y |
| SQL支持 | Y | Y (接近完成) | Y | Y |
| 离线 | Y | Y | Y | Y |
| 实时 | N | Y | N | Y (接近完成) |
| 精确去重 | Y | N | Y | Y |
| 明显查询 | Y | N | Y | N |
| 随机查询 | Y | N | Y | N |
| 模型改变 | Y | N | Y | N |
| 多表 join | Y | N | Y | Y |
| ODBC/JDBC 集成 | Y | N | Y | Y |
| Rest API for BI | N | Y | N | Y |
简单的测试：
Presto： count 13亿数据 花了 大概半分钟，40G的环境内存没吃满
SparkSQL：同样数据同样SQL情况下，花了大概 十几秒，具体吃的资源忘记看了，但是应该也不大。
Kylin 和 Druid ：时间主要花在预计算上，加上 Druid 接入 Parquet 元数据比较麻烦， 所以就没做这块的对比。业界普遍的测试结果时，查询时 Druid 比 Kylin 快，因为 HBase 的扫描赶不上倒排索引，但是 Druid 摄取数据没有 Kylin 方便。
环境安装和各个组件的样例测试的个人感受：
Presto很简单，能连接的数据源也很多，就是响应速度和查询并发上不是很好，相对于 Druid 和 Kylin来说。
Kylin 真正应该说是一个 OLAP引擎框架，因为它的Cube构建引擎、预计算引擎、结果存储后端都可以切换。目前构建引擎支持 Hive，SparkSQL。预计算引擎支持 MR、Spark。存储后端支持 HBase、Druid等。
Druid，内部组件有点多，六七个好像有。每个小组件都有自己不同的职责，分工明确，能提升不少效率，但是也加大了集群管理的难度。加上 SQL 支持在最近的版本在比较好的支持，前面的版本都是用 Rest 来呼叫的…还有摄取数据的方式，如果是Hadoop上的数据，都需要自己写Json脚本，然后提交任务。摄取 hadoop 上的 parquet数据还没搞定。
使用 Kylin 和 Druid 比较难用的就是维度和度量的选择，可能会有一些坑要慢慢填。