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

**前言******

在現在的大數據時代，Hadoop已經成為大數據事實上的標準規(guī)范惕橙，一大批工具陸陸續(xù)續(xù)圍繞Hadoop平臺來構建芙委，用來解決不同場景下的需求良哲。
讓我們來想想有哪些業(yè)務需求呢？

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

再比如HBase是基于Hadoop净宵，實現高可用性，高性能裹纳，面向列择葡，可伸縮的分布式存儲系統(tǒng)，Hadoop架構中的HDFS為HBase提供了高可靠性的底層存儲支持剃氧。

但是缺少一個基于Hadoop的分布式分析引擎刁岸，雖然目前存在業(yè)務分析工具，如Tableau等她我，但是他們往往存在很大的局限虹曙，比如難以水平擴展迫横、無法處理超大規(guī)模數據，同時也缺少Hadoop的支持酝碳。
ApacheKylin的出現矾踱，能夠基于Hadoop很好地解決上面的問題。Apache Kylin是一個開源的分布式存儲引擎疏哗。它提供Hadoop之上的SQL查詢接口及多維分析（OLAP）能力以支持大規(guī)模數據呛讲，能夠處理TB乃至PB級別的分析任務，能夠在亞秒級查詢巨大的Hive表返奉，并支持高并發(fā)贝搁。

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

在Apache Kylin集群上跑了多個Cube測試，結果表明它能夠有效解決大數據計算分析的三大痛點問題：

核心:預計算

Apache Kylin的核心思想是預計算膀哲，即對多維分析可能用到的度量進行預計算，將計算好的結果保存成 Cube被碗，供查詢時直接訪問某宪。把高復雜度的聚合運算、多表連接等操作轉換成對預計算結果的查詢锐朴，這決定了Kylin能夠擁有很好的快速查詢和高并發(fā)能力兴喂。

上圖所示就是一個Cube的例子，假設我們有4個dimension焚志，這個Cube中每個節(jié)點（稱作Cuboid）都是這4個dimension的不同組合瞻想，每個組合定義了一組分析的dimension（如group by），measure的聚合結果就保存在這每個Cuboid上娩嚼。查詢時根據SQL找到對應的Cuboid蘑险，讀取measure的值，即可返回岳悟。
Cube計算

Cube的構建佃迄，Kylin提供了一個稱作Layer Cubing的算法。簡單來說贵少，就是按照dimension數量從大到小的順序呵俏，從Base Cuboid開始，依次基于上一層Cuboid的結果進行再聚合滔灶。一個N維的完全Cube普碎，是由：1個N維子立方體（Cuboid）， N個（N-1）維Cuboid, N*(N-1)/2個(N-2)維Cuboid …, N個1維Cuboid, 1個0維Cuboid录平，總共2^N個子立方體組成的麻车，每一層的計算都是一個單獨的Map Reduce任務缀皱。如下圖所示：

此算法Mapper以上一層Cuboid的結果（Key-Value對）作為輸入。由于Key是由各維度值拼接在一起动猬，從其中找出要聚合的維度啤斗，去掉它的值成新的Key，然后把新Key和Value輸出赁咙，進而HadoopMapReduce對所有新Key進行排序钮莲、洗牌（shuffle）、再送到Reducer處彼水；Reducer的輸入會是一組有相同Key的Value集合崔拥，對這些Value做聚合計算，再結合Key輸出就完成了一輪計算凤覆。
由于Mapper不做預聚合链瓦，此算法會對Hadoop MapReduce輸出較多數據; 雖然已經使用了Combiner來減少從Mapper端到Reducer端的數據傳輸，所有數據依然需要通過Hadoop MapReduce來排序和組合才能被聚合叛赚，無形之中增加了集群的壓力。
快速Cube算法（Fast Cubing）

該算法的主要思想是稽揭，對Mapper所分配的數據塊俺附，將它計算成一個完整的小Cube 段（包含所有Cuboid）；每個Mapper將計算完的Cube段輸出給Reducer做合并溪掀，生成大Cube事镣，也就是最終結果，如下圖：

Mapper的預聚合：Mapper會利用內存做預聚合揪胃，算出所有組合璃哟；Mapper輸出的每個Key都是不同的，這樣會減少輸出到Hadoop MapReduce的數據量喊递，Combiner也不再需要随闪；一輪MapReduce便會完成所有層次的計算，減少Hadoop任務的調配骚勘。
在Cuboid的推算過程中的每一步铐伴，Fast Cubing算法都會比逐層算法產生更少數據；總的加起來俏讹，新算法中的Mapper對Hadoop的輸出当宴，會比老算法少一個或幾個數量級；越少的數據泽疆，意味著越少的I/O和CPU户矢，從而使得性能得以提升。
Cube存儲

MapReduce的計算結果最終保存到HBase中殉疼，HBase中每行記錄的Rowkey由dimension組成梯浪，measure會保存在 column family中捌年。為了減小存儲代價，這里會對dimension和measure進行編碼驱证。查詢階段延窜，利用HBase列存儲的特性就可以保證Kylin有良好的快速響應和高并發(fā)。

