经常使用OLAP引擎

 l  presto

Presto是Facebook开发的分布式大数据SQL查询引擎，专门进行快速数据分析。

特色：

1. 能够将多个数据源的数据进行合并，能够跨越整个组织进行分析。
2. 直接从HDFS读取数据，在使用前不须要大量的ETL操做。

查询原理：

1. 彻底基于内存的并行计算
2. 流水线
3. 本地化计算
4. 动态编译执行计划
5. 当心使用内存和数据结构
6. 类BlinkDB的近似查询
7. GC控制

架构图：

 

Presto实现原理和美团的使用实践 http://tech.meituan.com/presto.html

Presto官网 http://prestodb-china.com/

l  druid

Druid是广告分析公司Metamarkets开发的一个用于大数据实时查询和分析的分布式实时处理系统，主要用于广告分析，互联网广告系统监控、度量和网络监控。

特色：

1. 快速的交互式查询——Druid的低延迟数据摄取架构容许事件在它们建立后毫秒内可被查询到。
2. 高可用性——Druid的数据在系统更新时依然可用，规模的扩大和缩小都不会形成数据丢失；
3. 可扩展——Druid已实现天天可以处理数十亿事件和TB级数据。
4. 为分析而设计——Druid是为OLAP工做流的探索性分析而构建，它支持各类过滤、聚合和查询。

应用场景：

1. 须要实时查询分析时；
2. 具备大量数据时，如天天数亿事件的新增、天天数10T数据的增长；
3. 须要一个高可用、高容错、高性能数据库时。
4. 须要交互式聚合和快速探究大量数据时

架构图：

 

 

Druid官网 http://druid.io/druid.html

Druid：一个用于大数据实时处理的开源分布式系统   http://www.infoq.com/cn/news/2015/04/druid-data/

Druid创始人Eric Tschetter详解开源实时大数据分析系统Druid   http://www.csdn.net/article/2014-10-30/2822381

l  apache kylin

Apache Kylin最初由eBay开发并贡献至开源社区的分布式分析引擎，提供Hadoop之上的SQL查询接口及多维分析（OLAP）能力以支持超大规模数据。

特色:

1. 用户为百亿以上数据集定义数据模型并构创建方体
2. 亚秒级的查询速度，同时支持高并发
3. 为Hadoop提供标准SQL支持大部分查询功能
4. 提供与BI工具，如Tableau的整合能力
5. 友好的web界面以管理，监控和使用立方体
6. 项目及立方体级别的访问控制安全

架构图：

 

 

kylin官网  http://kylin.apache.org/cn/

l  系统对比

性能对比：

Presto，Kylin1.3，Kylin1.5和Druid

典型的五个查询场景：一个事实表的过滤和聚合；五张表全关联以后的查询；两个Count Dstinct指标和两个Sum指标；后面两个查询包含8~10个的维度过滤。

 

图-千万规模的级别

总结：能够看到无论Presto跟Kylin仍是Druid相比差的都比较多，差一个数量级。从后面的两个查询上能够看到，在千万规模的级别，和Druid仍是有比较大的差距。这主要和它们的实现模式相关，由于Druid会把全部的数据预处理完之后都加载到内存里，在作一些小数据量聚合的时候，能够达到很是快的速度；可是Kylin要到HBase上读，相对来讲它的性能要差一些，但也彻底能知足需求。

 

图-亿规模的级别

总结：在亿级的规模上状况又有了变化，仍是看后面两个查询，Kylin1.3基本上是一个线性的增加，这个数据已经变得比较难看了，这是因为Kylin1.3在扫描HBase的时候是串行方式，可是Kylin1.5反而会有更好的表现，这是由于Kylin1.5引入了HBase并行Scan，大大下降了扫描的时间。Kylin1.5的数据会shard到不一样的region上，在千万量级上数据量还比较小，没有明显的体现，可是上亿之后，随着数据量上升，region也变多了，反而能把并发度提上去。因此在这里能够看到Kylin1.5表现会更好。这里也能够看出，在数据量成数量级上升后，Kylin表现的更加稳定，在不一样规模数据集上依然能够保持不错的查询性能。而Druid随着数据量的增加性能损失也成倍增加。

系统的易用性：

Druid一个集群的角色是很是多的，若是要把这个系统用起来的话，可能光搭这个环境，起这些服务都要很长的时间。这个对于咱们作平台来说，其实是一个比较痛的事。不论是在部署，仍是加监控的时候，成本都是相对比较高的。另一个查询接口方面，咱们最熟悉或者最标准，最好用的固然是标准SQL的接口。ES、Druid这些系统原来都不支持SQL，固然如今也有一些插件，可是在功能的完备性和数据的效率上都不如原生的支持。

数据成本：

在查询成本上，Presto是最好的，由于几乎不须要作什么特殊的处理，基本上Hive能读的数据Presto也都能读，因此这个成本很是低。Druid和Kylin的成本相对较高，由于都须要提早的预计算，尤为是Kylin若是维度数特别多，并且不作特别优化的话，数据存储会比较耗资源。

Kylin优点：

第一，性能很是稳定。由于Kylin依赖的全部服务，好比Hive、HBase都是很是成熟的，Kylin自己的逻辑并不复杂，因此稳定性有一个很好的保证。

第二，易用。首先是外围的服务，不论是Hive仍是HBase，只要你们用Hadoop系统的话基本都有了，不须要额外工做。在部署运维和使用成本上来说，都是比较低的。其次，有一个公共的Web页面来作模型的配置。相比之下Druid如今仍是基于配置文件来作。这里就有一个问题，配置文件通常都是平台方或者管理员来管理的，没办法把这个配置系统开放出去，这样在沟通成本和响应效率上都不够理想。

第三，活跃开放的社区和热心的核心开发者团队，社区里讨论很是开放，你们能够提本身的意见及patch，修复bug以及提交新的功能等。核心团队都是中国人，这是Apache全部项目里惟一中国人为主的顶级项目，社区很是活跃和热心，有很是多的中国工程师。

Apache Kylin在美团数十亿数据OLAP场景下的实践 http://kyligence.io/2016/08/2016/