背景: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ù)。(有時候重刷不行,必須要刪除才行)