//
【微學(xué)堂】大數(shù)據(jù)多維分析引擎在MEIZU的實(shí)踐
http://mp.weixin.qq.com/s?src=3×tamp=1486433778&ver=1&signature=na0ytajPH-136OH6OuYhCpd5mKGJzLdNOWunnkPssO1KQxFA69YhoGqkMO9K7tLYhFR8Pb5x2XrgAYsUjWimIThmrrSMHXd9GEH21xUrK91yydHRp52nQWhrqANCOECY3vYnV60MTgJpWDfL4imhlljOo--rqq2IYpujGwEhs=
我是來(lái)自魅族科技的趙天爍，今晚跟大家分享apache kylin在魅族的一些實(shí)踐。
閑話不多說(shuō)我就直接進(jìn)入正題了~
相信群里的各位同學(xué)應(yīng)該都是對(duì)數(shù)據(jù)庫(kù)技術(shù)感興趣的，apache kylin作為大數(shù)據(jù)分析引擎這一塊近年來(lái)崛起的新星已經(jīng)受到越來(lái)越多人的關(guān)注。我今天的內(nèi)容主要分為以下幾個(gè)方面：
Kylin的基本 **介紹 **
Kylin核心概念和特性
** Kylin **在魅族的應(yīng)用案例（場(chǎng)景+優(yōu)化實(shí)踐）
在大數(shù)據(jù)的時(shí)代，越來(lái)越多的企業(yè)開(kāi)始使用Hadoop管理數(shù)據(jù)，但是現(xiàn)有的業(yè)務(wù)分析工具（如Tableau，Microstrategy等）往往存在很大的局限，如難以水平擴(kuò)展、無(wú)法處理超大規(guī)模數(shù)據(jù)、缺少對(duì)Hadoop的支持；Kylin就是為了解決這些問(wèn)題而設(shè)計(jì)的。Apache Kylin，中文名麒（shen）麟（shou） 是Hadoop動(dòng)物園的重要成員。Apache Kylin是一個(gè)開(kāi)源的分布式分析引擎，最初由eBay的幾位華人工程師開(kāi)發(fā)貢獻(xiàn)至開(kāi)源社區(qū)，這也是它取名麒麟的一個(gè)重要原因，kylin是為數(shù)不多的由華人貢獻(xiàn)至apache社區(qū)并能夠成為頂級(jí)項(xiàng)目的。它提供Hadoop之上的SQL查詢(xún)接口及多維分析（OLAP）能力以支持大規(guī)模數(shù)據(jù)，能夠處理TB乃至PB級(jí)別的分析任務(wù)，能夠在亞秒級(jí)查詢(xún)巨大的Hive表，并支持高并發(fā)。
[圖片上傳中。。。（1）]
Apache Kylin于2014年10月在github開(kāi)源，并很快在2014年11月加入Apache孵化器，于2015年11月正式畢業(yè)成為Apache頂級(jí)項(xiàng)目，也成為首個(gè)完全由中國(guó)團(tuán)隊(duì)設(shè)計(jì)開(kāi)發(fā)的Apache頂級(jí)項(xiàng)目。于2016年3月，Apache Kylin核心開(kāi)發(fā)成員創(chuàng)建了Kyligence公司，力求更好地推動(dòng)項(xiàng)目和社區(qū)的快速發(fā)展。
Apache Kylin于2014年10月在github開(kāi)源，并很快在2014年11月加入Apache孵化器，于2015年11月正式畢業(yè)成為Apache頂級(jí)項(xiàng)目，也成為首個(gè)完全由中國(guó)團(tuán)隊(duì)設(shè)計(jì)開(kāi)發(fā)的Apache頂級(jí)項(xiàng)目。于2016年3月，Apache Kylin核心開(kāi)發(fā)成員創(chuàng)建了Kyligence公司，力求更好地推動(dòng)項(xiàng)目和社區(qū)的快速發(fā)展。
Kyligence是一家專(zhuān)注于大數(shù)據(jù)分析領(lǐng)域創(chuàng)新的數(shù)據(jù)科技公司，提供基于Apache Kylin的企業(yè)級(jí)智能分析平臺(tái)及產(chǎn)品，以及可靠、專(zhuān)業(yè)、源碼級(jí)的商業(yè)化支持；并推出Apache Kylin開(kāi)發(fā)者培訓(xùn)，頒發(fā)全球唯一的Apache Kylin開(kāi)發(fā)者認(rèn)證證書(shū)。
這里插一句題外話，在做分析引擎選型的時(shí)候，除了項(xiàng)目本身的成熟度之外，社區(qū)的活躍度和是否有一家商業(yè)公司在背后推動(dòng)一直是我的一個(gè)重要的選擇標(biāo)準(zhǔn)，商業(yè)化公司在開(kāi)源技術(shù)的組織，標(biāo)準(zhǔn)化，推廣等各個(gè)方面都能夠彌補(bǔ)社區(qū)的不足之處
剛才對(duì)kylin做了一些基本的背景介紹，接下來(lái)，我們來(lái)逐步深入的探究一下kylin究竟是如何能夠做到在PB級(jí)的數(shù)據(jù)量下提供亞秒級(jí)的查詢(xún)響應(yīng)的
首先，為了更好的適應(yīng)大數(shù)據(jù)環(huán)境，Kylin從數(shù)據(jù)倉(cāng)庫(kù)中最常用的Hive中讀取源數(shù)據(jù)，使用 MapReduce作為Cube構(gòu)建的引擎，并把預(yù)計(jì)算結(jié)果保存在HBase中，對(duì)外暴露Rest API/JDBC/ODBC的查詢(xún)接口。因?yàn)镵ylin支持標(biāo)準(zhǔn)的ANSI SQL，所以可以和常用分析工具（如Tableau、Excel等）進(jìn)行無(wú)縫對(duì)接。
Kylin的架構(gòu)圖
簡(jiǎn)單來(lái)說(shuō)，Kylin的核心思想是預(yù)計(jì)算，即對(duì)多維分析可能用到的度量進(jìn)行預(yù)計(jì)算，將計(jì)算好的結(jié)果保存成Cube，供查詢(xún)時(shí)直接訪問(wèn)。把高復(fù)雜度的聚合運(yùn)算、多表連接等操作轉(zhuǎn)換成對(duì)預(yù)計(jì)算結(jié)果的查詢(xún)，這決定了Kylin能夠擁有很好的快速查詢(xún)和高并發(fā)能力。
下面我們聊一聊kylin的一些基本原理
上圖所示就是一個(gè)Cube的例子，假設(shè)我們有4個(gè)dimension，這個(gè)Cube中每個(gè)節(jié)點(diǎn)（稱(chēng)作Cuboid）都是這4個(gè)dimension的不同組合，每個(gè)組合定義了一組分析的dimension（如group by），measure的聚合結(jié)果就保存在這每個(gè)Cuboid上。查詢(xún)時(shí)根據(jù)SQL找到對(duì)應(yīng)的Cuboid，讀取measure的值，即可返回。
算法優(yōu)點(diǎn)
此算法充分利用了MapReduce的能力，處理了中間復(fù)雜的排序和洗牌工作，故而算法代碼清晰簡(jiǎn)單，易于維護(hù)；
受益于Hadoop的日趨成熟，此算法對(duì)集群要求低，運(yùn)行穩(wěn)定；在內(nèi)部維護(hù)Kylin的過(guò)程中，很少遇到在這幾步出錯(cuò)的情況；即便是在Hadoop集群比較繁忙的時(shí)候，任務(wù)也能完成。
算法缺點(diǎn)
當(dāng)Cube有比較多維度的時(shí)候，所需要的MapReduce任務(wù)也相應(yīng)增加；由于Hadoop的任務(wù)調(diào)度需要耗費(fèi)額外資源，特別是集群較龐大的時(shí)候，反復(fù)遞交任務(wù)造成的額外開(kāi)銷(xiāo)會(huì)相當(dāng)可觀；
由于Mapper不做預(yù)聚合，此算法會(huì)對(duì)Hadoop MapReduce輸出較多數(shù)據(jù); 雖然已經(jīng)使用了Combiner來(lái)減少?gòu)腗apper端到Reducer端的數(shù)據(jù)傳輸，所有數(shù)據(jù)依然需要通過(guò)Hadoop MapReduce來(lái)排序和組合才能被聚合，無(wú)形之中增加了集群的壓力;
對(duì)HDFS的讀寫(xiě)操作較多：由于每一層計(jì)算的輸出會(huì)用做下一層計(jì)算的輸入，這些Key-Value需要寫(xiě)到HDFS上；當(dāng)所有計(jì)算都完成后，Kylin還需要額外的一輪任務(wù)將這些文件轉(zhuǎn)成HBase的HFile格式，以導(dǎo)入到HBase中去；這些頻繁的對(duì)HDFS的讀寫(xiě)操作都是使得Cube構(gòu)建的整體時(shí)間變長(zhǎng)的重要原因
總體而言，該算法雖然簡(jiǎn)單清晰易于維護(hù)，但是效率較低，尤其是當(dāng)Cube維度數(shù)較大的時(shí)候。
[圖片上傳中。。。（2）]
Fast Cubing是1.5之后的版本新增的一種cube構(gòu)建方式，最大化利用Mapper端的CPU和內(nèi)存，對(duì)分配的數(shù)據(jù)塊，將需要的組合全都做計(jì)算后再輸出給Reducer； 由Reducer再做一次合并（merge），從而計(jì)算出完整數(shù)據(jù)的所有組合。如此，經(jīng)過(guò)一輪Map-Reduce就完成了以前需要N輪的Cube計(jì)算
[圖片上傳中。。。（3）]
這種算法還有另外一個(gè)優(yōu)點(diǎn)，如上圖所示：第一步會(huì)計(jì)算Base Cuboid（所有維度都有的組合），再基于它計(jì)算減少一個(gè)維度的組合。
基于parent節(jié)點(diǎn)計(jì)算child節(jié)點(diǎn)，可以重用之前的計(jì)算結(jié)果；當(dāng)計(jì)算child節(jié)點(diǎn)時(shí)，需要parent節(jié)點(diǎn)的值盡可能留在內(nèi)存中； 如果child節(jié)點(diǎn)還有child，那么遞歸向下，所以它是一個(gè)深度優(yōu)先遍歷。當(dāng)有一個(gè)節(jié)點(diǎn)沒(méi)有child，或者它的所有child都已經(jīng)計(jì)算完，這時(shí)候它就可以被輸出，占用的內(nèi)存就可以釋放。
如果內(nèi)存夠的話，可以多線程并行向下聚合。如此可以最大限度地把計(jì)算發(fā)生在Mapper這一端，一方面減少shuffle的數(shù)據(jù)量，另一方面減少Reducer端的計(jì)算量。
接下來(lái)我們看一下kylin是如何存儲(chǔ)這些cube的數(shù)據(jù)的
[圖片上傳中。。。（4）]
MapReduce的計(jì)算結(jié)果最終保存到HBase中，HBase中每行記錄的Rowkey由dimension組成，measure會(huì)保存在column family中。為了減小存儲(chǔ)代價(jià)，這里會(huì)對(duì)dimension和measure進(jìn)行編碼。查詢(xún)階段，利用HBase列存儲(chǔ)的特性就可以保證Kylin有良好的快速響應(yīng)和高并發(fā)。
有了這些預(yù)計(jì)算的結(jié)果，當(dāng)收到用戶(hù)的SQL請(qǐng)求，Kylin會(huì)將SQL轉(zhuǎn)換成查詢(xún)計(jì)劃（Apache calcite），把本該進(jìn)行的Join、Sum、Count Distinct等操作改寫(xiě)成HBase的get和scan的查詢(xún)操作。
[圖片上傳中。。。（5）]
相比于很多其他開(kāi)源分析引擎只開(kāi)放出來(lái)一個(gè)基于console的簡(jiǎn)單交互入口的內(nèi)核相比，kylin把一個(gè)集成了簡(jiǎn)單web-IDE，cube創(chuàng)建編輯，building過(guò)程監(jiān)控和管理、系統(tǒng)配置、權(quán)限管理的一個(gè)相對(duì)完善的管理界面都打包在了kylin的開(kāi)源發(fā)布包中，這使得上手使用kylin會(huì)變得非常簡(jiǎn)單。
[圖片上傳中。。。（6）]
Kylin提供了一套基于完整的REST API，并且支持符合ANSI SQL標(biāo)準(zhǔn)的語(yǔ)法以及JDBC、ODBC的驅(qū)動(dòng)，這樣我們可以非常方便的將現(xiàn)有的應(yīng)用切換到kylin上面來(lái)，如果有需要的，可以使用kylin的REST API把cube的構(gòu)建過(guò)程集成到我們自己的內(nèi)部平臺(tái)當(dāng)中去，這些緊靠行業(yè)標(biāo)準(zhǔn)的選擇也是kylin能夠快速躥紅的一個(gè)重要原因
不那么新的新特性---Parallel Scan
[圖片上傳中。。。（7）]
1.5之后的一個(gè)版本中，kylin對(duì)HBase存儲(chǔ)結(jié)構(gòu)進(jìn)行了調(diào)整，將大的Cuboid分片存儲(chǔ)，將線性掃描改良為并行掃描?；谏先f(wàn)查詢(xún)進(jìn)行了測(cè)試對(duì)比結(jié)果顯示，分片的存儲(chǔ)結(jié)構(gòu)能夠極大提速原本較慢的查詢(xún)5-10倍，但對(duì)原本較快的查詢(xún)提速不明顯，綜合起來(lái)平均提速為2倍左右
實(shí)驗(yàn)中的feature終于轉(zhuǎn)正---Streaming Cubing
[圖片上傳中。。。（8）]
Kylin從1.5早期的版本中就開(kāi)始實(shí)驗(yàn)一種Streaming Cubing的方式，當(dāng)時(shí)的實(shí)現(xiàn)方式無(wú)愧于實(shí)驗(yàn)feature的稱(chēng)號(hào)，我們也簡(jiǎn)單測(cè)試過(guò)，日常運(yùn)維各種問(wèn)題，mini-batch進(jìn)程crash、數(shù)據(jù)丟失、一但crash基本上就得重頭來(lái)過(guò)，數(shù)據(jù)不可能恢復(fù)，所以那時(shí)的streaming cubing還不是一個(gè)線上可用的狀態(tài)。
雖然看起來(lái)可以提高cube的構(gòu)建效率，大幅度提升數(shù)據(jù)的實(shí)時(shí)性，但是由于設(shè)計(jì)的不合理那時(shí)候還不能在生產(chǎn)中使用
最近在1.6中終于有一個(gè)看上去很美的streaming cubing實(shí)現(xiàn)了。新版用一個(gè)MR任務(wù)去跑每一個(gè)kafka分區(qū)，把kafka中的數(shù)據(jù)寫(xiě)入HDFS，之后就可以和從hive中build一樣使用通用kylin cube building過(guò)程了
[圖片上傳中。。。（9）]
這樣做有以下幾個(gè)好處
允許多個(gè)segment（一個(gè)segment就是hbase中存儲(chǔ)cube數(shù)據(jù)的一個(gè)片段）并發(fā)build
允許segment之間出現(xiàn)時(shí)間窗口重疊（很重要）
其他不那么新的新特性
支持精確的distinct計(jì)數(shù)（所有數(shù)據(jù)類(lèi)型）---1.5.3
支持針對(duì)不同的Project設(shè)置不同的MR job運(yùn)行隊(duì)列---1.5.3
Top N指標(biāo)支持多列g(shù)roup by ---1.5.3
主動(dòng)監(jiān)測(cè)OOM，將堆棧中的cuboid緩存到本地磁盤(pán)---1.5
查詢(xún)明細(xì)數(shù)據(jù)（RAW MEASURE）---1.5.2
支持Hive視圖作為lookup 表---1.5.2
綜上，如果大家想要在生產(chǎn)環(huán)境中使用kylin的話，推薦大家嘗試1.5以上的版本。
Why Kylin？
剛才聊的都是kylin的功能特性和設(shè)計(jì)，接下來(lái)看看我們?yōu)槭裁匆x擇kylin，或者說(shuō)kylin適合什么樣的場(chǎng)景？
1、平臺(tái)體系完善，成熟度高，部署簡(jiǎn)單，易用
2、在高并發(fā)訪問(wèn)下保持不錯(cuò)的性能，隨著數(shù)據(jù)量和維度組合的增長(zhǎng)，性能衰減也不會(huì)特別明顯
3、Cube模型的合理設(shè)計(jì)，可以減少人工配置 ETLjob的數(shù)量
4、可以在數(shù)據(jù)準(zhǔn)確度、存儲(chǔ)空間、性能之間靈活調(diào)整，找到最適合需求場(chǎng)景的平衡點(diǎn)
5、標(biāo)準(zhǔn)SQL語(yǔ)法+JDBC/ODBC驅(qū)動(dòng)可以很方便的和現(xiàn)有系統(tǒng)做集成
7、社區(qū)活躍，有Kyligence這樣的商業(yè)公司在背后推動(dòng)
8、支持準(zhǔn)實(shí)時(shí)的數(shù)據(jù)更新，未來(lái)有準(zhǔn)實(shí)時(shí)OLAP需求也可以復(fù)用kylin
9、底層基于已經(jīng)相對(duì)成熟的Hive、HBase，整體技術(shù)棧并不復(fù)雜，日常運(yùn)維成本低
hobo文庫(kù)本下面是Kylin的架構(gòu)圖應(yīng)用場(chǎng)景特征
我們總結(jié)了一下日常接入kylin的需求需要滿(mǎn)足的基本特征，這些描述都是基于我們自身的技術(shù)體系和需求的特點(diǎn)而決定的，僅供大家參考，并不是一定要這樣
I. 數(shù)據(jù)量大，同時(shí)對(duì)查詢(xún)性能有需求
數(shù)據(jù)量不大直接用mysql好了，對(duì)查詢(xún)性能沒(méi)有要求的可以用其他的諸如impala或者spark都可以
II. 數(shù)據(jù)實(shí)時(shí)性要求不高（目前最高到小時(shí)級(jí)更新）
只針對(duì)于非實(shí)時(shí)的cubing，Streaming cubing目前還在研究中，方案成熟后可以很大程度上提高實(shí)時(shí)性
III. 維度組合和查詢(xún)條件組合在可預(yù)見(jiàn)的范圍內(nèi)
由于Cube模型需要預(yù)先構(gòu)建，因此維度的組合和條件必須是可預(yù)見(jiàn)的，如果用戶(hù)傳入的維度building時(shí)沒(méi)有包含，自然是查詢(xún)報(bào)錯(cuò)了。對(duì)于查詢(xún)自由度過(guò)高的場(chǎng)景還是推薦用hive、spark或者impala
IV. 數(shù)據(jù)總量大，但條件掃描范圍不會(huì)太大的。
不適合需要大范圍模糊搜索排序的場(chǎng)景（類(lèi)似search），這類(lèi)場(chǎng)景自然是ES這類(lèi)搜索引擎的強(qiáng)項(xiàng)，kylin并不擅長(zhǎng)。
[圖片上傳中。。。（10）]
上圖中的性能指標(biāo)都是優(yōu)化后的，前期剛上線的時(shí)候也是經(jīng)歷了多倫的痛苦優(yōu)化。
先看看上面那個(gè)例子優(yōu)化前的狀態(tài)
優(yōu)化前：
Cube原始記錄 6億---一個(gè)月數(shù)據(jù)
build后的Cube Size 1.9T
單次查詢(xún)掃描一周數(shù)據(jù)，HBase頻繁超時(shí)，Region Server經(jīng)常被拖死，平均響應(yīng)時(shí)間近30s
維度基本上全選，mandory、維度繼承從來(lái)不用，結(jié)果如上。。Cube存儲(chǔ)空間相比原始數(shù)據(jù)膨脹了700倍，Hbase region server一天掛N次，運(yùn)維小哥苦不堪言。
優(yōu)化后：
活用Aggregation Groups
http://kylin.apache.org/blog/2016/02/18/new-aggregation-group/
將使用場(chǎng)景進(jìn)行分組，對(duì)應(yīng)不同的group
大基數(shù)維度創(chuàng)建單獨(dú)的group，盡量確認(rèn)需求，收縮條件組合范圍，include中只包含相關(guān)的維度
低基數(shù)的維度可以單獨(dú)建立一個(gè)group，加上必選條件維度，把低基數(shù)的維度都設(shè)置成Mandatory，這樣維度組合出現(xiàn)時(shí)kylin會(huì)靈活進(jìn)行內(nèi)存內(nèi)二次聚合，但因?yàn)檫@些維度基數(shù)都不大，對(duì)性能不會(huì)影響太多
二選一或多選一的條件維度不要包含在統(tǒng)一個(gè)group（比如崩潰時(shí)間和上傳時(shí)間）
同時(shí)有好幾個(gè)大基數(shù)group的話可以考慮每個(gè)group單獨(dú)建一個(gè)cube（避免cube膨脹，row key結(jié)構(gòu)也更合理）
kylin.query.mem.budget
Rowkey
有日期分區(qū)字段的，可以將日期轉(zhuǎn)成只包含變化范圍的數(shù)字：
比如原始格式是字符串的2016-07-15 12:31:25，只保留一個(gè)月的數(shù)據(jù)，同時(shí)查詢(xún)是按天維度group by 不關(guān)心小時(shí)分鐘可以把日期轉(zhuǎn)成yyMMdd ，160715，這樣可以極大的降低維度基數(shù)
基數(shù)小的維度在前面
低基數(shù)的維度盡量用dict編碼（100w以?xún)?nèi)）
合理使用層級(jí)維度/派生維度
http://kylin.apache.org/docs15/howto/howto_optimize_cubes.html
Kev1nZ:優(yōu)化后效果
Cube build后大小降低到500G上下
50%的查詢(xún)性能在2s以?xún)?nèi)
Cube build時(shí)間縮短30%
本來(lái)希望整理一些streaming cubing的實(shí)踐和優(yōu)化相關(guān)的內(nèi)容，但是由于社區(qū)里的很多實(shí)踐最近變化比較大，還不太穩(wěn)定，以后等穩(wěn)定過(guò)之后再有機(jī)會(huì)可以一并交流。
好了，我今天分享的內(nèi)容就到這里，謝謝大家！
