您现在的位置是:网站首页> 内容页

kylin构建cube优化

  • 乐游在线注册账号
  • 2019-11-04
  • 307人已阅读
简介前言下面通过对kylin构建cube流程的分析来介绍cube优化思路。 创建hive中间表kylin会在cube构建的第一步先构建一张hive的中间表,该表关联了所有的事实表和维度表,

前言

下面通过对kylin构建cube流程的分析来介绍cube优化思路。

 

创建hive中间表

kylin会在cube构建的第一步先构建一张hive的中间表,该表关联了所有的事实表和维度表,也就是一张宽表。

hive表分区,在构建宽表的时候,kylin需要遍历hive表,事实表和维度表如果是分区表,那么会减少遍历时间

hive相关配置调整,join相关配置,mapreduce相关配置等

 

创建完成后,为了防止文件大小不一致的情况,kylin又基于hive做了一次重均衡操作,

`kylin.engine.mr.mapper-input-rows=1000000`,默认每个文件包含100w的数据量

 

代码 `CreateFlatHiveTableStep`

找出所有维度的基数

通过HyperLogLog 算法找出去重后的维度列,如果某个的技术很大,那么这种维度为被称为ultra high cardinality column(UHC),也就是超高基数维度。

业务层处理UHC

比如时间戳维度基础可能是亿级的,可以转成为日期,基数降到几十万.

 

技术层处理UHC

kylin通过mapreduce进行此步骤,在reduce端,一个维度用一个reduce去重,因此当某个维度的基数很大时,会导致该维度所在的reduce运行很慢,甚至内存溢出,为了应对这种场景,kylin提供了两种解决方案

1. 全局唯一维度,也就是在count_dintinct中选择0错误率的统计分析。

2. 需要被shard by的维度,在rowkey构建时配置的维度。

接着可以通过配置`kylin.engine.mr.uhc-reducer-count=1`来声明这些列需要被分割成多少个reducer执行

 

当然,kylin也支持基于cuboid个数来进行reducer个数的分配,`kylin.engine.mr.hll-max-reducer-number=1`,默认情况下kylin不开启此功能,可以修改配置来提高最小个数;然后通过配置`kylin.engine.mr.per-reducer-hll-cuboid-number`来调整具体的reduce数量

int nCuboids = cube.getCuboidScheduler().getAllCuboidIds().size();int shardBase = (nCuboids - 1) / cube.getConfig().getHadoopJobPerReducerHLLCuboidNumber() + 1;int hllMaxReducerNumber = cube.getConfig().getHadoopJobHLLMaxReducerNumber();if (shardBase > hllMaxReducerNumber) { shardBase = hllMaxReducerNumber;}

 

最终的reducer数量由UHC和cuboids两个部分相加得到,具体代码参考

`FactDistinctColumnsReducerMapping`构造函数

 

# 配置UHC增加另外步骤,需要配置zk的地址(作为全局分布式锁使用)

# 因为在跑mapreduce的过程中,kylin没有将hbase-site.xml等配置上传到yarn,所以只能在kylin.properties中额外配置一遍

kylin.engine.mr.build-uhc-dict-in-additional-step=true

kylin.env.zookeeper-connect-string=host:port,host:port

 

代码 `FactDistinctColumnsJob`, `UHCDictionaryJob`

构建维度字典

找出所有维度的基数后,kyin为每个维度构建一个数据字典,字典的metadata存储在hdfs上,实际数据存储在hbase

字典在hdfs的路径规则为

kylin/kylin_meta_data/kylin-$jobid/%cubeid/metadata/dict/$catalog.$table/$dimension/$uuid.dict

 

字典数据在hbase的rowkey规则为

/dict/$catalog.$table/$dimension/$uuid.dict

 

rowkey长度

过长的rowkey会占用很大的存储空间,所以需要对rowkey长度进行控制。

当前kylin直接在当前进程内做了字典编码,也就是把string映射成int,如果维度列的基数很大,那么可能会出现内存溢出的情况(当列的基础大于1kw),这时候就需要考虑更改维度列的编码方式,改用`fixed_length`等

 

rowkey构建

对rowkey的构建也有一定的要求,一般而言,需要把基数大的字段放在前面,这样可以在scan的过程中尽可能的跳过更多的rowkey。

另一方面将基数小的列放在rowkey的后面,可以减少构建的重复计算,有些cuboid可以通过一个以上的父cuboid聚合而成,在这种情况下,Kylin将会选择最小的父cuboid。例如,AB能够通过ABC(id:1110)和ABD(id:1101)聚合生成,因此ABD会被作为父cuboid使用,因为它的id比ABC要小。基于以上处理,如果D的基数很小,那么此次聚合操作就会花费很小的代价。因此,当设计cube的rowkey顺序的时候,请记住,将低基数的维度列放在尾部。这不仅对cube的构建过程有好处,而且对cube查询也有好处,因为后聚合(应该是指在HBase查找对应cuboid的过程)也遵循这个规则。

 

构建cube

构建引擎

可以选择spark或者mapreduce来构建cube,通常来说,构建引擎的选择方式是这样的

    内存消耗型的cube选择mapreduce,例如Count Distinct, Top-N简单的cube选择spark,例如SUM/MIN/MAX/COUNT

 

spark引擎

spark构建引擎采用` by-layer`算法,也就是分层计算

比如有3个维度ABC,cube会构建A,B,C,AB,AC,ABC6种组合,这里就有3层,

第1层:A,B,C

第2层:AB,AC

第3层:ABC

每一层在计算对于spark而言都是一个action,并且该层计算的rdd会依赖其上一层的结果继续计算,这样避免了很大重复性计算工作。

 

代码` SparkCubingByLayer`

设计模式

参考《kylin介绍》中的cube设计模式

 

数据转换为HFile

kylin将生成的cube通过生成HFile的方式导入到hbase,这个优化点可以配置hbase的相关参数。

    region数量默认是1,如果数据量大的话可以提高region数量region大小默认是5GB,也就是hbae官方建议的大小;如果cube大小比这个值小太多,可以减小单region的大小hfile文件大小,默认是1GB,由于是通过mapreduce写入的,小文件意味着写入快,但是读取慢,大文件意味着写入慢,读取快

 

代码`CubeHFileJob`

cleanup

    清理hive中的中间表,清理hbase表清理hdfs数据

 

清理命令

# 查看需要清理的数据

./bin/kylin.sh org.apache.kylin.tool.StorageCleanupJob --delete false

# 清理

./bin/kylin.sh org.apache.kylin.tool.StorageCleanupJob --delete true

 

// clean参考

http://kylin.apache.org/docs20/howto/howto_cleanup_storage.html

 

总结

基于kylin的ui,可以看到kylin在构建cube时各个流程的耗时,可以依据这些耗时做相应的优化,常见的,可以从耗时最长的步骤开始优化,比如:

    遇到创建hive中间表时间很长,考虑对hive表进行分区处理,对表中的文件格式更改,使用orc,parquet等高性能的文件格式遇到cube构建时间过长,查看cube设计是否合理,维度的组合关系是否可以再减少,构建引擎是否可以优化

 

优化的思路还是以cube为中心,优化cube的整个生命周期,其中涉及到的所有组件都是优化点,具体情况还是要和实际的数据维度和业务结合起来。

 

参考

// 官方文档

http://kylin.apache.org/docs20/howto/howto_optimize_build.html

 

// 官方文档,cube性能优化

http://kylin.apache.org/docs23/tutorial/cube_build_performance.html

 

文章评论

Top