Kylin权威指南没说清楚的事情——读《Kylin权威指南》后的一些思考和笔记

1. 引言

读《Kylin权威指南》后的一些思考和笔记。

 

2. 关于维度

2.1 维度表太大怎么办？

维度表会被加载到内存里，但前提是小于300M。互联网公司往往会有大维表，比如用户表，这时候正常构建会失败。对于这种类型的维表，早期有建议在Hive中事先把维度做到事实表里，现在只需要在Model的Dimension里把“Skip snapshot for this lookup table”这个地方钩上，那它就不会再走内存形式了。其副作用就是不能再使用Derived Dimension了，所有来自该维表的维度都会参与cuboid的生成。

2.2 normal 和 derived 维度如何选择，hierarchy和它们什么关系？

normal dimension是会参与预计算的，derived dimension则是通过维表加载到内存里，查询时计算的。这也是为什么上面说超大的维表不能被加载到内存里，也因此不能做derived dimension。Aggregation Groups中的层级关系hierarchy是针对normal维度处理的，它优化的是cuboid的数量，因此对derived dimension中存在的hierarchy是不考虑的。

2.3 Advanced  Setting中Aggregation Groups里的爱恨情仇

有几个维度都会出现在Where里，优化的时候是放Mandatory还是Joint呢？当然是Mandatory！Joint是可能同时出现，也可能同时不出现的。所以放Mandatory里比放Joint里少一半的cuboid。

Hierarchy直接被Derived Dimensions了，是不是效率不如设置Hierarchy？是的。因为Hierarchy是预计算，以空间换时间，而Derived Dimensions需要运行时计算。

总会在一起查询的维度放在Joint里很好理解，基数很低的维度被考虑成Joint是为什么呢？这里的基数很低，主要是指两个维度组合的基数比例。举个例子，月份的两个维度'201905'和'2019-05'以及'2019 May'这样的维度组合基数比都是1:1，这时把这三个维度放在一个joint里面就能将cuboid从2^N减少到2^(N-2)，因为这组维度由原来2^3变成了2^1。

2.4 Rowkeys的设计

Cube在HBase中产生的rowkey默认使用字典编码，将string映射成int。字典编码允许的基数上限默认是500万，超过500万就不能用字典编码了。编码优先选择整形，其次字典，最后才考虑固定长度这种并不转换的方式。

Rowkeys的设计顺序，先按过滤频率从高到低排列。同频率的情况下，按基数从高到低排列。因为基数高的，一旦过滤某个条件，剩下的数据量就会减少很多。

 

3. 关于增量构建

触发构建API下面都是用rebuild，然后在buildType中设置BUILD, MERGE, REFRESH。

Volatile Rage设置之后对Auto Merge Thresholds会进行叠加吗，比如都设置为7的情况下会怎么样呢？我们知道正常情况下Auto Merge Thresholds设置为7，当segment达到7个的时候会触发该7个segments合并。但是如果此时将Volatile Rage从0改成7的话，会先保留7个segments不合并的情况，然后再往前数，当满足7个segments也就是总共由14个的时候，才合并较早的7个。

 

4. 流式构建

Margin设置对应消息队列中可能的延迟。

 

5. 查询和可视化

JDBC的PreparedStatement是否比传SQL的API安全？从权限上来看的话，单个API目前可以提供project级别的四种权限，基本上够用了。封装一层JDBC的需求个人感觉并不强烈。

传SQL的API没有写权限，是否意味着只存在读泄漏的可能？是的，如果同时也没有删除权限的话。

 

6. Cube优化

6.1 检查Cuboid数量

bin/kylin.sh org.apache.kylin.engine.mr.common.CubeStatsReader CUBE_NAME

查看shrink 接近100%甚至大于100%的时候，考虑取消该cuboid。直接用它的前一个cuboid来满足需求，因为聚合度不高的cuboid存在的意义不大。

6.2 检查Cube大小

通常要求膨胀率小于1000%。超过1000%的时候要分析各维度的业务关系，考虑如何优化。

 

7 应用案例分析

TOP-N的度量，其背后是GROUP BY加ORDER BY，预聚合上会有什么措施吗？就目前来看，GROUP BY是预计算的，ORDER BY则是Kylin查询引擎实时处理的。

 

8 实战中遇到的问题

8.1 kylin一样的两个cube，构建出来是2个表吗？查数的时候会用哪个表出数据呢？官宣会使用Cost低的那个，目测用类似MicroStrategy的Logical Table Size机制。

8.2 measures不能放在where条件里，但是可以在GROUP BY之后放在having里。在此基础上增加一个外部的聚合，并不会引起太多性能问题。

8.3 维表有重复值的时候，会直接挂吗？应该不会，但是容易产生笛卡尔积。

8.4 Kylin构建中设置外部参数的方式，如hive参数mapjoin的设置方式：kylin.source.hive.config-override.hive.auto.convert.join