今天聊一聊 OLAP 技术，一哥认为好的 OLAP 引擎应该具备以下三个条件：易开发、易维护、易移植。今天给大家分享一下常见的几种 OLAP 计算引擎，他们的特性、适用场景，优缺点等，希望对大家在选型应用上有帮助。
Kylin
简介
1、Kylin 是 ebay 开发的一套 MOLAP 系统；
2、提供 Hadoop 之上的 SQL 查询接口及多维分析能力以支持超大规模数据；
3、提供与 BI 工具（如 Tableau）的整合能力；
适用范围
适用于：数据仓库，用户行为分析，流量（日志）分析，自助分析平台，电商分析，广告效果分析，实时分析，数据服务平台等各种场景
产品特性
1、Kylin 是对 hive 中的数据进行预计算，利用 hadoop 的 mapreduce 框架实现
2、Kylin 为 Hadoop 提供标准 SQL 支持大部分查询功能
3、用户可以与 Hadoop 数据进行亚秒级交互，在同样的数据集上提供比 Hive 更好的性能
4、用户能够在 Kylin 里为百亿以上数据集定义数据模型并构建立方体
5、友好的 web 界面以管理，监控和使用立方体
6、支持额外功能和特性的插件
7、与调度系统，ETL，监控等生命周期管理系统的整合
8、通过预计算的方式缓存了所有 需要查询的的数据结果，需要大量的存储空间（原数据量的 10+倍）
Presto
简介
1、Presto 是一个开源的分布式 SQL 查询引擎，适用于交互式分析查询，数据量支持 GB 到 PB 字节。
2、Presto 的设计和编写完全是为了解决像 Facebook 这样规模的商业数据仓库的交互式分析和处理速度的问题。
适用范围
1、Presto 支持 SQL 并提供了一个标准数据库的语法特性，但其不是一个通常意义上的关系数据库。
2、Presto 是一个可选的工具，可以用来查询 HDFS
3、被设计为处理数据仓库和分析：分析数据，聚合大量的数据并产生报表，这些场景通常被定义为 OLAP
产品特性
1、Presto 支持在线数据查询，包括 Hive, Cassandra
2、一条 Presto 查询可以将多个数据源的数据进行合并，可以跨越整个组织进行分析
3、完全基于内存的并行计算
4、流水线
5、本地化计算
6、动态编译执行计划
7、小心使用内存和数据结构
8、类 BlinkDB 的近似查询
9、GC 控制
Impala
简介
1、由 cloudera 公司主导开发的大数据实时查询分析工具。
2、是一个分布式，大规模并行处理（MPP）数据库引擎，包括运行在 CDH 集群主机上的不同后台进程。
3、Impala 主要由 Impalad， State Store 和 CLI 组成。
适用范围
Impala 适合于实时交互式 SQL 查询，Impala 给数据分析人员提供了快速实验、验证想法的大数据分析工具。
产品特性
1.查询速度快。不同于 hive 底层执行使用的是 MapReduce 引擎，它仍然是一个批处理过程。impala 中间结果不写入磁盘，即使及时通过网络以流的形式传递，大大降低的节点的 IO 开销。
2.灵活性高。可以直接查询存储在 HDFS 上的原生数据，也可以查询经过优化设计而存储的数据，只需要数据的格式能够兼容 MapReduce、hive、Pig 等等。
3.易整合。很容易和 hadoop 系统整合，并使用 hadoop 生态系统的资源和优势，不需要将数据迁移到特定的存储系统就能满足查询分析的要求。
4.可伸缩性。可以很好的与一些 BI 应用系统协同工作，如 Microstrategy、Tableau、Qlikview 等。
5、使用 Impala 比使用 Hive 能提高 3-90 的效率
Kudu
简介
1、Cloudera 带头开发的存储系统，其整体应用模式和 HBase 比较接近，即支持行级别的随机读写，并支持批量顺序检索功能。
2、Kudu 管理的是类似关系型数据库的结构化的表。
3、Kudu 底层核心代码使用 C++开发，对外提供 Java API 接口。
适用范围
1、Kudu 的定位是提供 fast analytics on fast data，也就是在快速更新的数据上进行快速的查询。
2、它定位 OLAP 和少量的 OLTP 工作流，如果有大量的 random accesses，官方建议还是使用 HBase 最为合适。
产品特性
1、Kudu 的集群架构基本和 HBase 类似，采用主从结构，Master 节点管理元数据，Tablet 节点负责分片管理数据。
2、Kudu 采用了类似 log-structured 存储系统的方式，增删改操作都放在内存中的 buffer，然后才 merge 到持久化的列式存储中。Kudu 还是用了 WALs 来对内存中的 buffer 进行灾备。
对比分析
Kylin
Kylin 可以说是与市面上流行的 RTOLAP 走了一条完全不同的道路。Kylin 在如何快速求得预计算结果，以及优化查询解析使得更多的查询能用上预计算结果方面在优化，后续 Kylin 的版本会优化预计算速度，使得 Kylin 可以变成一个近似实时的分析引擎。然而其缺点就是 SQL 支持方面可能在一定程度上会有所牺牲，存储开销也会比较大， 而像 Presto，SparkSQL，Hawq 等是着重于优化查询数据的过程环节，像一些其它的数据仓库一样，使用列存、压缩、并行查询等技术，优化查询。这种方案的好处就在于扩展性强、能适配更广泛的查询， 然而由于每次的聚合计算是 On Fly 的，因此性能上相较 Kylin 还是有所不如。
Presto
- 轻量快速支持近实时交互查询
- 在 Facebook 得到广泛使用，扩展性和稳定性毋容置疑
- 使用分布式查询引擎，和传统的 MapReduce 相比消除了延迟和磁盘 IO 开销
- 后期支持 UDF
Impala
优点：
- 支持 SQL 查询，快速查询大数据。
- 可以对已有数据进行查询，减少数据的加载，转换。
- 多种存储格式可以选择（Parquet,Text, Avro, RCFile, SequeenceFile）。
- 可以与 Hive 配合使用。
缺点：
- 不支持用户定义函数 UDF。
- 不支持 text 域的全文搜索。
- 不支持 Transforms。
- 不支持查询期的容错。
- 对内存要求高。
在实时性要求不高的应用场景中，比如，月度、季度、年度报表的生成。可以使用基于传统的 HadoopMapreduce 处理海量大数据。但是在一些实时性要求很高的场景中，一方面满足实时性要求，一方面提升用户体验。Impala 因其快速的响应能力当之无愧作为首选查询分析工具。
Kudu
Kudu 本质上是将性能的优化，寄托在以列式存储为核心的基础上，希望通过提高存储效率，加快字段投影过滤效率，降低查询时 CPU 开销等来提升性能。而其他绝大多数设计，都是为了解决在列式存储的基础上支持随机读写这样一个目的而存在的。比如类 Sql 的元数据结构，是提高列式存储效率的一个辅助手段，唯一主键的设定也是配合列式存储引入的定制策略，至于其他如 Delta 存储，compaction 策略等都是在这个设定下为了支持随机读写，降低 latency 不确定性等引入的一些 Tradeoff 方案。
官方测试结果上，如果是存粹的随机读写，或者单行的检索请求这类场景，由于这些 Tradeoff 的存在，HBASE 的性能吞吐率是要优于 Kudu 不少的（2 倍到 4 倍），kudu 的优势还是在支持类 SQL 检索这样经常需要进行投影操作的批量顺序检索分析场合。
