kylin|kylin cube优化 kylincube优化

1. 查看相关统计 1.1 查看cuboid物化状态

命令：./kylin.sh org.apache.kylin.engine.mr.common.CubeStatsReader cube_name

文章图片
image.png

1.2 检查cube大小

文章图片
image.png

一般来说，膨胀率应控制在0-1000%，
- 膨胀率过高的原因分析：维度数量高且未进行剪枝
- 存在较高基维的维度，导致包含该维度的cuboid占用空间较大
- 存在占用空间的度量，如count distinct

1.3 时间和空间的平衡

所有能用cuboid的查询请求都可以通过base cuboid来处理，但是这样带来大量的聚合计算，kylin构建这么多cuboid就是为了适应不同的聚合计算。但是过多的cuboid又会导致构建速度慢空间占用多，例如：shrink值接近100%的，及时丢弃这个cuboid而使用父cuboid计算也不会产生更多的开销。

2. 剪枝优化

文章图片
image.png 2.1 衍生维度

2.2 聚合组

2.3 必需维度

2.4 层级维度

2.5 联合维度

适用场景：同时查询几个维度的场景，即某种维度组合要么一起出现，要么一起不出现，如o_city,d_city; 不常出现的多个维度可以设置为联合维度；基数比较小的多个维度可以设置为联合维度。
优化效率： 2^n ->2

3. 并发粒度优化 3.1 读并发优化

原理：每个segment对应一张hbase中的表，一张表可以对应多个region,这是region的个数就对应的是查询时的并发粒度，region切分越细，并发度越高。
对应参数：kylin.storage.hbase.region-cut-gb

3.2 写并发优化

4. row_key优化 4.1 row_key顺序

4.1.1 row_key的顺序遵循如下原则：

【kylin|kylin cube优化】有可能作为查询的过滤条件的维度放在前面
- 多个可能作为过滤条件的维度，基数高的（作为过滤条件时可以过滤更多数据）更适合放前面
- 公式：得分 = 维度出现在过滤条件中的频率 * 作为过滤条件时尅过滤的数据记录数
经常出现在查询中的维度放在不经常出现的维度前面，这样在需要进行后聚合的场景中查询效率会更高
不会出现在查询中的维度，按照其基数的高低，低基数的放在后面：在逐层构建cuboid时，kylin会优先选择rowkey后面的维度所在的cuboid来生成子coboid，那么基数越低的维度包含他的父cuboid的行数就越少，生成子cuboid的代价就越低。（例：101110 和101101 都可以构建出 101100，按kylin的设计，会选择101101来完成构建）

4.2 合适的维度编码

4.3 按维度分片

原理：默认cuboid的分片策略时哈希计算后随即分配的，按维度分片的意思是，当选择一个维度作为维度分片(如od_city)时，如果cuboid中的两行在该维度上相等，name这两行数据始终在一个分片中。这样在查询时，hbase为每个分片（region）开启一个coprocessor，coprocessor就能够在读取自身的分片数据做一定的预聚合，那么所有按照od_city分组的查询都会变得更加高效，因为每个分片都做了预聚合，分片返回的结果更少，查询引擎需要做的聚合操作也更少。
适用范围：高基围维度，并且数据分布相对均匀的，在大多数cuboid中都会出现的维度

4.4 top_N度量优化

原理：对特定维度（较高基维）的topN做预先计算topN的结果，当查询到来时，只用各个单元格中存储的topN个数据进行聚合得到结果返回。

文章图片
image.png

文章图片
image.png

5. cube planner

这是自kylin2.3提供的一个自动优化工具，在用户自定义的基础上进行进一步的自动优化，主要是两个阶段：
- 阶段1. 初次构建时，cube planner根据cube构建过程中的extract fact table distinct columns步骤中的采样数据，计算效益比（查询成本/物化该维度组合后对整个cube减少的的查询成本）
- 阶段2：对于已经运行一段时间的cube，根据历史统计的查询信息，几乎不被查询的cuboid会被删除（需要依赖于system cube）