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

12-30

在實際應用中如何選型？

謝謝邀請。你之列了這一領域的一部分，據我不完全收集，包括：

商業系統

InfoBright
Greenplum（已開源）、HP Vertica、TeraData、Palo、ExaData、RedShift、BigQuery（Dremel）

開源實現

Impala、Presto、Spark SQL、Drill、Hawq
Druid、Pinot
Kylin

其中你列的presto、druid、sparkSQL、kylin可以分為三類。其中presto和spark sql都是解決分散式查詢問題，提供SQL查詢能力，但數據載入不一定能保證實時。Druid是保證數據實時寫入，但查詢上不支持SQL，或者說目前只支持部分SQL，我個人覺得適合用於工業大數據，比如一堆感測器實時寫數據的場景。Kylin是MOLAP，就是將數據先進行預聚合，然後把多維查詢變成了key-value查詢。

這裡要看你實際要應用於什麼場景了。

這幾個框架都是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來支持超大數據查詢和join

3.基於lucene外部索引的，比如ElasticSearch和Solr,能夠滿足的的查詢場景遠多於傳統的資料庫存儲，但對於日誌、行為類時序數據，所有的搜索請求都也必須搜索所有的分片，另外，對於聚合分析場景的支持也是軟肋

簡單說幾句。

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 很有前景。

做過一些調研:

kylin 的團隊成員以國人為主，速度很有優勢，數據模型cube主要在演算法上做文章，將大量數據以固定的模式收斂再計算。

Presto 玩的更絕，全程在內存中倒騰，需要對各個步驟下對象數據規模做到完全精細的把控。

Druid 沒接觸過不做評論。

很明顯上面兩種對應用演算法會有一定的限制，建立在對已知演算法的深刻理解上。

Spark sql 相對更『原生『一些，單純的通用框架，和上面兩位並不是同一層面上的東西。

美團網曾調研了市面上主流的開源OLAP引擎，並做出了非常中肯的比較和應用場景分析。

【案例分享】Apache Kylin在美團點評的應用

部分引用如下：

MPP架構的系統（Presto/Impala/SparkSQL/Drill等）有很好的數據量和靈活性支持，但是對響應時間是沒有保證的。當數據量和計算複雜度增加後，響應時間會變慢，從秒級到分鐘級，甚至小時級都有可能。
搜索引擎架構的系統（Elasticsearch等）相對比MPP系統，在入庫時將數據轉換為倒排索引，採用Scatter-Gather計算模型，犧牲了靈活性換取很好的性能，在搜索類查詢上能做到亞秒級響應。但是對於掃描聚合為主的查詢，隨著處理數據量的增加，響應時間也會退化到分鐘級。
預計算系統（Druid/Kylin等）則在入庫時對數據進行預聚合，進一步犧牲靈活性換取性能，以實現對超大數據集的秒級響應。

沒有一個引擎能同時在數據量，靈活性和性能這三個方面做到完美，用戶需要基於自己的需求進行取捨和選型。

目前我們也正選型之中

一期的方案 vertica saiku +自己搞的前端一億數據 11維度 200指標秒查

需求都差不多海量數據（一億以上以下mysql搞）的統計匯總多維度數據分析

至少有幾種選擇

商用軟體 Vertica代表 1T內免費 SQL支持好我們目前就是直接通過方言連接saiku很好用

BDP等幾個公司就是搞的這個

開源分散式計算平台 Hadoop Spark 人員投入就多了吧（不推薦）而且我也覺得搞大數據就搞個統計計數都不好意思叫數據科學家

開源分析資料庫 Piont Kylin Druid 個人覺得個有個的麻煩比如kylin需要搞定cube定義同步

druid SQL的支持不是特別好雖然支持不過是否可以定義方言我還不確定

不過用json定義查詢連前端也超好用

一段別人的專業分析

========

