spark(二)优化思路

优化思路

内存优化

内存优化大概分为三个方向

1.所有对象的总内存(包括数据和java对象)

2.访问这些对象的开销

3.垃圾回收的开销

其中Java的原生对象往往都能被很快的访问,但是会多占据2-5倍或更多的内存,有下面4点原因

·每个单独的java对象都有一个对象头(16字节),其中包括指向对象的指针(栈->堆),如果该对象只有几个属性,那么对象头可能比实际数据占用的空间都大(严重浪费资源)

·java每个string都包含了40字节的额外开销(因为底层其实是存储在数组,需要记录数组的指针,长度等信息),每个字符包含2字节(UTF-16编码)。例如一个10字符的string,实际占用内存空间60字节

·常见的集合类,例如linkedlist,hashmap都有用到链表,其中的对象头,元素指针都会占据额外的空间

·基础类型的包装,例如Integer

明确内存消耗

一般情况,可以把数据转成rdd,然后通过spark自带的UI的Storage页面来观察rdd占用内存大小。

其它特殊的对象,可以用spark自带的工具类SizeEstimator来评估内存大小,包括对广播数据的内存占用评估

优化数据结构

避免使用需要额外开销的java原生的数据结构,比如链表,hashmap,包装类。下面是常见的方法

·尽量使用数组结构和基础类型,

·在嵌套的数据结构中,尽量避免小对象和指针

·考虑用数字或者枚举来代替string作为key

·如果内存少于32GB,可以优化JVM -XX:+UseCompressedOops ,OOP = “ordinary object pointer” 普通对象指针。可以让指针由8->4字节,压缩的一般是对象的相关指针(不是用来压缩数据的)。

一般建议场景是在分配给JVM的内存大小在[4G,32G], 如果小于4G,那么JVM会使用低虚拟地址空间(low virutal address space,64位下模拟32位),这样就不需要做压解压动作了。而对于大于32G,将采用默认的随机地址分配特性,进行压解压。

数据序列化

选择合适的序列化协议,一般而言用Kryo,比java原生序列化快很多

数据存储

RDD persistence API

通过把数据序列化至内存,或者磁盘,或者其他策略

GC优化

所有给spark的内存资源,有一部分是用于cache RDD的,剩下的用于jvm的堆和栈等使用。

默认的比例是cache RDD占总内存的60%,可以通过spark.storage.memoryFraction来更改。

一般情况下,官方文档建议这个比值不要超过JVM Old Gen区域的比值。这也很容易理解,因为RDD Cache数据通常都是长期驻留内存的,理论上也就是说最终会被转移到Old Gen区域(如果该RDD还没有被删除的话),如果这部分数据允许的尺寸太大,势必把Old Gen区域占满,造成频繁的FULL GC,这种情况就可以调小该值。

·确认资源是否给足driver的cpu和memory,executor的cpu和memory

·当出现过多的full GC时候,可以减小RDD cache的内存空间

·当出现过多的minor GC时候,可以增加JVM中Eden区的大小,通过4/3的比例增加

·其它常规JVM优化方法,线程栈的内存大小,永久代的堆内存大小等

分区数优化

分区数多就是task多,整个任务的并发度就高,但也不是越多越好,假设你有100条数据,有50个分区,平均一个分区就处理两条数据,这样就造成了严重的浪费,更多的时间浪费在分区间的shuffle,和driver的聚合。

下面是几个优化建议

·每个cpu core上跑2~3个tasks

·当task上的数据大于20KB的时候,可以考虑

·在当前的分区数的1.5倍来进行调优

关于分区

除了显示的声明rdd或者dataframe的分区数外,还有两种控制分区数的配置,

1.spark.sql.shuffle.partitions

针对dataframe和一些sql操作的分区数

默认的分区数为父RDD的最大分区数

2.spark.default.parallelism

针对rdd的默认分区数

一般分区数取决于executor的core数量,因为partition越多task越多,而task是spark的最小处理单元。executor的core数量不够,task再多也只能排队,反而慢了。

注:默认的shuffle后分区数为200

共享变量

广播

当遇到全局性的数据需要使用时,可以采用广播的方式

广播变量的优势:是因为不是每个task一份变量副本,而是变成每个节点的executor才一份副本。这样的话,就可以让变量产生的副本大大减少。

广播变量,初始的时候,就在Drvier上有一份副本。task在运行的时候,想要使用广播变量中的数据,此时首先会在自己本地的Executor对应的BlockManager中,尝试获取变量副本;如果本地没有,BlockManager,也许会从远程的Driver上面去获取变量副本;也有可能从距离比较近的其他节点的Executor的BlockManager上去获取,并保存在本地的BlockManager中;BlockManager负责管理某个Executor对应的内存和磁盘上的数据,此后这个executor上的task,都会直接使用本地的BlockManager中的副本。

