文档章节

Kylin 2.0 Spark Cubing 优化改进

大数据之路
 大数据之路
发布于 2012/08/28 18:49
字数 2539
阅读 373
收藏 0

Kylin 2.0 引入了Spark Cubing beta版本,本文主要介绍我是如何让 Spark Cubing 支持 启用Kerberos的HBase集群,再介绍下Spark Cubing的性能测试结果和适用场景。

Spark Cubing 简介

在简介Spark Cubing之前,我简介下MapReduce Batch Cubing。所谓的MapReduce Batch Cubing就是利用MapReduce 计算引擎 批量计算Cube,其输入是Hive表,输出是HBase的KeyValue,整个构建过程主要包含以下6步:

  1. 建立Hive的大宽表; (MapReduce计算)
  2. 对需要字典编码的列计算列基数; (MapReduce计算)
  3. 构建字典; (JobServer计算 or MapReduce计算)
  4. 分层构建Cuboid; (MapReduce计算)
  5. 将Cuboid转为HBase的KeyValue结构(HFile); (MapReduce计算)
  6. 元数据更新和垃圾回收。

详细的Cube生成过程可以参考 Apache Kylin Cube 构建原理

而Kylin 2.0的Spark Cubing就是在Cube构建的第4步替换掉MapReduce。

如下图,就是将5个MR job转换为1个Spark job:

(注:以下两个图片引自 Apache Kylin 官网的blog: By-layer Spark Cubing, 更详细的介绍也可以参考这篇blog。)

MapReduce 计算5层的Cuboid会用5个MR Application计算: 此处输入图片的描述

Spark 计算Cuboid只会用1个 Application计算: 此处输入图片的描述

Spark Cubing的核心实现类是SparkCubingByLayer

为什么目前只有计算Cuboid这一步用Spark计算?

个人认为主要有以下两点:

  1. 实现并不复杂。
  2. 收益会比较明显。Cuboid的分层计算方法天然可以利用RDD的Cache特性来加速Cuboid 计算,最理想的情况,如果executor的内存能够完全cache住每层Cuboid的RDD,那就可以完全避免读写磁盘,必然会比MapReduce快很多。

我认为第2点是主要原因。

Cube构建的其他步骤不可以用Spark计算吗?

当然可以! 其中第1步 建立Hive的大宽表 和 第5步 生成HFile 替换为Spark是十分简单的,但是性能提升可能不会十分明显。 至于2步计算列基数,其代码逻辑应该是整个Cube构建中最复杂的一步,复杂的主要原因就是这一步肩负的使命略多。 还有第3步MR构建字典,因为MR构建本身尚不成熟,自然不急着迁移到Spark

Spark Cubing beta版本目前最大的问题就是不支持启用Kerberos认证的HBase集群,而事实上不少企业级的HBase服务都启用了Kerberos认证。不支持的原因主要是Spark Cubing需要直接从HBase中访问cube,dict等元数据信息。

Spark Cubing 访问 Kerberos认证的 HBase 解1

第一种简单的做法是将访问HBase的token从Kylin的JobServer传递到executor中,这种做法的限制是只能运行在Yarn-client模式中,即必须让driver运行在Kylin的JobServer中。 关于yarn-cluster mode和yarn-client mode两种模式的区别可以参考: Apache Spark Resource Management and YARN App Models

这种做法的实现方式很简单,只需在SparkCubingByLayer的new SparkConf()之前加入以下3行代码:

        Configuration configuration = HBaseConnection.getCurrentHBaseConfiguration();
        HConnection connection = HConnectionManager.createConnection(configuration);
        TokenUtil.obtainAndCacheToken(connection, UserProvider.instantiate(configuration).create(UserGroupInformation.getCurrentUser()));

但是如果只能在yarn-client模式下运行,必然无法运行在生产环境,因为Kylin JobServer机器的内存肯定不够用。

Spark Cubing 访问 Kerberos认证的 HBase 解2

既然Spark Cubing在 启用Kerberos认证的 HBase集群下无法运行的根本原因是 Spark Cubing需要从HBase 直接访问Job相关的Kylin元数据, 那我们把元数据换个地方存不就可以了, 所以我们将每个Spark Job相关的Kylin元数据上传到HDFS,并用Kylin的HDFSResourceStore来管理元数据

在介绍实现思路前,我先简介下Kylin元数据的存储结构和Kylin的ResourceStore。

首先,Kylin每个具体的元数据都是一个JSON文件,整个元数据的组织结构是个树状的文件目录。 如图是Kylin元数据的根目录: 屏幕快照 2017-07-02 下午3.51.43.png-20.7kB下图是project目录下的具体内容,其中learn_kylin和kylin_test都是project名称: 屏幕快照 2017-07-02 下午3.54.59.png-11.8kB

我们知道Kylin元数据的组织结构后,再简介下Kylin元数据的存储方式。 元数据存储的抽象类是ResourceStore,具体的实现类共有3个:

  • FileResourceStore 本地文件系统
  • HBaseResourceStore HBase
  • HDFSResourceStore HDFS

