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等）則在入庫時對數據進行預聚合，進一步犧牲靈活性換取性能，以實現對超大數據集的秒級響應。
沒有一個引擎能同時在數據量，靈活性和性能這三個方面做到完美，用戶需要基於自己的需求進行取捨和選型。