kylin|kylin cube优化

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

  • 命令:./kylin.sh org.apache.kylin.engine.mr.common.CubeStatsReader cube_name
    kylin|kylin cube优化
    文章图片
    image.png
1.2 检查cube大小
kylin|kylin cube优化
文章图片
image.png
  • 一般来说,膨胀率应控制在0-1000%,
    • 膨胀率过高的原因分析:维度数量高且未进行剪枝
    • 存在较高基维的维度,导致包含该维度的cuboid占用空间较大
    • 存在占用空间的度量,如count distinct
1.3 时间和空间的平衡
  • 所有能用cuboid的查询请求都可以通过base cuboid来处理,但是这样带来大量的聚合计算,kylin构建这么多cuboid就是为了适应不同的聚合计算。但是过多的cuboid又会导致构建速度慢空间占用多,例如:shrink值接近100%的,及时丢弃这个cuboid而使用父cuboid计算也不会产生更多的开销。
2. 剪枝优化 kylin|kylin cube优化
文章图片
image.png 2.1 衍生维度
  • 适用范围:使用维度表时,可以将维度表的字段设置为衍生维度。
  • 原理:衍生维度不参加预计算,在底层记录维度表主键与维度表其他维度之间的映射关系,在查询的时候可以进行动态翻译得到非主键id并进行实时聚合
  • 注意项:只在维表维度中可用,另外如果主键到某个维度所需要的聚合工作量非常大,也不建议用衍生维度。如日期主键映射到年份等
  • 优化效率:每个衍生维度可以减少一半的cuboid
2.2 聚合组
  • 适用场景:根据业务场景,可以划分出具有强依赖的组合。
  • 原理

    kylin|kylin cube优化
    文章图片
    image.png
  • 根据业务的维度组合,划分出具有强依赖的组合,这些组合称之为聚合组,在聚合组内,维度之间的组合会预计算,聚合组之间并不交叉预计算,从而减少Cuboid的数量
2.3 必需维度
  • 适用场景:如果某个维度在所有查询中都会作为group by或者where的条件,可以把他设置为必需维度,通常情况下会设置日期为必需维度。
2.4 层级维度
  • 适用场景:维度之间有层级关系,比如 国家(A)->省份(B)->城市(C)

    kylin|kylin cube优化
    文章图片
    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的顺序遵循如下原则:
  • 【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个数据进行聚合得到结果返回。

    kylin|kylin cube优化
    文章图片
    image.png
kylin|kylin cube优化
文章图片
image.png
  • 适用范围:分析场景主要集中在某个维度的topN时。
5. cube planner
  • 这是自kylin2.3提供的一个自动优化工具,在用户自定义的基础上进行进一步的自动优化,主要是两个阶段:
    • 阶段1. 初次构建时,cube planner根据cube构建过程中的extract fact table distinct columns步骤中的采样数据,计算效益比(查询成本/物化该维度组合后对整个cube减少的的查询成本)
    • 阶段2: 对于已经运行一段时间的cube,根据历史统计的查询信息,几乎不被查询的cuboid会被删除(需要依赖于system cube)

    推荐阅读