使用Mysql，PostgreSQL等關係型資料庫，不僅用於業務查詢（OLTP），也做統計分析，一般是在現有業務資料庫上直接做一些分析需求。這種方式在數據量增長之後就會遇到性能問題，特別是分析查詢會對業務查詢產生極大影響。可以考慮把數據導入IndexR做分析，即把業務資料庫和分析資料庫分開。
ES，Solr等全文搜索資料庫用於統計分析場景。這類資料庫最大的特點是使用了倒排索引解決索引問題。對於統計分析場景通常沒有特別優化，在大數據量場景下內存和磁碟壓力比較大。如果遇到性能問題，或者數據量撐不住了，可以考慮使用IndexR。
Druid，Pinot等所謂時序資料庫。在查詢條件命中大量數據情況下可能會有性能問題，而且排序、聚合等能力普遍不太好，從我們的使用經驗來看運維比較困難，靈活性和擴展性不夠，比如缺乏Join、子查詢等。在保存大量歷史數據情況下需要的硬體資源相對昂貴。這種場景下可以考慮使用IndexR直接替換，不用擔心業務實現問題。
Infobright，ClickHose等列式資料庫。列式資料庫本身非常適合於OLAP場景，IndexR也屬於列式資料庫。最大的區別在於IndexR是基於Hadoop生態的。
離線預聚合，建Cube，結果數據存放於HBase等KV資料庫，如Kylin等。這種方式在只有多維分析場景且查詢比較簡單的情況下非常有效。問題就在於靈活性不足（flexibility），無法探索式分析，以及更複雜的分析需求。IndexR可以通過表配置達到預聚合的效果，並且聚合是實時，沒有延遲的；可以保留原始數據或者高維度數據，通過表路由決定具體的查詢表。
為了解決大數據量的即時分析問題，上層使用Impala，Presto，SparkSQL，Drill等計算引擎來做查詢，存儲層使用開源數據格式比如Parquet，基於Hadoop生態。這類架構和IndexR很相似。IndexR的優勢在於更有效的索引設計，更好的性能，並且支持實時入庫，秒級延遲。我們在相同環境下與Parquet格式做過查詢性能對比，IndexR的查詢速度提升在3~8倍以上。之後IndexR經歷了很大的性能優化，估計會有更好的表現。
Kudu，Phoenix等既支持OLTP場景，又為OLAP場景優化等開源產品。通常很難兩者兼顧，建議分成實時庫和歷史庫，針對不同數據特點採用不用的存儲方案。
內存資料庫。貴。

hadoop也算吧

說我用過的：

我覺得hive，spark sql和presto可以算一類，druid算另一類。

前面三個系統基本就是一個execution engine讓你用類似sql的語言或者jdbc去查詢存在hdfs上面的數據。你可以選擇數據在hdfs上面的儲存格式（最簡單的csv，json，或者更高級的parquet之類的columnar format）。區別：

hive基本沒有in memory caching，predicate push down的優化也一般。presto和spark sql新一些，caching和query optimistization比hive好，benchmark快很多。

spark sql是spark這個平台的一部分，所以除了query以外，可以直接在spark這個平台上輕鬆寫負責的data pipeline，減輕integration的麻煩。

presto本身只是sql execution engine，做data pipeline的時候還是要用spark之類的。不過如果很多人同時查詢的話，presto更快一些。

BI工具（tableau之類的）可以直接鏈接spark sql和presto。

Druid號稱能在幾秒的時間裡處理billion 行。這個實踐基本是能做到的。不過druid的問題是要它不能理解sql or jdbc，而是要用它自己一套語言寫query。所以用起來非常麻煩，周邊BI的支持非常差，我知道只有airbnb的superset支持druid。當然druid最新版0.10加了experimental的sql。是不是成熟還有待觀察。

我覺得想省事就用spark，整套analytics

pipeline都有了。

架構方面的東西上面幾位都說得很清楚了。選型其實還是看數據量和業務場景。不過以我的經歷來看應對大多數號稱要搞大數據的公司的數據量和業務場景，MySQL足矣...

就沖「實際應用中如何選型？」，就應該選sparksql，spark接近主流了，sql是數據分析必備技能。選sparksql穩定性可用性都強，而且可以更低成本的招到人。

玩花樣容易掉坑。這種大方向的選擇，錯一步毀一個團隊，耽誤一個公司。