背景：B公司，前美納斯上市公司，上億App用戶，近年來數(shù)據(jù)呈爆發(fā)式增長，每天行為日志達10T，原有的hive+mysql（查詢太慢，存儲太大），hive+impala（界面不友好，需要寫sql語言，門檻較高，不方便運營人員查詢數(shù)據(jù)，對多維數(shù)據(jù)查詢較慢），已經(jīng)滿足不了當下需求，急需要一個能支持大規(guī)模數(shù)據(jù)查詢，速度又快，使用零門檻的查詢服務，幾套方案選擇后，最終選擇了Kylin，主要看重的是它支持大規(guī)模數(shù)據(jù)快速查詢，而且是兼容我們現(xiàn)有Hadoop框架的，這對我們開發(fā)和使用來說成本很低。

基本情況：

2016年初，開始調研，上半年開始部署測試試用，截至17年底，生產(chǎn)環(huán)境每天cube要處理數(shù)據(jù)總條數(shù)為150億條，原始日志大小每天約450G（去重壓縮后），緯度16個,單表膨脹率在4%內，單表查詢60億條數(shù)據(jù)，延遲5秒返回結果。我們部署了kylin集群模式，一個all節(jié)點，3個query查詢服務節(jié)點（32G內存，8核cpu），Nginx實現(xiàn)負載均衡，hbase集群只用了10臺機器，所以很多數(shù)據(jù)只存了30天的。上線初期遇到很多問題，沒有達到預期效果，經(jīng)過慢慢優(yōu)化和實踐，運行2年了,現(xiàn)在運行比較穩(wěn)定，支撐了我們80%數(shù)據(jù)業(yè)務查詢需求，性能也基本符合我們的預期了。其實kylin部署安裝很簡單，主要是在cube設計優(yōu)化技巧方面需要花功夫。

?

查詢性能和cube性能優(yōu)化

我們剛開始也走過一些彎路，在創(chuàng)建cube的時候，不了解高級設置里的奧秘，配置的cube，運行時間非常長，膨脹率達300%，非常占用空間，前臺查詢沒有預想中那么快，經(jīng)過查詢文檔和實踐，我們對cube進行了一些優(yōu)化：

一、Aggregation Groups優(yōu)化

Includes : 表示需要參加group by 的維度，也是主要參與聚合的維度，業(yè)務需要經(jīng)常查詢顯示的字段可放這里。這里如果放太多字段，占用空間較大，預計算時間較長，膨脹率也較高。

Mandatory Dimensions ：高頻維度，必須要或經(jīng)常要用到的維度放在此地，會提高查詢速度。

Hierarchy Dimensions ：有層級關系的維度，如年、月、日

Joint Dimensions ：不常用到的維度放在此處，可以降低存儲和計算量。

?

16個維度，9個維度放在Includes里，3個維度放在Mandatory Dimensions里，4個放在Joint Dimensions里，膨脹率在2%內。

?

二、Rowkeys優(yōu)化

Rowkeys的順序對查詢性能有一定程度的影響，一般把過濾條件大的放在前面，如：時間，用戶類型等，不需要過濾的放后面：如手機機型，系統(tǒng)版本等，這樣做的目的是最大化先把查詢掃描范圍縮小，提高查詢速度。這些配置都對業(yè)務的了解和數(shù)據(jù)結構有一定的了解才行，因為最終都是為了業(yè)務查詢而設計的。

三、正確的Segment策略?

影響查詢速度的還有一個比較重要的因素是Segment的多少，如果你的數(shù)據(jù)是按日期增量更新，產(chǎn)生的Segment會越來越多，如果不進行定期合并，查詢的速度會因為數(shù)據(jù)量的增大而變慢，kylin的刷新設置里給我們提供了很好的策略，默認自動合并策略是7,28，代表的是每隔7天合并最近7天的Segment，每隔28天合并前面7天合并后的Segment，這樣做的目的是hbase表不會越來越多，前端查詢的時候也不用掃描那么多表了，如：7天內的數(shù)據(jù)掃描一個表就夠了，大大提升了查詢速度；另外一個是如果數(shù)據(jù)非常大，又不是非常重要，可以設置保留天數(shù)，比如只保留30天的構建數(shù)據(jù)，這樣Segment只有30天的記錄存在，這樣也不會使Segment越來越多，從而提高查詢速度。

集群模式更能提供查詢性能

剛開始我們也是單機模式，用一臺機器既做cube構建，同時又做查詢服務，在cube忙的時候，服務器內存和cpu非常高，這個時候查詢請求多的話，往往會造成查詢超時或失敗，嚴重影響前臺體驗，隔三差五收到產(chǎn)品、運營人員吐槽和投訴報表查詢失敗，迫于形勢壓力我們做了集群模式，目前集群模式是一臺all集群，3臺query服務器，用Nginx負載均衡，效果很明顯，all節(jié)點主要負載cube構建去了，查詢的請求被分攤到3臺query機器上，忙的時候也沒有出現(xiàn)過查詢超時或失敗的情況了。

Kylin集成Superset可視化展示平臺

搭建Superset（前身是caravel），Superset是用python寫的，安裝的時候會碰到各種環(huán)境和python包的問題，搭建好了Superset后，讓他支持kylin其實就很簡單了，只需安裝一個pykylin包就好了（這里感謝作者WuXiang，曉文兄的支持），這樣就支持kylin數(shù)據(jù)源了，當然我們還順便安裝了mysql驅動包，mysql和kylin數(shù)據(jù)源就都支持可視化數(shù)據(jù)查詢了。用superset的優(yōu)點就是圖形多樣性，并且支持維度和指標自由組合，拉取自己想要的數(shù)據(jù)保存為數(shù)據(jù)圖表，最后把把多個數(shù)據(jù)圖表放在一個頁面里，這樣每天只要打開這個頁面就可以看到自己想要的數(shù)據(jù)了。被運營和產(chǎn)品同事堪稱為周報、月報數(shù)據(jù)神器。

?

?

我們走過的彎路

1）Cube的設計不合理導致cube膨脹率高，構建時間長，占用空間大等問題，后來仔細研究了cube的高級設置和不段的測試，才有了現(xiàn)在的比較合理的配置。

2）內存不足，導致服務不穩(wěn)定，經(jīng)常被掛，kylin還是比較耗內存的，尤其當你要構建的數(shù)據(jù)量比較大的時候，所以我們后來配置了32G的內存服務器，KYLIN_JVM_SETTINGS的-Xmx23g配置了23G，基本就能滿足了。

3）Nginx負載均衡的時候，監(jiān)聽的端口號要對應好，因為我們自己封裝了kylin的jdbc查詢數(shù)據(jù)連接池，所以Nginx里的配置監(jiān)聽端口號的時候要跟這個連接池里面的url端口號一致，這個端口號不一定要7070，可以自己給一個其他的，只要能對應上就可以了。

平臺存在的問題：

1）cube設計完后，跑了數(shù)據(jù)之后就不能修改了，因為難免后面會加字段或修改配置什么的，這樣一次性的設計不是很人性化。

2)? 不能刪除任意SEGMENT，只能刪除最新的那個，不方便處理有問題的SEGMENT重新刷數(shù)據(jù)。（有時候重刷不行，必須要刪除才行）