Kylin实战（六）—— Kylin Cube构建优化以及增量构建Cube_kylin 聚合组优化

Cube 构建优化方向：

减少业务中无用Cuboid构建，也就是剪枝， 我们知道在Kylin中一个指标的维度越多，那么他的Cuboid的数量就越多，假设有n个维度我们就会有2^n-1 个Cuboid，那么我们来思考一个问题，在实际应用中，指标的维度数量是非常多的，有的指标甚至几十个，那么我们来假设一下，假如现在有10个维度，那么我们就需要构建2^10-1 =1023个Cuboid，那么有20个呢？就会有（2^20-1）= 1048576个Cuboid，更多呢？如果全部构建出来我们可以想像但是这对我们的构建引擎（Kylin）和存储引擎（HBase）来说简直是在灾难。那么我们可不可以通过分析合理减少的一些不必要的Cuboid的维度组合呢？其实是可以的在Kylin中将这种方式称为剪枝（即减少Cuboid生成的个数），那么现在我们可能就会产生疑惑，你减少行吗？你假设我分析额维度你给我减少了我还怎么查呀，对不对？可能大家会有这样的疑问？但是在实际的使用中构建一些维度的组合对我们分析的指标来说是无用的，举一个不太恰当的例子帮大家理解，假设现在我们的一个指标中包含年月日这样三个维度，那么我们如果使用维度组合来分析指标我们是不是只会通过年月日、年月、月日、年、月、日这六种形式去分析啊，但是我们知道是那个维度一个是7个维度组合吧。其实还有一个年、日但是我们发现使用这个维度组合的Cuboid来分析指标却没有任何的意义对不对？所以我们减少Cuboid是减少的一些对指标分析无用的Cuboid，那么现在我们的优化方向就比较明确了就是剪枝，减少Cuboid中的无用的部分。

Cube 构建优化的几种方式：

1、使用衍生维度（derived dimension）（官网提供）

这是什么意思呢？这其实就是我们的星型模型中我们的事实表的外键其实就是各个维度表的主键，我们在构建Cube 的时候我们使用维度表中非主键的维度来组合Cuboid时可以省略非主键维度的方式就是使用衍生维度进行构建Cube优化。
那么问题来了，什么是衍生维度呢？其实通过刚才的说法我们就可以知道衍生维度就是指事实表的外键在维度表中对应的非主键的维度，说到这里大家可能会感觉稍微有一点模糊，为了让大家更好的理解我们可以来下面的图，我们来看

首先，我们还是图里的两张表不难看出第一张表是事实，第二张表是维度表，然后我们明确红色框表示的是维度，黄色框表示的是维度信息，接下来不知道大家还记不记得在我们构建Cube 的时候我们有这样的一个页面

1) Normal和Derived的选用

那么我们自什么情况下选用Normal什么情况下选用Derived呢
也就是说我们现在要考虑到如果使用Derived衍生维度这种方式，在查询的时候在重新聚合，我们应该考虑重新聚合工作量的大小，如果工作量的比较大我们还是选择Normal的方式来构建，如果聚合的工作量是不是很大，那么我们就可以使用Drived衍生维度的方式进行构建。我们在统计按时间年月日维度的年来统计指标的时候，在使用derived方式我们来构建Cube使用的是外键进行构建，那么我们在构建Cube的时候我们根据F（day）= year和F（day）= month使用其实我们是通过日期也就是年月日中的日进行构建的。这样在聚合的时候就需要聚合365天的数据就比较大了所以我们就不建议使用derived，而我们在按照月份统计的时候只需要集合30天左右的数据那么我们就可以选择使用derived，所以说我们在选择是否使用衍生维度应该考虑查询时的工作量。

2、使用聚合组

这个其实就和我们开始说的例子使用年月日维度去查询分析需求的时候，我们不会使用年日这种组合去查询相同。

什么是聚合组

按我的理解就是根据业务指标可以将我们构建的Cuboid的维度划分为具有强依赖的若干个组，说白了就是按照需求将维度分组，这些组合称为聚合组。在聚合组内，各维度之间的组合会预计算，但聚合组之间并不交叉预计算，从而减少Cuboid的数量。什么意思呢就是说同一个维度可以出现在多个聚集组中，但是build期间只会计算一次，需要注意的是聚合组的数量不不易过多。那么我们如何来定义那些维度是强依赖的呢？其实它是有三种定义方式的：

