//
Apache Kylin 大數(shù)據(jù)下的OLAP解決方案(原理篇)
http://mp.weixin.qq.com/s?__biz=MzI2MDU5ODY2Mg==&mid=2247483927&idx=1&sn=6697cde0bc54e1725da868c5cf52aeb0&chksm=ea667cfedd11f5e8803a6ee9ebc2444d515b7c18c641261f697d4ca341d1439ac3acca472240&mpshare=1&scene=1&srcid=0306oTHdHxhTi2IWYsK4Etr6#rd

**前言******

在現(xiàn)在的大數(shù)據(jù)時(shí)代，Hadoop已經(jīng)成為大數(shù)據(jù)事實(shí)上的標(biāo)準(zhǔn)規(guī)范，一大批工具陸陸續(xù)續(xù)圍繞Hadoop平臺(tái)來構(gòu)建，用來解決不同場(chǎng)景下的需求。
讓我們來想想有哪些業(yè)務(wù)需求呢？

比如Hive是基于Hadoop的一個(gè)用來做企業(yè)數(shù)據(jù)倉庫的工具，可以將存儲(chǔ)在HDFS分布式文件系統(tǒng)上的數(shù)據(jù)文件映射為一張數(shù)據(jù)庫表，并提供SQL查詢功能，Hive執(zhí)行引擎可以將SQL轉(zhuǎn)換為MapReduce任務(wù)來進(jìn)行運(yùn)行，非常適合數(shù)據(jù)倉庫的數(shù)據(jù)分析。

再比如HBase是基于Hadoop，實(shí)現(xiàn)高可用性，高性能，面向列，可伸縮的分布式存儲(chǔ)系統(tǒng)，Hadoop架構(gòu)中的HDFS為HBase提供了高可靠性的底層存儲(chǔ)支持。

但是缺少一個(gè)基于Hadoop的分布式分析引擎，雖然目前存在業(yè)務(wù)分析工具，如Tableau等，但是他們往往存在很大的局限，比如難以水平擴(kuò)展、無法處理超大規(guī)模數(shù)據(jù)，同時(shí)也缺少Hadoop的支持。
ApacheKylin的出現(xiàn)，能夠基于Hadoop很好地解決上面的問題。Apache Kylin是一個(gè)開源的分布式存儲(chǔ)引擎。它提供Hadoop之上的SQL查詢接口及多維分析（OLAP）能力以支持大規(guī)模數(shù)據(jù)，能夠處理TB乃至PB級(jí)別的分析任務(wù)，能夠在亞秒級(jí)查詢巨大的Hive表，并支持高并發(fā)。

大數(shù)據(jù)多維分析的挑戰(zhàn)

在Apache Kylin集群上跑了多個(gè)Cube測(cè)試，結(jié)果表明它能夠有效解決大數(shù)據(jù)計(jì)算分析的三大痛點(diǎn)問題：

核心:預(yù)計(jì)算

Apache Kylin的核心思想是預(yù)計(jì)算，即對(duì)多維分析可能用到的度量進(jìn)行預(yù)計(jì)算，將計(jì)算好的結(jié)果保存成 Cube，供查詢時(shí)直接訪問。把高復(fù)雜度的聚合運(yùn)算、多表連接等操作轉(zhuǎn)換成對(duì)預(yù)計(jì)算結(jié)果的查詢，這決定了Kylin能夠擁有很好的快速查詢和高并發(fā)能力。

上圖所示就是一個(gè)Cube的例子，假設(shè)我們有4個(gè)dimension，這個(gè)Cube中每個(gè)節(jié)點(diǎn)（稱作Cuboid）都是這4個(gè)dimension的不同組合，每個(gè)組合定義了一組分析的dimension（如group by），measure的聚合結(jié)果就保存在這每個(gè)Cuboid上。查詢時(shí)根據(jù)SQL找到對(duì)應(yīng)的Cuboid，讀取measure的值，即可返回。
Cube計(jì)算

Cube的構(gòu)建，Kylin提供了一個(gè)稱作Layer Cubing的算法。簡(jiǎn)單來說，就是按照dimension數(shù)量從大到小的順序，從Base Cuboid開始，依次基于上一層Cuboid的結(jié)果進(jìn)行再聚合。一個(gè)N維的完全Cube，是由：1個(gè)N維子立方體（Cuboid）， N個(gè)（N-1）維Cuboid, N*(N-1)/2個(gè)(N-2)維Cuboid …, N個(gè)1維Cuboid, 1個(gè)0維Cuboid，總共2^N個(gè)子立方體組成的，每一層的計(jì)算都是一個(gè)單獨(dú)的Map Reduce任務(wù)。如下圖所示：

