目錄
背景
瞭解OLAP Cube的人都會知道，建立cube的過程中往往會出現“維度爆炸”問題。Kylin是典型的Multidimensional OLAP應用，犧牲靈活性，使用預計算來提升性能，以實現對超大數據集的秒級響應。在Kylin建立cube的過程中，如果默認選擇所有維度的組合，那麼維度組合將是2^N（N爲維度個數）。
在工業領域，一般建立的寬表可能會有大幾十個的維度，甚至達到上百。但是平常使用的時候，也許只有不到一半的維度組合能超過20個維度。大部分維度組合的個數可能都是10多個。這樣一來，會造成存儲的極大浪費，也會影響Kylin的查詢性能。
Kylin的維度組合優化
kylin從1.5版本後引入了一個新的特性：聚合組（Aggregation Groups）。
如下是官網提出的兩種方法：
1、首先，我們可以移除那些不一定是維度的維度。例如，假設有一個日期查找表，其中保存的cal_dt是PK列，以及許多派生列，如week_begin_dt、month_begin_dt。儘管分析人員需要week_begin_dt作爲維度，但我們可以對它進行刪減，因爲它總是可以從維度cal_dt中計算出來，這就是“派生”優化。
2、其次，可以修剪聚合組之間的某些組合。這是本文的主要討論，我們稱之爲“組合修剪”。例如，如果將某個維度指定爲“強制”，則可以刪除所有沒有該維度的組合。如果維A，B，C形成“層次”關係，則僅保留與A，AB或ABC的組合。在v1.5之前，Kylin還具有“聚合組”概念，該概念也可用於組合修剪。但是，它的文獻記錄不多，很難理解（我也發現很難解釋）。無論如何，我們將跳過它，因爲我們將重新定義“聚合組”的真正含義。
下文主要講解第二種方法-----維度剪枝優化：
在kylin1.5之後，有四種類型的聚合組，每一種類型的聚合組也即是一種特定的規則。通過這四種規則來達到剪枝優化的目的。
1、 Mandatory維度
這種維度意味着每次查詢的group by中都會攜帶的，將某一個dimension設置爲mandatory可以將cuboid的個數減少一半，如下圖：
這是因爲我們確定每一次group by都會攜帶A，那麼就可以省去所有不包含A這個維度的cuboid了。
2、 hierarchy維度
這種維度是最常見的，尤其是在mondrian中，我們對於多維數據的操作經常會有上卷下鑽之類的操作，這也就需要要求維度之間有層級關係，例如國家、省、城市，年、季度、月等。有層級關係的維度也可以大大減少cuboid的個數。如下圖：
這裏僅僅侷限於A/B/C是一個層級，例如A是年份，B是季度、C是月份，那麼查詢的時候可能的組合只有年、xx年的季度、xx年xx季度的xx月，這就意味着我們不能再單獨的對季度和月份進行聚合了，例如我們查詢的時候不能使用group by month，而必須使用group by year，quart，month。如果需要單獨的對month進行聚合，那麼還需要再使用month列定義一個單獨的普通維度。
3、 derived維度
這類維度的意思是可推導的維度，需要該維度對應的一個或者多個列可以和維度表的主鍵是一對一的，這種維度可以大大減少cuboid個數，如下圖：
例如timeid是時間這個維度表的主鍵，也就是事實表的外鍵，時間只精確到天，那麼year、month、day三列可以唯一對應着一個time_id，而time_id是事實表的外鍵，那麼我們可以指定year、month、day爲一個derived維度，實際存儲的時候可以只根據timeid的取值決定維度的組合，但這就要求我們在查詢的時候使用的group by必須指定derived維度集合中的所有列。 3.聯合維度（Joint） 每一個聯合維度包括兩個或者更多的維度，聯合維度內的維度，要麼不出現，要麼必須一起出現。不同的聯合之間不應當有共同的維度
4、 聯合維度
聯合維度：將幾個維度視爲一個維度。 適用場景：
- 1 可以將確定在查詢時一定會同時使用的幾個維度設爲一個聯合維度。
- 2 可以將基數很小的幾個維度設爲一個聯合維度。
- 3 可以將查詢時很少使用的幾個維度設爲一個聯合維度。
優化效果：將N個維度設置爲聯合維度，則這N個維度組合成的cuboid個數會從2的N次方減少到1。
應用實例:
假設創建一個交易數據的Cube，它具有很多普通的維度，像是交易日期 cal_dt，交易的城市 city，顧客性別 sex_id 和支付類型 pay_type 等。分析師常用的分析方法爲通過按照交易時間、交易地點和顧客性別來聚合，獲取不同城市男女顧客間不同的消費偏好，例如同時聚合交易日期 cal_dt、交易的城市 city 和顧客性別 sex_id來分組。 聚合組：[cal_dt, city, sex_id，pay_type] 聯合維度： [cal_dt, city, sex_id]
Case 1：
SELECT cal_dt, city, sex_id, count(*) FROM table GROUP BY cal_dt, city, sex_id
則它將從Cuboid [cal_dt, city, sex_id]中獲取數據
複製代碼
Case2:
如果有一條不常用的查詢：
SELECT cal_dt, city, count(*) FROM table GROUP BY cal_dt, city
則沒有現成的完全匹配的 Cuboid，Apache Kylin 會通過在線計算的方式，從現有的 Cuboid 中計算出最終結果。
Kylin的Rowkey優化
1、編碼
Kylin 以 Key-Value 的方式將 Cube 存儲到 HBase 中，HBase 的 key，也就是 Rowkey，是由各維度的值拼接而成的；爲了更高效地存儲這些值，Kylin 會對它們進行編碼和壓縮；每個維度均可以選擇合適的編碼（Encoding）方式，默認採用的是字典（Dictionary）編碼技術；字段支持的基本編碼類型如下：
- dict：適用於大部分字段，默認推薦使用，但在超高基情況下，可能引起內存不足的問題；
- boolean：適用於字段值爲true, false, TRUE, FALSE, True, False, t, f, T, F, yes, no, YES, NO, Yes, No, y, n, Y, N, 1, 0；
- integer：適用於字段值爲整數字符，支持的整數區間爲[ -2^(8N-1), 2^(8N-1)]；
- date：適用於字段值爲日期字符，支持的格式包括yyyyMMdd、yyyy-MM-dd、yyyy-MM-dd HH:mm:ss、yyyy-MM-dd HH:mm:ss.SSS，其中如果包含時間戳部分會被截斷；
- time：適用於字段值爲時間戳字符，支持範圍爲[ 1970-01-01 00:00:00, 2038/01/19 03:14:07]，毫秒部分會被忽略，time編碼適用於 time, datetime, timestamp 等類型；
- fix_length：適用於超高基場景，將選取字段的前 N 個字節作爲編碼值，當 N 小於字段長度，會造成字段截斷，當 N 較大時，造成 RowKey 過長，查詢性能下降，只適用於 varchar 或 nvarchar 類型；
- fixed_length_hex：適用於字段值爲十六進制字符，比如 1A2BFF 或者 FF00FF，每兩個字符需要一個字節，只適用於 varchar 或 nvarchar 類型。
2、順序
各維度在 Rowkeys 中的順序，對於查詢的性能會產生較明顯的影響；在這裏用戶可以根據查詢的模式和習慣，通過拖曳的方式調整各個維度在Rowkeys上的順序。推薦的順序爲：Mandatory 維度、where 過濾條件中出現頻率較多的維度、高基數維度、低基數維度。這樣做的好處是，充分利用過濾條件來縮小在 HBase 中掃描的範圍，從而提高查詢的效率。
3、分片
指定 ShardBy 的列，明細數據將按照該列的值分片；沒有指定 ShardBy 的列，則默認將根據所有列中的數據進行分片；選擇適當的 ShardBy 列，可以使明細數據較爲均勻的分散在多個數據片上，提高並行性，進而獲得更理想的查詢效率；建議選擇基數較大的列作爲 ShardBy 列，以避免數據分散不均勻。
參考：
1、http://kylin.apache.org/blog/2016/02/18/new-aggregation-group/
2、https://juejin.im/post/5bd81eafe51d457b26679917#heading-25
3、https://juejin.im/post/5bd5c59851882565e031f4be#heading-17