有了這些預計算的結果抹锄，當收到用戶的SQL請求逆瑞，Kylin會對SQL做查詢計劃，并把本該進行的Join伙单、Sum获高、CountDistinct等操作改寫成Cube的查詢操作。
Cube查詢

查詢時吻育，SQL語句被SQL解析器翻譯成一個解釋計劃念秧，從這個計劃可以準確知道用戶要查哪些表，它們是怎樣join起來布疼，有哪些過濾條件等等摊趾。Kylin會用這個計劃去匹配尋找合適的Cube。
如果有Cube命中游两，這個計劃會發(fā)送到存儲引擎砾层，翻譯成對存儲(默認HBase)相應的Scan操作。Groupby和過濾條件的列贱案，用來找到 Cuboid肛炮，過濾條件會被轉換成Scan的開始和結束值，以縮小Scan的范圍; Scan的result宝踪，Rowkey會被反向解碼成各個dimension的值侨糟，Value會被解碼成Metrics值 。

Apache Kylin****項目實踐

目前基于kylin的數據分析平臺已經在業(yè)務中開始測試以及使用瘩燥，并且在用戶管理和權限操作方面做了的二次開發(fā)改造秕重，以實現project和cube的安全管理。
下圖是cube的查詢響應圖表厉膀，cube 大小為157GB悲幅，包括一個事實表，14個維度和4個度量：

在項目實踐過程中也遇到問題：
Hadoop任務內存資源不夠站蝠，cube計算失敗汰具。

調整MapReduce分配資源參數：在cube計算過程中，會出現mr任務失敗菱魔，根據日志排查留荔，主要因mr的內存分配不足導致，于是，我們根據任務實際情況整體調整了yarn.nodemanager.resource.memory-mb聚蝶、mapreduce.map.memory.mb杰妓、
mapreduce.map.java.opts、mapreduce.reduce.memory.mb碘勉、apreduce.reduce.java.opts
等參數巷挥。
JVMGC相關參數調優(yōu)：可以通過GC調優(yōu)獲得更好的GC性能，減少單次GC的時間和FULL GC頻率验靡。

使用Apache Kylin的實踐總結

1倍宾、大的事實表采用天分區(qū)增量構建，為了不影響查詢性能胜嗓，可以定期做合并(Merge)高职，周期可以根據實際情況確定。
2辞州、對于維表比較大的情況怔锌，或者查詢Select部分存在復雜的邏輯判斷，存在Apache Kylin不支持的函數或語句時变过，可以將事實表和維表的關聯處理創(chuàng)建為Hive視圖埃元，之后根據視圖創(chuàng)建Cube模型。
3媚狰、每次查詢必然帶有的條件建議在字典設置步驟將其設置為Mandatory岛杀。這樣會最終 Build出來Cube的大小會減少一半。
4哈雏、Cube的維度如果超過10個楞件，建議將常用的聚合字段做分組衫生。
5裳瘪、Cube定義中RowKey順序：Mandatory維度，Where過濾條件中出現頻率較多的維度罪针，高基數維度彭羹，低基數維度。
6泪酱、當Segment中某一個Cuboid的大小超過一定的閾值時派殷，修改數據分片大小以實現數據讀取的并行化，從而優(yōu)化Cube的查詢速度墓阀。
7毡惜、設計合適的維度編碼能減少維度對空間的占用，比如對于高基數的維度如果使用Dict字典編碼方式占用大量空間斯撮，容易造成構建引擎或查詢引擎的內存溢出经伙。
8、對維度進行分片勿锅，如果Cuboid中某兩個行的Shard by Dimension的值相同帕膜，那么無論這個Cuboid最終會被劃分多少個分片枣氧，這兩行數據必然會被分配到同一個分片中，方便查詢和索引垮刹。
9达吞、部署層面，可以通過Nginx在前端做負載均衡荒典，后端啟動多個Query Server接收查詢請求處理酪劫。

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

經過項目的摸索和實踐，Apache Kylin能很好的解決開篇所說的大數據計算分析的3大痛點問題种蝶，提升業(yè)務的查詢效率契耿。
首先，在接下來我們也將會持續(xù)關注Kylin的發(fā)展變化螃征，包括數據字典的分布式構建以及基于Kafka定義Streaming Table搪桂，從而完成準實時Cube的構建的特性。
其次盯滚，規(guī)劃設計符合需求的拖拽前臺界面踢械，支持探索性數據查詢。采用拖拽式方便用戶使用魄藕；規(guī)定化前臺界面内列，屏蔽后臺技術細節(jié)，避免低效的查詢出現背率。
在目前的工作基礎上規(guī)劃構建基于Apache Kylin的大數據OLAP分析平臺话瞧， 如下圖所示：

最后還將繼續(xù)調研和分析新的存儲引擎和構建引擎來滿足更多的業(yè)務需求。