一. 构建cube 调优:
降低纬度数,在真正构建cube时参与的纬度组合个数减少,以达到减少Cuboid的数量。
5.1.1 可以通过在kylin bin目录下 运行命令:
./kylin.sh org.apache.kylin.engine.mr.common.CubeStatsReader
OrderCommodityClone2以检查当前cube中的segment大小,cuboid状态信息如大小,相比父节点占比值即重合率等。1和0代表着 对应于rowkey中(即纬度组合)是由哪种纬度组合的,1代表有该纬度参与,0则没有,特殊的base cuboid 全是1即所有纬度都参与。
优化点一:重合率将近100%,意味着子相比父虽然少了一个纬度,但是并没有比它的父亲Cuboid少很多行数据。换而言之,没有这个Cuboid,我们在查询时使用它的父亲Cuboid,也不会有太大的代价
少的纬度为低基数纬度列,如status都为1,父节点为地区,status组合,则少个纬度stauts,子的行数还是一样的,这样的纬度可以不设计 或者 不参到与其他纬度的组合中,比如把某些低基数纬度设置为
一个联合纬度;
优化点二:cuboid太多,可以根据业务查询场景,对纬度进行分组(设置聚合组,必要纬度,层级纬度和联合纬度)
5.1.2 聚合组,必要纬度,层级纬度和联合纬度(所有前提是根据业务的查询场景设定,sql中总会按照某些纬度过滤或者group by)
根据cube理论 N纬 有2的N次幂个cuboid,如下图采用官网示例图所示 2的4次幂16个cuboid,随着n的增大,cuboid的则呈指数增长。
优化点三: 可以具体根据查询场景对纬度进行分组(聚合组 同一个组内的维度更可能同时被同一个查询用到)
例:ABCD纬度(某种查询场景中只需用到AB,另一场景只用到CD)AB和CD各设置到各自聚合组中,cuboid由2^(m+n)变为2^m + 2^n, (ps:使用聚合组设置,可以把高基数纬度的列放入一个单独的聚合组,再把所有可能会与这个高基数维度一起被查询到的其他维度也放进来 大大减少了包含该高基数维度的Cuboid的数量(行数),可以有效地控制Cube的膨胀率),示意图如下:
优化点四: 可以在聚合组中又可以设置必要纬度 (必要纬度 业务查询场景中 会对某一个或几个维度经常使用,其它则不使用 比如 所有的查询请求中都存在group by这个维度 可以把它设置必要纬度)
例:ABCD四个纬度 只用A 那么cube中只包含A的cuboid,不包含A的则不构建,示意图如下:
优化点五: 可以在聚合组中又可以设置层级纬度 (层级维度每个层级包含两个或更多个维度, 使用于有层级关系的,比如国家省市区,年月日这类具有层级关系的纬度可以设置为层级纬度)
例:ABCD四个纬度,ABC设置层级关系,则A、AB、ABC,低层级纬度必须伴随着高层级纬度一起出来。示意图如下:
优化点六: 可以在聚合组中又可以设置联合纬度 (每个联合中包含两个或更多个维度 联合维度要么一起出现,要么都不出现 每个分组中可以有0个或多个联合,但是不同的联合之间
不应当有共享的维度(否则它们可以合并成一个联合)
例:ABCD四个纬度,ABC设置为联合纬度,示意图如下:
5.1.3 使用衍生纬度
大多model设计中,是事实表关联其他维度表(类似主外键关系),其维度表中的字段最好不要
二 . cube 查询优化:
简单的讲,查询频率越高/基数越大的维度在Rowkey中的顺序需要越靠前。
“shard by”维度列
选择基数高的维度做分片(sharding),如useid列
可以使MR构建过程按照该列进行重新分布,加快构建速度
相关文档:
http://lxw1234.com/archives/2017/04/849.htm