Spark&Spark性能调优实战

标签: spark spark 性能调优 | 发表时间:2014-08-09 22:09 | 作者:zcc_0015
出处:http://blog.csdn.net

       Spark特别适用于多次操作特定的数据,分mem-only和mem & disk。其中mem-only:效率高,但占用大量的内存,成本很高;mem & disk:内存用完后,会自动向磁盘迁移,解决了内存不足的问题,却带来了数据的置换的消费。Spark常见的调优工具有nman、Jmeter和Jprofile,以下是Spark调优的一个实例分析:

1、场景:精确客户群

对一个容量为300g的客户信息表在spark上进行查询优化,该大宽表有1800多列,有效使用的有20列。

2、优化达到的效果:查询由原来的40.232s降低为2.7s

3、优化过程分析

第一步:首先发现磁盘存在大量的iowait,通过查看相关日志文件,发现一个block的大小进而推算出整个数据文件大小为300G整个内存无法容纳,采用压缩的方法实现优化,结合本数据文件的特点,存在大量的0和1,选 Gzip算法进行压缩,压缩后的大小为1.9G,该步使得查询从40.232降为了20.12s。

第二步:大宽表存在1800多列,而有效使用的只有20多列,故通过RCFILE只将有效的列加载,该步使得查询从20s降为12s。

第三步:通过Jprofile分析出CPU的负载过高,到底是什么原因造成的,仔细发现序列化机制有问题。Spark的serialization框架有两种:java自身的和kryo的。其中kryo 是一个快速高效的Java对象图形序列化框架,主要特点是性能、高效和易用,换成kryo后,查询从12s降到7s。

第四步:进一步分析CPU各核负载量很不均匀,内存也没有用满,系统的资源没有得到充分利用,该如何利用? (1)Spark的RDD的partition个数创建task的个数是对应的;(2)Partition的个数在hadoop的RDD中由block的个数决定的,内存:系统总内存数=work内存大小*work数=SPARK_WORKER_MEMORY*SPARK_WORKER_INSTANCES;

CPU:系统总的task数=work数×work所占的cores数=SPARK_WORKER_INSTANCES*SPARK_WORKER_CORES,计算task并行度,内存分配情况,调优参数:

SPARK_WORKER_INSTANCES=4

SPARK_WORKER_CORES = 3

SPARK_WORKER_MEMORY = 6G

Cpu(12core)  mem(24G),通过这几个参数的优化,查询由7s降到5s。

第五步:进一步发现Sharkserver端出现明显的fullGC,通过调优参数

Export SHARK_MASTER_MEM=2g,该步由6s降到3sl;

第六步:又发现当两表关联时,cpu 出现瓶颈,分析原因是日表做了gzip压缩,优化方法:日表不使用gzip压缩,将日表做成内存表。查询从3s降到2s。

4、总结

        优化是一个逐步求精的过程,回顾该优化过程,主要是从以下几个因素考虑:(1)mem;(2)cpu;(3)dis;(4)网络IO;(5)序列化机制。认真这些因素为主线,挖掘与其相关的内容时行大胆尝试。

作者:zcc_0015 发表于2014-8-9 22:09:38 原文链接
阅读:102 评论:0 查看评论

相关 [spark spark 性能调优] 推荐:

Spark性能调优

- - zzm
通常我们对一个系统进行性能优化无怪乎两个步骤——性能监控和参数调整,本文主要分享的也是这两方面内容. Spark提供了一些基本的Web监控页面,对于日常监控十分有用. http://master:4040(默认端口是4040,可以通过spark.ui.port修改)可获得这些信息:(1)stages和tasks调度情况;(2)RDD大小及内存使用;(3)系统环境信息;(4)正在执行的executor信息.

Spark&Spark性能调优实战