此算法Mapper以上一層Cuboid的結(jié)果（Key-Value對(duì)）作為輸入。由于Key是由各維度值拼接在一起，從其中找出要聚合的維度，去掉它的值成新的Key，然后把新Key和Value輸出，進(jìn)而HadoopMapReduce對(duì)所有新Key進(jìn)行排序、洗牌（shuffle）、再送到Reducer處；Reducer的輸入會(huì)是一組有相同Key的Value集合，對(duì)這些Value做聚合計(jì)算，再結(jié)合Key輸出就完成了一輪計(jì)算。
由于Mapper不做預(yù)聚合，此算法會(huì)對(duì)Hadoop MapReduce輸出較多數(shù)據(jù); 雖然已經(jīng)使用了Combiner來減少?gòu)腗apper端到Reducer端的數(shù)據(jù)傳輸，所有數(shù)據(jù)依然需要通過Hadoop MapReduce來排序和組合才能被聚合，無形之中增加了集群的壓力。
快速Cube算法（Fast Cubing）

該算法的主要思想是，對(duì)Mapper所分配的數(shù)據(jù)塊，將它計(jì)算成一個(gè)完整的小Cube 段（包含所有Cuboid）；每個(gè)Mapper將計(jì)算完的Cube段輸出給Reducer做合并，生成大Cube，也就是最終結(jié)果，如下圖：

Mapper的預(yù)聚合：Mapper會(huì)利用內(nèi)存做預(yù)聚合，算出所有組合；Mapper輸出的每個(gè)Key都是不同的，這樣會(huì)減少輸出到Hadoop MapReduce的數(shù)據(jù)量，Combiner也不再需要；一輪MapReduce便會(huì)完成所有層次的計(jì)算，減少Hadoop任務(wù)的調(diào)配。
在Cuboid的推算過程中的每一步，F(xiàn)ast Cubing算法都會(huì)比逐層算法產(chǎn)生更少數(shù)據(jù)；總的加起來，新算法中的Mapper對(duì)Hadoop的輸出，會(huì)比老算法少一個(gè)或幾個(gè)數(shù)量級(jí)；越少的數(shù)據(jù)，意味著越少的I/O和CPU，從而使得性能得以提升。
Cube存儲(chǔ)

MapReduce的計(jì)算結(jié)果最終保存到HBase中，HBase中每行記錄的Rowkey由dimension組成，measure會(huì)保存在 column family中。為了減小存儲(chǔ)代價(jià)，這里會(huì)對(duì)dimension和measure進(jìn)行編碼。查詢階段，利用HBase列存儲(chǔ)的特性就可以保證Kylin有良好的快速響應(yīng)和高并發(fā)。

有了這些預(yù)計(jì)算的結(jié)果，當(dāng)收到用戶的SQL請(qǐng)求，Kylin會(huì)對(duì)SQL做查詢計(jì)劃，并把本該進(jìn)行的Join、Sum、CountDistinct等操作改寫成Cube的查詢操作。
Cube查詢

查詢時(shí)，SQL語句被SQL解析器翻譯成一個(gè)解釋計(jì)劃，從這個(gè)計(jì)劃可以準(zhǔn)確知道用戶要查哪些表，它們是怎樣join起來，有哪些過濾條件等等。Kylin會(huì)用這個(gè)計(jì)劃去匹配尋找合適的Cube。
如果有Cube命中，這個(gè)計(jì)劃會(huì)發(fā)送到存儲(chǔ)引擎，翻譯成對(duì)存儲(chǔ)(默認(rèn)HBase)相應(yīng)的Scan操作。Groupby和過濾條件的列，用來找到 Cuboid，過濾條件會(huì)被轉(zhuǎn)換成Scan的開始和結(jié)束值，以縮小Scan的范圍; Scan的result，Rowkey會(huì)被反向解碼成各個(gè)dimension的值，Value會(huì)被解碼成Metrics值 。

Apache Kylin****項(xiàng)目實(shí)踐

目前基于kylin的數(shù)據(jù)分析平臺(tái)已經(jīng)在業(yè)務(wù)中開始測(cè)試以及使用，并且在用戶管理和權(quán)限操作方面做了的二次開發(fā)改造，以實(shí)現(xiàn)project和cube的安全管理。
下圖是cube的查詢響應(yīng)圖表，cube 大小為157GB，包括一個(gè)事實(shí)表，14個(gè)維度和4個(gè)度量：

