presto、druid、sparkSQL、kylin的對比分析，如效能、架構等，有什麼異同？

作者：iseeyou
連結：https://www.zhihu.com/question/41541395/answer/114798939
來源：知乎
著作權歸作者所有。商業轉載請聯絡作者獲得授權，非商業轉載請註明出處。

這幾個框架都是OLAP大資料分析比較常見的框架，各自特點如下：presto：facebook開源的一個java寫的分散式資料查詢框架，原生整合了Hive、Hbase和關係型資料庫，Presto背後所使用的執行模式與Hive有根本的不同，它沒有使用MapReduce，大部分場景下比hive快一個數量級，其中的關鍵是所有的處理都在記憶體中完成。Druid：是一個實時處理時序資料的Olap資料庫，因為它的索引首先按照時間分片，查詢的時候也是按照時間線去路由索引。spark SQL：基於spark平臺上的一個olap框架，本質上也是基於DAG的MPP， 基本思路是增加機器來平行計算，從而提高查詢速度。kylin：核心是Cube，cube是一種預計算技術，基本思路是預先對資料作多維索引，查詢時只掃描索引而不訪問原始資料從而提速。這幾種框架各有優缺點，存在就是合理，如何選型個人看法如下：從成熟度來講：kylin>spark sql>Druid>presto從超大資料的查詢效率來看：Druid>kylin>presto>spark sql從支援的資料來源種類來講：presto>spark sql>kylin>Druid大資料查詢目前來講可以大體分為三類：1.基於hbase預聚合的，比如Opentsdb,Kylin,Druid等,需要指定預聚合的指標，在資料接入的時候根據指定的指標進行聚合運算，適合相對固定的業務報表類需求，只需要統計少量維度即可滿足業務報表需求2.基於Parquet列式儲存的，比如Presto, Drill，Impala等，基本是完全基於記憶體的平行計算，Parquet系能降低儲存空間，提高IO效率，以離線處理為主，很難提高資料寫的實時性，超大表的join支援可能不夠好。spark sql也算類似，但它在記憶體不足時可以spill disk來支援超大資料查詢和join3.基於lucene外部索引的，比如ElasticSearch和Solr,能夠滿足的的查詢場景遠多於傳統的資料庫儲存，但對於日誌、行為類時序資料，所有的搜尋請求都也必須搜尋所有的分片，另外，對於聚合分析場景的支援也是軟肋

據我不完全收集，包括：商業系統InfoBrightGreenplum（已開源）、HP Vertica、TeraData、Palo、ExaData、RedShift、BigQuery（Dremel）開源實現Impala、Presto、Spark SQL、Drill、HawqDruid、PinotKylin其中你列的presto、druid、sparkSQL、kylin可以分為三類。其中presto和spark sql都是解決分散式查詢問題，提供SQL查詢能力，但資料載入不一定能保證實時。Druid是保證資料實時寫入，但查詢上不支援SQL，或者說目前只支援部分SQL，我個人覺得適合用於工業大資料，比如一堆感測器實時寫資料的場景。Kylin是MOLAP，就是將資料先進行預聚合，然後把多維查詢變成了key-value查詢。這裡要看你實際要應用於什麼場景了。

作者：桑文鋒
連結：https://www.zhihu.com/question/41541395/answer/91709171
來源：知乎
著作權歸作者所有。商業轉載請聯絡作者獲得授權，非商業轉載請註明出處。

作者：吳鏑
連結：https://www.zhihu.com/question/41541395/answer/130713893
來源：知乎
著作權歸作者所有。商業轉載請聯絡作者獲得授權，非商業轉載請註明出處。

簡單說幾句。
1. kylin 預計算。使用者指定dimensions和要計算的metric，kylin通過MR將結果儲存在HBase中，後續讀取直接讀HBase。適合那種業務清楚的知道自己要分析什麼的場景。查詢模式比較固定，只不過所檢視的時間不同的場景。注意的點是要避免維度災難。

2. presto java8寫的，程式碼質量非常高。設計：純記憶體，沒有容錯，一個task失敗就整個query fail。需要注意調整記憶體相關，執行緒數等引數，容易OOM。benchmark還行。支援標準SQL

3. spark sql 個人覺得支援查詢Hive的資料，支援HQL非常重要，因為很多公司以前的資料都是放在Hive上的。我們測試了spark sql 2.0.1，對於鄙司這種分割槽數很多，每個分割槽很多parquet檔案的情形來說，幾乎不可用，原因在於 [SPARK-16980] Load only catalog table partition metadata required to answer a query 轉而測試spark sql 2.1.0， 結果還是比較滿意的。不過容錯性還有待檢驗，benchmark過程中如果個別task失敗，job 有時候會hang住，待分析。

其他沒用過不評價。

總體來說，至少從我們的benchmark結果來看，spark sql 很有前景。