//
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已經成為大數據事實上的標準規范，一大批工具陸陸續續圍繞Hadoop平臺來構建，用來解決不同場景下的需求。
讓我們來想想有哪些業務需求呢？
比如Hive是基于Hadoop的一個用來做企業數據倉庫的工具，可以將存儲在HDFS分布式文件系統上的數據文件映射為一張數據庫表，并提供SQL查詢功能，Hive執行引擎可以將SQL轉換為MapReduce任務來進行運行，非常適合數據倉庫的數據分析。
再比如HBase是基于Hadoop，實現高可用性，高性能，面向列，可伸縮的分布式存儲系統，Hadoop架構中的HDFS為HBase提供了高可靠性的底層存儲支持。
但是缺少一個基于Hadoop的分布式分析引擎，雖然目前存在業務分析工具，如Tableau等，但是他們往往存在很大的局限，比如難以水平擴展、無法處理超大規模數據，同時也缺少Hadoop的支持。
ApacheKylin的出現，能夠基于Hadoop很好地解決上面的問題。Apache Kylin是一個開源的分布式存儲引擎。它提供Hadoop之上的SQL查詢接口及多維分析（OLAP）能力以支持大規模數據，能夠處理TB乃至PB級別的分析任務，能夠在亞秒級查詢巨大的Hive表，并支持高并發。
大數據多維分析的挑戰
在Apache Kylin集群上跑了多個Cube測試，結果表明它能夠有效解決大數據計算分析的三大痛點問題：
ApacheKylin從數據倉庫中最常用的Hive中讀取源數據，使用 MapReduce作為Cube構建的引擎，并把預計算結果保存在HBase中，對外暴露Rest API/JDBC/ODBC的查詢接口。
核心:預計算
Apache Kylin的核心思想是預計算，即對多維分析可能用到的度量進行預計算，將計算好的結果保存成 Cube，供查詢時直接訪問。把高復雜度的聚合運算、多表連接等操作轉換成對預計算結果的查詢，這決定了Kylin能夠擁有很好的快速查詢和高并發能力。
上圖所示就是一個Cube的例子，假設我們有4個dimension，這個Cube中每個節點（稱作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有良好的快速響應和高并發。
有了這些預計算的結果，當收到用戶的SQL請求，Kylin會對SQL做查詢計劃，并把本該進行的Join、Sum、CountDistinct等操作改寫成Cube的查詢操作。
Cube查詢
查詢時，SQL語句被SQL解析器翻譯成一個解釋計劃，從這個計劃可以準確知道用戶要查哪些表，它們是怎樣join起來，有哪些過濾條件等等。Kylin會用這個計劃去匹配尋找合適的Cube。
如果有Cube命中，這個計劃會發送到存儲引擎，翻譯成對存儲(默認HBase)相應的Scan操作。Groupby和過濾條件的列，用來找到 Cuboid，過濾條件會被轉換成Scan的開始和結束值，以縮小Scan的范圍; Scan的result，Rowkey會被反向解碼成各個dimension的值，Value會被解碼成Metrics值 。
Apache Kylin****項目實踐
目前基于kylin的數據分析平臺已經在業務中開始測試以及使用，并且在用戶管理和權限操作方面做了的二次開發改造，以實現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相關參數調優：可以通過GC調優獲得更好的GC性能，減少單次GC的時間和FULL GC頻率。
使用Apache Kylin的實踐總結
1、大的事實表采用天分區增量構建，為了不影響查詢性能，可以定期做合并(Merge)，周期可以根據實際情況確定。
2、對于維表比較大的情況，或者查詢Select部分存在復雜的邏輯判斷，存在Apache Kylin不支持的函數或語句時，可以將事實表和維表的關聯處理創建為Hive視圖，之后根據視圖創建Cube模型。
3、每次查詢必然帶有的條件建議在字典設置步驟將其設置為Mandatory。這樣會最終 Build出來Cube的大小會減少一半。
4、Cube的維度如果超過10個，建議將常用的聚合字段做分組。
5、Cube定義中RowKey順序：Mandatory維度，Where過濾條件中出現頻率較多的維度，高基數維度，低基數維度。
6、當Segment中某一個Cuboid的大小超過一定的閾值時，修改數據分片大小以實現數據讀取的并行化，從而優化Cube的查詢速度。
7、設計合適的維度編碼能減少維度對空間的占用，比如對于高基數的維度如果使用Dict字典編碼方式占用大量空間，容易造成構建引擎或查詢引擎的內存溢出。
8、對維度進行分片，如果Cuboid中某兩個行的Shard by Dimension的值相同，那么無論這個Cuboid最終會被劃分多少個分片，這兩行數據必然會被分配到同一個分片中，方便查詢和索引。
9、部署層面，可以通過Nginx在前端做負載均衡，后端啟動多個Query Server接收查詢請求處理。
基于Kylin的前景規劃
經過項目的摸索和實踐，Apache Kylin能很好的解決開篇所說的大數據計算分析的3大痛點問題，提升業務的查詢效率。
首先，在接下來我們也將會持續關注Kylin的發展變化，包括數據字典的分布式構建以及基于Kafka定義Streaming Table，從而完成準實時Cube的構建的特性。
其次，規劃設計符合需求的拖拽前臺界面，支持探索性數據查詢。采用拖拽式方便用戶使用；規定化前臺界面，屏蔽后臺技術細節，避免低效的查詢出現。
在目前的工作基礎上規劃構建基于Apache Kylin的大數據OLAP分析平臺， 如下圖所示：
最后還將繼續調研和分析新的存儲引擎和構建引擎來滿足更多的業務需求。