1）强制维度（Mandatory Dimensions）

什么意思呢？就是说一个维度被指定为强制维度，我们在构建Cuboid的时候只会是构建被指定了有强制维度关系的Cuboid，其他的我就不再构建，也就是构建出来的Cuboid必须含有强致维度，以此来达到剪枝的目的的呀，可能大家还是不理解，我们落实到我们实际业务中，就是被指定为强制维度的字段在查询时必须要在Group by之后，反过来理解就是在业务指标分析时不论怎么分析都需要分析的维度我们可以设置为强制维度，当然如果一个维度被定义为强制维度，在之后的查询中如果Group by中不出现设置为强制的维度他是一定会报错的。为了好理解我们来看一张图对比一下使用强制维度和不使用强制维度的区别：

2）层级维度

层级维度其实很好理解，层级维度就是类似我们说的像是年月日、洲国省市县区街道像这种有上下级关系的维度，那么层级维度在这里有什么用呢？还是用图表来解释这个问题。

3）联合维度

联合维度就更简单了，就是假设两个维度被指定为联合维度，那么这两个维度在组合是必须同时出现或者同时不出现，就像是被绑在一起一样，一荣俱荣。一损俱损的关系啊我们还是通过图来看：

那么联合维度有什么应用场景呢？就是我们在业务分析这两种或者多种维度肯定是样同时查的，那么这种情况我们就可以使用联合维度聚合组通过这三种方式就实现了剪枝（减少Cuboid的构建）这种聚合组优化方式其实是在构建Cube第五步进行的。

3、RowKey优化

其实Kylin使用HBase存储Cube，良好的Rowkey设计不仅对构建Cube，对查询速度来说也是一种极大的提升，说到RowKey大家还记得Cube的RowKey长啥样么？不记得的话我们就回去看一下3.Cube构建流程。

1）将用作过滤条件（where）的维度放在前边

这啥意思？那我们一起来看，其实很简单

2）基数大的维度放在基数小的维度的前边

那么基数是什么呢？基数其实就是一个维度所具有的所有不同值的个数，比如月份最多就12个，日最多就31天，星期最多也就7个星期值。
这个将基数大的放在基数小的前边比如月和日，按照这个逻辑就是将日放在前边将月放在后边，这个其实不是很好想我们来看

这个在哪里用呢其实也是在我们Kylin构建Cube的第五步使用的

4、并发粒度优化

并发粒度值得是谁的并发呢？其实他指的是我们在查询时HBase读取的并发度，要查询HBase那我们就要来看HBase中的表，我们知道HBase中的表它分为多个Region，对应于行式存储数据库其实Region对应了关系型数据库中的分区的概念。那么分为多个region有什么好处？是不是就和分区的好处类似，一个是扩展性一个是并发度呀，那么大家来思考一个问题我们开始向HBase中写数据的时候是几个Region呢？假设没有预分区的话。其实是不是就是一个region，当我们的数据越来越多达到我们设定的预值我们才能进行拆分呢？那么这个值是那个呀？其实在Kylin中我们也有这样一个值可以实现对HBase Region的控制。

1）通过增加region 切分增加并发力度

这个值就是"kylin.hbase.region.cut"，什么意思呢就是hbase表中一个Region达到多大后我给他进行拆分呢，其实这个参数的默认值是5G。也就是说一个Region达到5个G才会进行切分，这样显然是很困难的，降低切分的门槛我们可以将这个值设置的小一点1G或者0.5G就切分，这样是不是就增加了Region的数量，也提高了并发粒度。这也就是提高并发力度的一种方式。

2）通过设置Region的数量范围来控制并发粒度

Region的数量范围其实在Kylin中也是有两个参数来控制的分别是kylin.hbase.region.count.min（默认为1）（region最少有几个）和kylin.hbase.region.count.max（默认为500）（region最多有几个）
这是三个参数其实我们是在Cube设计的第六步进行配置的如下图所示：

增量构建Cube流程：

这里我们只说明增量构建和全量构建的不同之处，其他的地方不做多余的赘述。第一个不同点就是创建Model的第5步不能在省略此时需要进行配置

下面我们来看第二个不同点


接下来我们来看Kylin Cube构建算法