在項(xiàng)目實(shí)踐過程中也遇到問題：
Hadoop任務(wù)內(nèi)存資源不夠，cube計(jì)算失敗。

調(diào)整MapReduce分配資源參數(shù)：在cube計(jì)算過程中，會(huì)出現(xiàn)mr任務(wù)失敗，根據(jù)日志排查，主要因mr的內(nèi)存分配不足導(dǎo)致，于是，我們根據(jù)任務(wù)實(shí)際情況整體調(diào)整了yarn.nodemanager.resource.memory-mb、mapreduce.map.memory.mb、
mapreduce.map.java.opts、mapreduce.reduce.memory.mb、apreduce.reduce.java.opts
等參數(shù)。
JVMGC相關(guān)參數(shù)調(diào)優(yōu)：可以通過GC調(diào)優(yōu)獲得更好的GC性能，減少單次GC的時(shí)間和FULL GC頻率。

使用Apache Kylin的實(shí)踐總結(jié)

1、大的事實(shí)表采用天分區(qū)增量構(gòu)建，為了不影響查詢性能，可以定期做合并(Merge)，周期可以根據(jù)實(shí)際情況確定。
2、對(duì)于維表比較大的情況，或者查詢Select部分存在復(fù)雜的邏輯判斷，存在Apache Kylin不支持的函數(shù)或語句時(shí)，可以將事實(shí)表和維表的關(guān)聯(lián)處理創(chuàng)建為Hive視圖，之后根據(jù)視圖創(chuàng)建Cube模型。
3、每次查詢必然帶有的條件建議在字典設(shè)置步驟將其設(shè)置為Mandatory。這樣會(huì)最終 Build出來Cube的大小會(huì)減少一半。
4、Cube的維度如果超過10個(gè)，建議將常用的聚合字段做分組。
5、Cube定義中RowKey順序：Mandatory維度，Where過濾條件中出現(xiàn)頻率較多的維度，高基數(shù)維度，低基數(shù)維度。
6、當(dāng)Segment中某一個(gè)Cuboid的大小超過一定的閾值時(shí)，修改數(shù)據(jù)分片大小以實(shí)現(xiàn)數(shù)據(jù)讀取的并行化，從而優(yōu)化Cube的查詢速度。
7、設(shè)計(jì)合適的維度編碼能減少維度對(duì)空間的占用，比如對(duì)于高基數(shù)的維度如果使用Dict字典編碼方式占用大量空間，容易造成構(gòu)建引擎或查詢引擎的內(nèi)存溢出。
8、對(duì)維度進(jìn)行分片，如果Cuboid中某兩個(gè)行的Shard by Dimension的值相同，那么無論這個(gè)Cuboid最終會(huì)被劃分多少個(gè)分片，這兩行數(shù)據(jù)必然會(huì)被分配到同一個(gè)分片中，方便查詢和索引。
9、部署層面，可以通過Nginx在前端做負(fù)載均衡，后端啟動(dòng)多個(gè)Query Server接收查詢請(qǐng)求處理。

基于Kylin的前景規(guī)劃

經(jīng)過項(xiàng)目的摸索和實(shí)踐，Apache Kylin能很好的解決開篇所說的大數(shù)據(jù)計(jì)算分析的3大痛點(diǎn)問題，提升業(yè)務(wù)的查詢效率。
首先，在接下來我們也將會(huì)持續(xù)關(guān)注Kylin的發(fā)展變化，包括數(shù)據(jù)字典的分布式構(gòu)建以及基于Kafka定義Streaming Table，從而完成準(zhǔn)實(shí)時(shí)Cube的構(gòu)建的特性。
其次，規(guī)劃設(shè)計(jì)符合需求的拖拽前臺(tái)界面，支持探索性數(shù)據(jù)查詢。采用拖拽式方便用戶使用；規(guī)定化前臺(tái)界面，屏蔽后臺(tái)技術(shù)細(xì)節(jié)，避免低效的查詢出現(xiàn)。
在目前的工作基礎(chǔ)上規(guī)劃構(gòu)建基于Apache Kylin的大數(shù)據(jù)OLAP分析平臺(tái)， 如下圖所示：

最后還將繼續(xù)調(diào)研和分析新的存儲(chǔ)引擎和構(gòu)建引擎來滿足更多的業(yè)務(wù)需求。