開源大數據OLAP引擎對比

 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所有項目裏唯一中國人爲主的頂級項目,社區非常活躍和熱心,有非常多的中國工程師。


發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章