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 衍生维度

• 适用范围：使用维度表时，可以将维度表的字段设置为衍生维度。
• 原理：衍生维度不参加预计算，在底层记录维度表主键与维度表其他维度之间的映射关系，在查询的时候可以进行动态翻译得到非主键id并进行实时聚合
• 注意项：只在维表维度中可用，另外如果主键到某个维度所需要的聚合工作量非常大，也不建议用衍生维度。如日期主键映射到年份等
• 优化效率：每个衍生维度可以减少一半的cuboid

2.2 聚合组

• 适用场景：根据业务场景，可以划分出具有强依赖的组合。

• 原理

  
  
  image.png

• 根据业务的维度组合，划分出具有强依赖的组合，这些组合称之为聚合组，在聚合组内，维度之间的组合会预计算，聚合组之间并不交叉预计算，从而减少Cuboid的数量

2.3 必需维度

• 适用场景：如果某个维度在所有查询中都会作为group by或者where的条件，可以把他设置为必需维度，通常情况下会设置日期为必需维度。

2.4 层级维度

• 适用场景：维度之间有层级关系，比如 国家(A)->省份(B)->城市(C)

  
  
  image.png

• 优化效率：2^n -> n+1

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 写并发优化

• 原理：构建cube时，最终是将文件写入到hbase中，此时一个文件对应一个并发度，文件划分越小，并发度则越高。
• 对应参数：kylin.storage.hbase.hfile-size-gb

4. row_key优化

4.1 row_key顺序

• row_key中字段的顺序对于查询非常重要，因为hbase的查询最终依赖的是对row_key的scan,

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

• 有可能作为查询的过滤条件的维度放在前面

  • 多个可能作为过滤条件的维度，基数高的（作为过滤条件时可以过滤更多数据）更适合放前面
  • 公式： 得分 = 维度出现在过滤条件中的频率 * 作为过滤条件时尅过滤的数据记录数

• 经常出现在查询中的维度放在不经常出现的维度前面，这样在需要进行后聚合的场景中查询效率会更高

• 不会出现在查询中的维度，按照其基数的高低，低基数的放在后面：在逐层构建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

• 适用范围：分析场景主要集中在某个维度的topN时。

5. cube planner

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