例如,50个executor,1000个task。一个map,10M。默认情况下,1000个task,1000份副本。10G的数据,网络传输,在集群中,耗费10G的内存资源。如果使用了广播变量。50个execurtor,50个副本。500M的数据,网络传输,而且不一定都是从Driver传输到每个节点,还可能是就近从最近的节点的executor的bockmanager上拉取变量副本,网络传输速度大大增加;500M,大大降低了内存消耗。

累加器

全局的累加器,可以用于统计全局性的数据

数据本地化

数据本地化是一个影响spark jobs性能的主要方面。其实运行分为两块,一块数据,一块代码,最好的情况就是数据不动(数据量太大),代码会部署在各个executor上。

可以通过调节spark.locality相关配置来决定任务的运行选择。

接口优化

1.reduceBy和groupBy

同理,reduceByKey,aggregateByKey,groupByKey等

优先使用reduceBy

reduceBy会优先合并本地的rdd,这样就大大的减少了shuffle的数据量

2.coalesce和repartition

看源码可知repartition是采用shuffle的coalesce。从性能上来讲,coalesce是本地合并,也就是同一个executor合并,这样可以减少网络传输带来的性能损失,并且是窄依赖,数据恢复也方便。而reparation直接采用shuffle的方式合并。优先使用coalesce。但是在大量分区需要合并的时候,要考虑一下策略。比如,现在一共有1000个分区,需要合并成10个分区。

如果直接采用coalesce(10),可能导致合并的速度并不快(原因未知),而采用reparation(10)并发度会多很多。最终性能还是repartition好一点。

应用场景,设原rdd分区大小为M,现rdd分区大小为N
M>N,并且差10倍以内,考虑用coalesce
M>N,并且差10倍以上,考虑用repartition
M<N,考虑用repartition

注:也可以采用混合使用,先coalesce,把分区数降下来,然后采用repartition,当然这就需要实际测试,观察哪种性能更加

动态分配资源

Spark on yarn支持一种特殊的资源分配机制

从spark1.2开始就提供该机制。你的application在运行过程中会返回给资源池你所拥有的资源(比如你问yarn要了2G,跑玩数据预处理后,接下来的计算只需要1G,那剩下的1G就先还给yarn)

可以通过下面配置开启

spark.dynamicAllocation.enabled=true

参考资料

//官方配置文档

http://spark.apache.org/docs/1.5.0/configuration.html

//spark官方提供的思路

https://spark.apache.org/docs/1.5.0/tuning.html

//cloudera提供的思路

http://blog.cloudera.com/blog/2015/03/how-to-tune-your-apache-spark-jobs-part-1/

http://blog.cloudera.com/blog/2015/03/how-to-tune-your-apache-spark-jobs-part-2/

//IBM提供的相关资料

https://www.ibm.com/support/knowledgecenter/en/SSZU2E_2.2.0/performance_tuning/application_overview.html

时间: 2024-10-06 08:16:05

spark(二)优化思路的相关文章

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

Spark性能优化指南--高级篇 [TOC] 前言 继基础篇讲解了每个Spark开发人员都必须熟知的开发调优与资源调优之后,本文作为<Spark性能优化指南>的高级篇,将深入分析数据倾斜调优与shuffle调优,以解决更加棘手的性能问题. 数据倾斜调优 调优概述 有的时候,我们可能会遇到大数据计算中一个最棘手的问题--数据倾斜,此时Spark作业的性能会比期望差很多.数据倾斜调优,就是使用各种技术方案解决不同类型的数据倾斜问题,以保证Spark作业的性能. 数据倾斜发生时的现象 绝大多数tas

【转载】Spark性能优化指南——高级篇

前言 数据倾斜调优 调优概述 数据倾斜发生时的现象 数据倾斜发生的原理 如何定位导致数据倾斜的代码 查看导致数据倾斜的key的数据分布情况 数据倾斜的解决方案 解决方案一:使用Hive ETL预处理数据 解决方案二:过滤少数导致倾斜的key 解决方案三:提高shuffle操作的并行度 解决方案四:两阶段聚合(局部聚合+全局聚合) 解决方案五:将reduce join转为map join 解决方案六:采样倾斜key并分拆join操作 解决方案七:使用随机前缀和扩容RDD进行join 解决方案八:多

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

