10億數據量的即席查詢 spark 和 kylin的對比

    數據量大約在10億+，須要作一個即席查詢，用戶能夠主動輸入搜索條件，如時間。可提供必定的預處理時間。天天還有新數據加入。

    10億+的數據對於普通的rdbms仍是有些壓力的，並且數據天天還在不停的增加，因此咱們運用了咱們的spark技術來作一個計算加速。關於增量更新的相關，我會在後續的博客中介紹。

語句以下

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

首先用咱們的spark-local模式進行測試數據量成倍上漲。

數據量	table_a的倍數	spark-local i3 ddr3 8g	spark-local i7 ddr4 32g	spark-yarn 5g,3core 3instance
800w	1	0.512s	0.4	0.771
1600w	2	0.512s	0.5	0.552
3200w	4	0.794s	0.68	0.579
6400w	8	1.126s	0.945	0.652
1億2800w	16	1.968s	1.4	0.922
2億5600w	32	3.579s	2.574	1.475
5億1200w	64	6.928s	5.001	3.384
10億2400w	128	13.395s	9.528	5.372

    咱們能夠看到單核cpu的性能也會影響spark的性能，因此在衡量一個spark集羣的計算性能時，不光要看有幾個core，幾個instance，還要看單個core的計算能力，並且數據量越大，差距也越大。

    spark-sql有一個特色，一樣的語句，第二，第三次計算會比以前快，若是不停地運行同一個語句，你會發現時間會成降低趨勢直到一個穩定值，通常爲2-3次後會達到最小值，在10億這個級別上，在yarn模式下，運行3次左右後，性能能夠達到3s左右，對於一個測試用的小集羣已經很讓人滿意了，若是是正規的spark集羣，相信性能還會好不少，作即席查詢徹底夠用了。我的理解是spark會有必定的緩存機制，可是不會緩存在多的東西，這個和以後要講的Kylin仍是不一樣的。kylin若是是一樣的語句，第二次絕對是秒出。

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

Kylin官網以下

http://kylin.apache.org/

Apache Kylin是一個開源的分佈式分析引擎，提供Hadoop之上的SQL查詢接口及多維分析（OLAP）能力以支持超大規模數據，最初由eBay Inc. 開發並貢獻至開源社區。它能在亞秒內查詢巨大的Hive表。

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

Kylin是基於Hive表的，因此咱們仍是要將咱們的數據先導入到hive中去。

Kylin的安裝在這裏就不將了，很簡單，官網有介紹，啓動下服務就能夠了。而後打開7070端口

要使用Kylin計算，咱們要先創建Model，一個model須要對應一張hive表，而後再model的基礎上創建cube，這裏咱們建立一個默認的cube便可。

在Model頁面咱們能夠看咱們建立的cube以下圖所示。

在列表中咱們能夠看到cube大小，記錄數，上次構建時間等信息。

build好cube後就能夠查詢了，若是build成功cube的狀態會變爲READY，這時就能夠查詢了。

仍是用以前的3節點的集羣作性能測試

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

測試結果以下

數據量	構建時間（全量）	sql時間
800w	6.5min	0.15s
1億2800w	48min	0.15s
2億5600w	90.17min	0.15s
5億1200w	142.40min	執行錯誤

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

    能夠看到，kylin的查詢性能仍是很是可觀的，並且查詢時的資源消耗很是少，這點和spark不同，因爲這樣的特性相對於spark，一樣性能的集羣上kylin就能夠支持高得多的併發，而且提供高得多的查詢性能，可是kylin的代價是很長的構建cube的時間和更多的磁盤佔用，並且據個人經驗來看，kylin對sql的支持不如spark-sql支持的好。若是要把原來rdbms的查詢遷移到大數據集羣中來，spark-sql的適應性會更好。

    雖然kylin也支持增量構建，可是相對於spark來講，數據準備的時間仍是會長不少，由於spark也支持增量更新。若是容許有數據預處理時間的，例如把構建放到晚上12:00事後進行，在這種場景下，kylin也許更適合.可是若是須要數據實時變化，並且維度不少，sql徹底不肯定的狀況，也許spark-sql更合適一些，具體怎麼選擇，還要看應用場景。