kylin 维度优化，Aggregation Group，Joint，Hierachy，Mandatory等解析

众所周知，Apache Kylin 的主要工作就是为源数据构建 N 个维度的 Cube，实现聚合的预计算。理论上而言，构建 N 个维度的 Cube 会生成 $2^n$个 Cuboid， 如图 1 所示，构建一个 4 个维度（A，B，C, D）的 Cube，需要生成 16 个Cuboid。

随着维度数目的增加，Cuboid 的数量会爆炸式地增长。为了缓解 Cube的构建压力，Apache Kylin 引入了一系列的高级设置，帮助用户筛选出真正需要的 Cuboid。这些高级设置包括聚合组（Aggregation Group）、联合维度（Joint Dimension）、层级维度（Hierachy Dimension）和必要维度（Mandatory Dimension）等。

聚合组（Aggregation Group）

用户根据自己关注的维度组合，可以划分出自己关注的组合大类，这些大类在 Apache Kylin 里面被称为聚合组。例如图 1 中展示的 Cube，如果用户仅仅关注维度 AB 组合和维度 CD 组合，那么该 Cube 则可以被分化成两个聚合组，分别是聚合组 AB 和聚合组 CD。如图 2 所示，生成的 Cuboid 数目从 16 个缩减成了 8 个。

用户关心的聚合组之间可能包含相同的维度，例如聚合组 ABC 和聚合组 BCD 都包含维度 B 和维度 C。这些聚合组之间会衍生出相同的 Cuboid，例如聚合组 ABC 会产生 Cuboid BC，聚合组 BCD 也会产生 Cuboid BC。这些 Cuboid不会被重复生成，一份 Cuboid 为这些聚合组所共有，如图 3 所示。

有了聚合组用户就可以粗粒度地对 Cuboid 进行筛选，获取自己想要的维度组合。

层级维度（Hierarchy Dimension）

用户选择的维度中常常会出现具有层级关系的维度。例如对于国家（country）、省份（province）和城市（city）这三个维度，从上而下来说国家／省份／城市之间分别是一对多的关系。也就是说，用户对于这三个维度的查询可以归类为以下三类:

• group by country
• group by country, province（等同于group by province）
• group by country, province, city（等同于 group by country, city 或者group by city）

以图 2 所示的 Cube 为例，假设维度 A 代表国家，维度 B 代表省份，维度 C 代表城市，那么ABC 三个维度可以被设置为层级维度，生成的Cube 如图 2 所示。

例如，Cuboid [A,C,D]=Cuboid[A, B, C, D]，Cuboid[B, D]=Cuboid[A, B, D]，因而 Cuboid[A, C, D] 和 Cuboid[B, D] 就不必重复存储。图 3 展示了 Kylin 按照前文的方法将冗余的Cuboid 剪枝从而形成图 2 的 Cube 结构，Cuboid 数目从 16 减小到 8。

案例分析
假设一个交易数据的 Cube，它具有很多普通的维度，像是交易的城市 city，交易的省 province，交易的国家 country， 和支付类型 pay_type等。分析师可以通过按照交易城市、交易省份、交易国家和支付类型来聚合，获取不同层级的地理位置消费者的支付偏好。在上述的实例中，建议在已有的聚合组中建立一组层级维度（国家country／省province／城市city），包含的维度和组合方式如图 4：

聚合组：[country, province, city，pay_type]
层级维度： [country, province, city]
Case 1 当分析师想从城市维度获取消费偏好时：
SELECT city, pay_type, count(*) FROM table GROUP BY city, pay_type 则它将从 Cuboid [country, province, city, pay_type] 中获取数据。
Case 2 当分析师想从省级维度获取消费偏好时：
SELECT province, pay_type, count(*) FROM table GROUP BY province, pay_type 则它将从Cuboid [country, province, pay_type] 中获取数据。
Case 3 当分析师想从国家维度获取消费偏好时：
SELECT country, pay_type, count(*) FROM table GROUP BY country, pay_type 则它将从Cuboid [country, pay_type] 中获取数据。
Case 4 如果分析师想获取不同粒度地理维度的聚合结果时：
无一例外都可以由图 3 中的 cuboid 提供数据 。
例如，SELECT country, city, count(*) FROM table GROUP BY country, city 则它将从 Cuboid [country, province, city] 中获取数据。

联合维度（Joint Dimension）

用户有时并不关心维度之间各种细节的组合方式，例如用户的查询语句中仅仅会出现 group by A, B, C，而不会出现 group by A, B 或者 group by C 等等这些细化的维度组合。这一类问题就是联合维度所解决的问题。例如将维度 A、B 和 C 定义为联合维度，Apache Kylin 就仅仅会构建 Cuboid ABC，而 Cuboid AB、BC、A 等等Cuboid 都不会被生成。最终的 Cube 结果如图 2 所示，Cuboid 数目从 16 减少到 4。

由于在hbase中只存在cubeid ABC，所以在查询是只能通过ADC来搜索cubeid， 例如设置联合维度： [cal_dt, city, sex_id]

SELECT cal_dt, city, sex_id, count(*) FROM table GROUP BY cal_dt, city, sex_id

则它将从Cuboid [cal_dt, city, sex_id]中获取数据

SELECT cal_dt, city, sex_id, count(*) FROM table GROUP BY cal_dt, city

遇到不存在的cubeid时，kylin会选择在线计算的方式，从现有的 Cuboid 中计算出最终结果。

必要维度（Mandatory Dimension）

用户有时会对某一个或几个维度特别感兴趣，所有的查询请求中都存在group by这个维度，那么这个维度就被称为必要维度，只有包含此维度的Cuboid会被生成（如图2）

以图 1中的Cube为例，假设维度A是必要维度，那么生成的Cube则如图3所示，维度数目从16变为9。

derived 衍生维度

如果是衍生维度的话，则必须是来自于某个维度表，由于这些列值都可以从该维度表的主键值中衍生出来，所以实际上只有主键列会被Cube加入计算。而在Kylin的具体实现中，往往采用事实表上的外键替代主键进行计算和存储。但是在逻辑上可以认为衍生列来自于维度表的主键。

参考：
http://cn.kyligence.io/blog/page/11/
Apache Kylin 权威指南 （链接：https://pan.baidu.com/s/1pLNxdpD 密码：ww7s）