其中只有HBase可以用于生产环境,本地文件系统主要用来测试,HDFS不能用于生产的原因是并发处理方面还有些问题。具体用哪个ResourceStore是通过配置文件的kylin.metadata.url来决定的。

所以下面的问题就是我们如何将HBase中的元数据转移到HDFS 和如何将HBaseResourceStore 转为 HDFSResourceStore?

  1. 确定Spark Job需要读取哪些Kylin元数据
  2. 将需要的Kylin元数据dump到本地
  3. 改写kylin.metadata.url并将所有配置写到本地的元数据目录
  4. 利用ResourceTool将本地的元数据上传到指定的HDFS目录
  5. 在Spark executor中根据指定HDFS元数据目录的Kylin配置文件构造出HDFSResourceStore。

当然,在最后我们需要清理掉指定HDFS目录的元数据。 整个思路比较简单清晰,但是实际实现中还是有很多细节需要去考虑。

Spark Cubing 参数配置

以下是我使用的Spark配置,目的是尽可能让用户不需要关心Spark的配置

//运行在yarn-cluster模式
kylin.engine.spark-conf.spark.master=yarn
kylin.engine.spark-conf.spark.submit.deployMode=cluster 

//启动动态资源分配,个人认为在Kylin生产场景中是必须的,因为我们不可能让每个用户自己去指定executor的个数
kylin.engine.spark-conf.spark.dynamicAllocation.enabled=true
kylin.engine.spark-conf.spark.dynamicAllocation.minExecutors=10
kylin.engine.spark-conf.spark.dynamicAllocation.maxExecutors=1024
kylin.engine.spark-conf.spark.dynamicAllocation.executorIdleTimeout=300
kylin.engine.spark-conf.spark.shuffle.service.enabled=true
kylin.engine.spark-conf.spark.shuffle.service.port=7337

//内存设置
kylin.engine.spark-conf.spark.driver.memory=4G
//数据规模较大或者字典较大时可以调大executor内存
kylin.engine.spark-conf.spark.executor.memory=4G 
kylin.engine.spark-conf.spark.executor.cores=1

//心跳超时
kylin.engine.spark-conf.spark.network.timeout=600

//队列设置
kylin.engine.spark-conf.spark.yarn.queue=root.rz.hadoop-hdp.test

//分区大小
kylin.engine.spark.rdd-partition-cut-mb=100

Spark Cubing 的构建性能

对于百万级,千万级,亿级的源数据,且无很大字典的情况下,我的测试结果和官方By-layer Spark Cubing 的结果基本一致,构建速度提升比较明显,而且Cuboid的层次数越多,提速越明显。

此外,我专门测试了数十亿级源数据或者有超大字典的情况,构建提速也十分明显:

测试Cube1

原始数据量: 27亿行 9个维度 包含1个精确去重指标 字典基数7千多万

MR Cuboid构建耗时: 75分钟

Spark Cuboid第一次构建耗时: 40分钟 (spark.executor.memory = 8G,没有加spark.memory.fraction参数)

Spark Cuboid第二次构建耗时: 24分钟 (spark.executor.memory = 8G,spark.memory.fraction = 0.5)

为什么减小spark.memory.fraction可以加速构建?

因为减小spark.memory.fraction,可以增大executor中User Memory的大小,给Kylin字典更多的内存,这样就可以避免全局字典换入换出,减少GC。

测试Cube2

原始数据量:24亿行 13个维度 38个指标(其中9个精确去重指标) 不过这个cube的精确去重指标基数比较小,只有几百万。

MR Cuboid构建耗时: 31分钟

Spark Cuboid构建耗时: 8分钟

总结来说,Spark Cubing的构建性能相比MR有1倍到3倍的提升

Spark Cubing 的资源消耗

除了构建性能,我们肯定还会关注资源消耗。在这次测试中我没有对所以测试结果进行资源消耗分析,只分析了几个Cube。

我的结论是,在我采用的Spark配置情况下,对于中小规模数据集Spark的资源消耗是小于MR的(executor的内存是4G); 对于有大字典的情况(executor的内存是8G),CPU资源Spark是小于MR的,但是内存资源Spark会比MR略多,在这种情况下,我们相当于用内存资源来换取了执行效率

Spark Cubing 的优缺点

优点:

  • 利用RDD的Cache特性,尽可能利用内存来避免重复IO
  • 大部分场景下Cuboid构建速度有明显提升
  • 在集群资源充足的情况下,我们可以用更多的资源换取更好的构建性能

缺点:

  • 目前版本还未历经生产环境考验,稳定性不确定
  • 不适合有超大字典的场景
  • 引入Spark Cubing将带来额外的运维成本和沟通成本

Spark Cubing 的适用场景

个人的结论是,除了有好几亿基数超大字典的这种情况,其他情况应该都适用Spark Cubing,其中:

  1. Cuboid层次越多越适用。
  2. 数据规模越小越适用。
  3. 字典越小越适用。

Spark Cubing 字典加载优化

Spark和MR有一点重要的区别就是Spark的Task是在线程中执行的,MR的Task是在进程中执行的。 这点区别会对Kylin的Cube 构建造成重要影响,在MR Cubing中,每个Mapper task 只需要load一次字典,但是在Spark Cubing中,一个executor的多个task会多次load 字典,如果字典较大,就会造成频繁GC,导致执行变慢。

