10億數(shù)據(jù)量的即席查詢 spark 和 kylin的對比

    數(shù)據(jù)量大約在10億+，需要做一個即席查詢，用戶可以主動輸入搜索條件，如時間。可提供一定的預處理時間。每天還有新數(shù)據(jù)加入。

    10億+的數(shù)據(jù)對于普通的rdbms還是有些壓力的，而且數(shù)據(jù)每天還在不停的增長，所以我們運用了我們的spark技術來做一個計算加速。關于增量更新的相關，我會在后續(xù)的博客中介紹。

語句如下

select count(*) a,b from table_a where c = '20170101' group by a,b order by a

首先用我們的spark-local模式進行測試數(shù)據(jù)量成倍上漲。

    我們可以看到單核cpu的性能也會影響spark的性能，所以在衡量一個spark集群的計算性能時，不光要看有幾個core，幾個instance，還要看單個core的計算能力，而且數(shù)據(jù)量越大，差距也越大。

    spark-sql有一個特點，同樣的語句，第二，第三次計算會比之前快，如果不停地運行同一個語句，你會發(fā)現(xiàn)時間會成下降趨勢直到一個穩(wěn)定值，一般為2-3次后會達到最小值，在10億這個級別上，在yarn模式下，運行3次左右后，性能可以達到3s左右，對于一個測試用的小集群已經(jīng)很讓人滿意了，如果是正規(guī)的spark集群，相信性能還會好很多，做即席查詢完全夠用了。個人理解是spark會有一定的緩存機制，但是不會緩存在多的東西，這個和之后要講的Kylin還是不同的。kylin如果是同樣的語句，第二次絕對是秒出。

下面我們嘗試了用Kylin，效果很讓人震撼。

Kylin官網(wǎng)如下

http://kylin.apache.org/

Apache Kylin是一個開源的分布式分析引擎，提供Hadoop之上的SQL查詢接口及多維分析（OLAP）能力以支持超大規(guī)模數(shù)據(jù)，最初由eBay Inc. 開發(fā)并貢獻至開源社區(qū)。它能在亞秒內(nèi)查詢巨大的Hive表。

Kylin中國唯一Apache頂級項目。支持下哦

Kylin是基于Hive表的，所以我們還是要將我們的數(shù)據(jù)先導入到hive中去。

Kylin的安裝在這里就不將了，很簡單，官網(wǎng)有介紹，啟動下服務就可以了。然后打開7070端口

要使用Kylin計算，我們要先建立Model，一個model需要對應一張hive表，然后再model的基礎上建立cube，這里我們創(chuàng)建一個默認的cube即可。

在Model頁面我們可以看我們創(chuàng)建的cube如下圖所示。

在列表中我們可以看到cube大小，記錄數(shù)，上次構建時間等信息。

build好cube后就可以查詢了，如果build成功cube的狀態(tài)會變?yōu)镽EADY，這時就可以查詢了。

還是用之前的3節(jié)點的集群做性能測試

如上圖所示，我們在查詢界面可以看到這個語句走了哪個project，cubes，耗時等信息

測試結果如下

    這里到5億的時候構建cube可以成功，但是運行sql會報錯。應該是我沒配置好。

    可以看到，kylin的查詢性能還是非?？捎^的，而且查詢時的資源消耗非常少，這點和spark不一樣，由于這樣的特性相對于spark，同樣性能的集群上kylin就可以支持高得多的并發(fā)，并且提供高得多的查詢性能，但是kylin的代價是很長的構建cube的時間和更多的磁盤占用，而且據(jù)我的經(jīng)驗來看，kylin對sql的支持不如spark-sql支持的好。如果要把原來rdbms的查詢遷移到大數(shù)據(jù)集群中來，spark-sql的適應性會更好。

    雖然kylin也支持增量構建，但是相對于spark來說，數(shù)據(jù)準備的時間還是會長很多，因為spark也支持增量更新。如果允許有數(shù)據(jù)預處理時間的，例如把構建放到晚上12:00過后進行，在這種場景下，kylin也許更適合.但是如果需要數(shù)據(jù)實時變化，而且維度很多，sql完全不確定的情況，也許spark-sql更合適一些，具體怎么選擇，還要看應用場景。