經常使用OLAP引擎

 l  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全部項目裏惟一中國人爲主的頂級項目，社區很是活躍和熱心，有很是多的中國工程師。

Apache Kylin在美團數十億數據OLAP場景下的實踐 http://kyligence.io/2016/08/2016/