针对这个问题,我做了两点优化:

  1. 让每个executor里的字典只load一次,让该executor的所有Task共享字典。
  2. 给全局字典的AppendTrieDictionary中使用的LoadingCache增加maximumSize。 我用了一个有6亿基数的全局字典测试了这个优化,优化后GC时间明显缩短。

Spark 学习资料推荐

网上公开资料如果只推荐一份的话,我推荐: spark-internals

此外,这几篇文章也不错:

Spark Memory Management

Spark Architecture: Shuffle

how-to-tune-your-apache-spark-jobs-part-1

how-to-tune-your-apache-spark-jobs-part-2

Spark性能优化指南——基础篇

Spark性能优化指南——高级篇

Spark源码分析之-scheduler模块

当然,看的资料再多自己不思考都没啥卵用。 学习一个系统,我们可以从系统的整体架构和设计层面开始,自顶向下的学习,也可以从一个具体的问题把整个系统涉及的所有模块串起来,切面式学习。 个人感觉两种方式结合着效率会比较高,而且一般从具体问题入手会让印象更深刻,理解更深入。

本文转载自:http://blog.bcmeng.com/post/kylin-spark-cubing.html

大数据之路
粉丝 1605
博文 514
码字总数 333882
作品 0
武汉
架构师
私信 提问
Apache Kylin v2.0.0 Beta 尝鲜版上线

Apache Kylin 社区于日前宣布:Apache Kylin v2.0.0 Beta 版发布。 此次 Apache Kylin v2.0.0 Beta 升级的功能有: (KYLIN-1875)支持雪花数据模型 (KYLIN-2467)支持TPC-H查询 (KYLIN-2...

王练
2017/02/28
1K
11
Apache Kylin v3.0.0-alpha 正式发布

Apache Kylin v3.0.0-alpha 正式发布!欢迎大家下载使用。在这个版本中,值得关注的是: 3.0.0-alpha 增加了对流式数据源进行实时查询的能力,详情可以查看KYLIN-3654; 在KYLIN-3795中,我们...

ApacheKylin
04/18
983
0
Apache Kylin v2.5.0正式发布,开源分布式分析引擎

文章转载自开源中国,作者 Apache Kylin 社区 日前,Apache Kylin 社区宣布,Apache Kylin v2.5.0 正式发布。 Apache Kylin 是一个开源的分布式分析引擎,旨在为极大数据集提供 SQL 接口和多...

AI科技大本营
2018/10/08
0
0
如何在 Kylin 中优雅地使用 Spark

前言 Kylin 用户在使用 Spark的过程中,经常会遇到任务提交缓慢、构建节点不稳定的问题。为了更方便地向 Spark 提交、管理和监控任务,有些用户会使用 Livy 作为 Spark 的交互接口。在最新的...

ApacheKylin
09/01
48
0
Apache Kylin v2.5.1 正式发布

Apache Kylin社区于日前宣布:Apache Kylin v2.5.1 正式发布!欢迎大家下载使用。 Apache Kylin 是一个开源的分布式分析引擎,提供 Hadoop 之上的 SQL 查询接口及多维分析(OLAP)能力,支持...

ApacheKylin
2018/11/08
1K
0

没有更多内容

加载失败,请刷新页面

加载更多

Spring Boot + Mybatis + Ehcache 二级缓存实例

二级缓存是多个SqlSession共享的,其作用域是mapper的同一个namespace,不同的sqlSession两次执行相同namespace下的sql语句且向sql中传递参数也相同即最终执行相同的sql语句,第一次执行完毕...

xiaolyuh
16分钟前
4
0
Spring源码学习(二)哎呦,按菜谱做菜与AbstractAutowireCapableBeanFactory.createBean流程差不多

记得跟老婆谈恋爱时,有一天心血来潮给老婆做饭,按照菜谱一步一步的做,结果差点把厨房烧了!!! 这事至今老婆还记得。 入口 上一篇说了,AbstractBeanFactory.getBean的主流程 ,今天来说下...

温安适
18分钟前
34
0
前端UI攻城狮 你们该抛弃jQuery了

你不再需要jQuery! Web工程师太依赖jQuery了,某种意义上说jQuery已经成了JavaScript的同义词。但是我们真的需要他么?或许我们应该反思一下什么时候才真的需要jQuery。 对我个人而言开始使...

前端老手
20分钟前
5
0
六、Java设计模式之工厂方法

工厂方法定义: 定义一个创建对象的接口,但让实现这个接口的类来决定实例化哪个类,工厂方法让类的实例化推迟到子类中进行 类型:创建型 工厂方法-使用场景: 创建对象需要大量重复的代码 ...

东风破2019
今天
5
0
win服务器管理遇到的一系列问题记录

有些小伙伴在使用iis7远程桌面管理工具的时候总是会遇到一系列的问题,下面就是为大家介绍一下服务器日常管理过程中出现的问题及我的解决办法和心得。希望能帮到大家。   拒绝服务器重新启...

1717197346
今天
6
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部