1、常见方案比较
首先，Hive/SparkSQL 在数据仓库的领域应用是比较广泛的，但是因为查询时延很难能够满足毫秒到秒级的要求，同时因为是离线计算，数据时效性也比较差。
其次，ES （Elasticsearch+Logstash+Kibana）是一个功能很强大的系统，在中等数据规模场景下能较好地满足需求，但是在万亿和更大的数据规模场景下，数据的写入性能和查询性能都遇到了很大的瓶颈。
最后，Kylin 和 Druid 功能比较类似，考虑到 Druid 采用 OLAP 架构，数据时效性相对于 Kylin 来讲会更好，数据的变更也相对更加灵活，所以最终 Druid 作为 OLAP 平台的查询引擎比较合适。
2、Kylin与Druid具体介绍
Apache Kylin
Apache Kylin的核心思想是利用空间换时间，它主要是通过预计算的方式将用户设定的多维立方体缓存到HBase中（目前还仅支持hbase），同时由于Apache Kylin在查询方面制定了多种灵活的策略，进一步提高空间的利用率，使得这样的平衡策略在应用中值得采用。
Apche Kylin 是 Hadoop 大数据平台上的一个开源 OLAP 引擎。它采用多维立方体（Cube）预计算技术，可以将某些场景下的大数据 SQL 查询速度提升到亚秒级别。相对于之前的分钟乃至小时级别的查询速度。
kylin主要是对hive中的数据进行预计算，利用hadoop的mapreduce框架实现;kylin的出现就是为了解决大数据系统中TB级别数据的数据分析需求。
核心是Cube，cube是一种预计算技术，基本思路是预先对数据作多维索引，查询时只扫描索引而不访问原始数据从而提速。
关键技术：大规模并行处理 列式存储 预计算
它的优势在于项目来自于丰富的实践、发展前景光明、直接利用了成熟的Hadoop体系（HBase和Hive等）、cube模型支持较好、查询速度快速等。但它也在一些方面有着自己的局限，比如：查询的维度组合数量需要提前确定好，不适合即席查询分析；预计算量大，资源消耗多；集群依赖较多，如HBase和Hive等，属于重量级方案，因此运维成本也较高。
Apache Druid
Druid 是一个开源的，分布式的，列存储的，适用于实时数据分析的高容错、高性能开源分布式系统，能够快速聚合、灵活过滤、毫秒级查询、和低延迟数据导入。
Druid是一个为大型冷数据集上实时探索查询而设计的开源数据分析和存储系统，提供极具成本效益并且永远在线的实时数据摄取和任意数据处理。
Druid是一个实时处理时序数据的Olap数据库，因为它的索引首先按照时间分片，查询的时候也是按照时间线去路由索引。
Druid应用最多的如广告分析、互联网广告系统监控以及网络监控等。
Druid目前已经有很多公司用于实时计算和实时OLAP，而且效果很好。
缺点：配置和查询都比较复杂和繁琐，不支持SQL或类SQL接口。
解决痛点：在高并发环境下，保证海量数据查询分析性能，同时又提供海量实时数据的查询、分析与可视化功能。
Apache Druid 具有以下特点：
亚秒级 OLAP 查询，包括多维过滤、Ad-hoc 的属性分组、快速聚合数据等等。
实时的数据消费，真正做到数据摄入实时、查询结果实时。
高效的多租户能力，最高可以做到几千用户同时在线查询。
扩展性强，支持 PB 级数据、千亿级事件快速处理，支持每秒数千查询并发。
极高的高可用保障，支持滚动升级。
实时数据分析是 Apache Druid 最典型的使用场景。该场景涵盖的面很广，例如：实时指标监控、推荐模型、广告平台、搜索模型。
这些场景的特点都是拥有大量的数据，且对数据查询的时延要求非常高。在实时指标监控中，系统问题需要在出现的一刻被检测到并被及时给出报警。在推荐模型中，用户行为数据需要实时采集，并及时反馈到推荐系统中。用户几次点击之后系统就能够识别其搜索意图，并在之后的搜索中推荐更合理的结果。
3、大数据查询的三种分类
大数据查询目前来讲可以大体分为三类：
1.基于hbase预聚合的，比如Opentsdb,Kylin,Druid等,需要指定预聚合的指标，在数据接入的时候根据指定的指标进行聚合运算，适合相对固定的业务报表类需求，只需要统计少量维度即可满足业务报表需求
2.基于Parquet列式存储的，比如Presto, Drill，Impala等，基本是完全基于内存的并行计算，Parquet系能降低存储空间，提高IO效率，以离线处理为主，很难提高数据写的实时性，超大表的join支持可能不够好。spark sql也算类似，但它在内存不足时可以spill disk来支持超大数据查询和join
3.基于lucene外部索引的，比如ElasticSearch和Solr,能够满足的的查询场景远多于传统的数据库存储，但对于日志、行为类时序数据，所有的搜索请求都也必须搜索所有的分片，另外，对于聚合分析场景的支持也是软肋。
大数据查询三类再解：
MPP架构的系统（Presto/Impala/SparkSQL/Drill等）有很好的数据量和灵活性支持，但是对响应时间是没有保证的。当数据量和计算复杂度增加后，响应时间会变慢，从秒级到分钟级，甚至小时级都有可能。
搜索引擎架构的系统（Elasticsearch等）相对比MPP系统，在入库时将数据转换为倒排索引，采用Scatter-Gather计算模型，牺牲了灵活性换取很好的性能，在搜索类查询上能做到亚秒级响应。但是对于扫描聚合为主的查询，随着处理数据量的增加，响应时间也会退化到分钟级。
预计算系统（Druid/Kylin等）则在入库时对数据进行预聚合，进一步牺牲灵活性换取性能，以实现对超大数据集的秒级响应。
没有一个引擎能同时在数据量，灵活性和性能这三个方面做到完美，用户需要基于自己的需求进行取舍和选型。