前言 数据倾斜调优 调优概述 数据倾斜发生时的现象 数据倾斜发生的原理 如何定位导致数据倾斜的代码 查看导致数据倾斜的key的数据分布情况 数据倾斜的解决方案 解决方案一:使用Hive ETL预处理数据 解决方案二:过滤少数导致倾斜的key 解决方案三:提高shuffle操作的并行度 解决方案四:两阶段聚合(局部聚合+全局聚合) 解决方案五:将reduce join转为map join 解决方案六:采样倾斜key并分拆join操作 解决方案七:使用随机前缀和扩容RDD进行join 解决方案八:多

分享企业网站SEO优化思路

现在网络也成为了大部分企业的营销工具,网站SEO优化对企业的效益明显突出来了.下面介绍企业网站SEO优化思路. 一.域名检测 为了了解网站目前的状态,需要检测各项指标对网站当前的状况进行综合评估,即域名检测.检测的内容一般包括网站当前的PR值.ALEXA排名.百度和谷歌等SE的收录情况.PV.IP.反向链接数等. 1) 域名注册时间 2) 域名PR值 3) ALEXA排名 4) 百度收录 5) 谷歌收录 6) PV数 7) IP数 8) 反向链接 二.网站结构分析和优化 1)网站框架 按照网站的

关于秒杀的系统架构优化思路

一.问题的提出 秒杀或抢购活动一般会经过 预约,下单,支付 ,扛不住的地方在于下单,一般会带来2个问题: 1.高并发 比较火热的秒杀在线人数都是10w起的,如此之高的在线人数对于网站架构从前到后都是一种考验. 2.超卖 任何商品都会有数量上限,如何避免成功下订单买到商品的人数不超过商品数量的上限,这是每个抢购活动都要面临的难题. 秒杀系统难做的原因:库存只有一份,瞬间大量用户读和写这些数据. 例如小米手机每周二的秒杀,可能手机只有1万部,但瞬时进入的流量可能是几百几千万 二.架构 常见站点架构如

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

前言 在大数据计算领域,Spark已经成为了越来越流行.越来越受欢迎的计算平台之一.Spark的功能涵盖了大数据领域的离线批处理.SQL类处理.流式/实时计算.机器学习.图计算等各种不同类型的计算操作,应用范围与前景非常广泛.在美团•大众点评,已经有很多同学在各种项目中尝试使用Spark.大多数同学(包括笔者在内),最初开始尝试使用Spark的原因很简单,主要就是为了让大数据计算作业的执行速度更快.性能更高. 然而,通过Spark开发出高性能的大数据计算作业,并不是那么简单的.如果没有对Spar

58沈剑:秒杀系统架构优化思路

有个兄弟分享秒杀系统的优化,其观点有些赞同,大部分观点却并不同意,结合自己的经验,谈谈自己的一些看法. 一.为什么难 秒杀系统难做的原因:库存只有一份,所有人会在集中的时间读和写这些数据. 例如小米手机每周二的秒杀,可能手机只有1万部,但瞬时进入的流量可能是几百几千万. 又例如12306抢票,亦与秒杀类似,瞬时流量更甚. 二.常见架构 流量到了亿级别,常见站点架构如上: 1)浏览器端,最上层,会执行到一些JS代码 2)站点层,这一层会访问后端数据,拼html页面返回给浏览器 3)服务层,向上游屏

Web下的整体测试 --性能测试及优化思路

随着Internet的日益普及,现在基于B/S结构的大型应用越来越多,可如何对这些应用进行测试成为日益迫切的问题.有许多测试人员来信问我B/S的测试如何做,由于工作较繁忙,对大家提出的问题也是头痛医头脚痛医脚,没有对WEB的测试过程做一个整体的概述.希望通过本篇能够让大家了解大型Web应用是如何来进行测试的. B/S下的功能测试比较简单,关键是如何做好性能测试.目前大多数的测试人员认为只要跑一些测试工具证明我的产品是可以达到性能的就ok了,为了证明而去测试是没有任何价值的,关键是要发现产品性能上

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

http://tech.meituan.com/spark-tuning-basic.html 前言 在大数据计算领域,Spark已经成为了越来越流行.越来越受欢迎的计算平台之一.Spark的功能涵盖了大数据领域的离线批处理.SQL类处理.流式/实时计算.机器学习.图计算等各种不同类型的计算操作,应用范围与前景非常广泛.在美团?大众点评,已经有很多同学在各种项目中尝试使用Spark.大多数同学(包括笔者在内),最初开始尝试使用Spark的原因很简单,主要就是为了让大数据计算作业的执行速度更快.性