KYLIN 建模设计学习总结

昨日Kyligence的老师对kylin建模进行了培训，基于Kyligence Cloud，除了界面以及商业特性，其他方式与开源版apache kylin 基本相同。

模型（model）

模型是一个语意层的设计，在数仓之上，各种BI工具之下。构建一个模型需要一张事实表，可以有多张维度表，并通过列进行inner\left join。

模型中的维度、度量，基本可以理解为描述事物的角度（地区、客户号），以及指标（身高、销量）。用来对应一种场景下的所有查询的可能性。

• 维度是从模型选取的表中的字段中部分选取、或全部选取。
• 度量是在表中字段选取的基础上，进行一定的聚合计算，例如sum、count、去重、top N.
• 可计算列是一种中间能力，处理底层数据未开发的，或者说不想修改历史设计时使用的，可以利用如case when 进行码值映射、区分范围的虚拟字段，在数仓中并不存在，但可给BI进行查询。

模型中对于维度字段的基数,释义大致是对于该字段的不重复值的数量（distinc count），其会影响构建聚合组时的膨胀率（预计算存储空间相对于原始数据的比例），当基数超过百万、甚至千万时，其对存储空间的影响会开始变得很大。

聚合组

聚合组相对于开源版本kylin应当是cube的概念。新增聚合组时，是从模型的维度中进行选取聚合组的纬度，并默认

对应n个维度产生

个索引（网上资料往往会说减一，实际上C n取n的索引也是存在的，就是其本身)。KYLIN为了减少对空间的浪费，默认配置中限制了一个聚合组索引上限为1000条，所以，达到10个维度就必须进行剪枝，否则会限制聚合组保存。【索引数在1000以内时，所需的存储空间基本处于线性增长，超过后会呈几何级增长】。

• 必需维度
  必需维度即每次查询中必然包含的维度，例如会计日期这样的字段 。勾选一个维度后，会使得不包含该维度的索引，以及该维度本身的一维索引不会再去生成。是一种结合业务的最有效的剪枝方式。有效降低膨胀率。
  
• 层级维度
  顾名思义，选中的维度存在层级关系，下层的维度存在时，上层维度必然存在，例如年-月这样的字段。这样勾选后，就会将包含“月”字段，但是未包含“年”字段的索引从组合中删除，完成剪枝。
  另外，万一存在查询层级维度断开的情况，比如查年-月-日这样的层级维度时，突然业务想要查一下今年每个月的第一天的销量，条件就为年-日，这种情况，由于当前聚合组中，一个维度只能使用一次，这个条件的查询如果真的有必要，就去新建一个聚合组，对其建立一个联合维度。
  
• 联合维度
  联合维度字面意思就是将这两个维度绑在一起，可以理解为一个联合维度中的维度往往在查询时会一起被查询到，不需要对单独维度列进行优化。联合维度与其他两个维度不同，它没有强业务关联，在使用必需维度、层级维度后，仍超过索引上限时，可以有一个利用数据特征的暴力优化的方式，将基数不大，看起来甚至也没有多少关联意义的维度进行组合，以此来减少索引数。（不要引入高基维）
  

另外，聚合组还有个设置：

• 最大维度组合数
  该值会限制进行组合产生索引的维度数的上线，例如设置为5,就不会产生维度在5个以上的维度组合产生的索引。
  

这种情况下生成的索引数会有很多，但是可能并不是所有的索引都是我们需要的，我们可以在生成后，单独对某一条索引进行删除。在生产运行一段时间后（按月为单位查看），可以对没有命中过的索引、命中次数少且消耗空间大（性价比低）的索引进行删除（这种情况它会命中比其少维度的父索引，并不会直接下压）。

其实，在挺多业务场景下，很少会基于一个维度、两个维度进行筛选查询，有些企业会通过调用kylin rest api进行定时扫描、删除。

查询优化

在聚合组的总结中，我有意仅写了关于如何在建立聚合组时如何减少存储空间的消耗，而实际上，用户关心的是查询的速度。那你可能要问了，建立聚合组索引，不就是用来预计算提高查询速度的吗？ 关于这点，我们可以类比以下普通的关系型数据库的索引。

• 区分度大的字段应该在索引中排在前，同样的基数大的维度，也应当排在前列。高频查询的字段，也应该往前挪动。
  
• 分片（shardBy）
  kylin将预计算数据存在hbase上，底层也是一个hdfs文件，出厂默认一个文件分片的大小为256M。在不设置分片列时，查询的小文件数多，可以去并发读取，当然这基于spark集群资源充裕时，查询速度是提升的，往往，老板也没那么大气。设置一个分片列，能有效去减少读取磁盘文件的次数，分片列建议设置为高频的筛选条件，当然，业务不明的情况下，暴力使用基数最大的列也是可取的（当然，我们要尽量保证数据不倾斜）。
  建议切片完成后，文件数量在200-300个，资源充足可以300-500个，使得扫描文件在两轮中可以完成。（曾经生产环境在读写分离前，资源抢占不到，一直没有去读取文件，导致查询缓慢，甚至麒麟返回超时、socket连接断开）。
  

明细索引

当前在企业版4.2、4.3中其效率并不高，方法论也和上面聚合组相似。期待其在v4.5接入clickhourse之后的提升了。