- - CSDN博客互联网推荐文章
       Spark特别适用于多次操作特定的数据,分mem-only和mem & disk. 其中mem-only:效率高,但占用大量的内存,成本很高;mem & disk:内存用完后,会自动向磁盘迁移,解决了内存不足的问题,却带来了数据的置换的消费. Spark常见的调优工具有nman、Jmeter和Jprofile,以下是Spark调优的一个实例分析:.

Spark的性能调优

- - 四火的唠叨
下面这些关于Spark的性能调优项,有的是来自官方的,有的是来自别的的工程师,有的则是我自己总结的. Data Serialization,默认使用的是Java Serialization,这个程序员最熟悉,但是性能、空间表现都比较差. 还有一个选项是Kryo Serialization,更快,压缩率也更高,但是并非支持任意类的序列化.

手把手教你 Spark 性能调优

- - ImportNew
上周四接到反馈,集群部分 spark 任务执行很慢,且经常出错,参数改来改去怎么都无法优化其性能和解决频繁随机报错的问题. 看了下任务的历史运行情况,平均时间 3h 左右,而且极其不稳定,偶尔还会报错:. 在有限的计算下,job的运行时长和数据量大小正相关,在本例中,数据量大小基本稳定,可以排除是日志量级波动导致的问题:.

浅谈 Spark 应用程序的性能调优

- - SegmentFault 最新的文章
Spark是基于内存的分布式计算引擎,以处理的高效和稳定著称. 然而在实际的应用开发过程中,开发者还是会遇到种种问题,其中一大类就是和性能相关. 在本文中,笔者将结合自身实践,谈谈如何尽可能地提高应用程序性能. 分布式计算引擎在调优方面有四个主要关注方向,分别是CPU、内存、网络开销和I/O,其具体调优目标如下:.

Spark概览

- - 简单文本
Spark具有先进的DAG执行引擎,支持cyclic data flow和内存计算. 因此,它的运行速度,在内存中是Hadoop MapReduce的100倍,在磁盘中是10倍. 这样的性能指标,真的让人心动啊. Spark的API更为简单,提供了80个High Level的操作,可以很好地支持并行应用.

Spark与Mapreduce?

- - 崔永键的博客
我本人是类似Hive平台的系统工程师,我对MapReduce的熟悉程度是一般,它是我的底层框架. 我隔壁组在实验Spark,想将一部分计算迁移到Spark上. 年初的时候,看Spark的评价,几乎一致表示,Spark是小数据集上处理复杂迭代的交互系统,并不擅长大数据集,也没有稳定性. 但是最近的风评已经变化,尤其是14年10月他们完成了Peta sort的实验,这标志着Spark越来越接近替代Hadoop MapReduce了.

Spark迷思

- - ITeye博客
目前在媒体上有很大的关于Apache Spark框架的声音,渐渐的它成为了大数据领域的下一个大的东西. 证明这件事的最简单的方式就是看google的趋势图:. 上图展示的过去两年Hadoop和Spark的趋势. Spark在终端用户之间变得越来越受欢迎,而且这些用户经常在网上找Spark相关资料. 这给了Spark起了很大的宣传作用;同时围绕着它的也有误区和思维错误,而且很多人还把这些误区作为银弹,认为它可以解决他们的问题并提供比Hadoop好100倍的性能.

Spark 优化

- - CSDN博客推荐文章
提到Spark与Hadoop的区别,基本最常说的就是Spark采用基于内存的计算方式,尽管这种方式对数据处理的效率很高,但也会往往引发各种各样的问题,Spark中常见的OOM等等. 效率高的特点,注定了Spark对性能的严苛要求,那Spark不同程序的性能会碰到不同的资源瓶颈,比如:CPU,带宽、内存.

Mesos上部署spark

- - 开源小站
还是回到之前一直持续的 Mesos话题. 在之前的环节里,我们已经尝试了Mesos的安装,Marathon守护服务以及相对比较主流的Mesos作为Hadoop的资源管理器的实际操作. 这次就说说同属于伯克利出品的Spark. 其实spark最初0.7以前的版本还没有自己的资源管理系统,资源的调度都是通过Mesos来执行的.