不可不知的Spark调优点

简介: 在利用Spark处理数据时,如果数据量不大,那么Spark的默认配置基本就能满足实际的业务场景。但是当数据量大的时候,就需要做一定的参数配置调整和优化,以保证业务的安全、稳定的运行。并且在实际优化中,要考虑不同的场景,采取不同的优化策略。

在利用Spark处理数据时,如果数据量不大,那么Spark的默认配置基本就能满足实际的业务场景。但是当数据量大的时候,就需要做一定的参数配置调整和优化,以保证业务的安全、稳定的运行。并且在实际优化中,要考虑不同的场景,采取不同的优化策略。

1.合理设置微批处理时间

在SparkSreaming流式处理中,合理的设置微批处理时间(batchDuration)是非常有必要的。
如果batchDuration设置过短,会导致SparkStreaming频繁提交job。如果每个batchDuration所产生的job不能在这个时间内完成处理,就会造成job不断堆积,最终导致SparkStreaming发生阻塞,甚至程序宕掉。
需要根据不同的应用场景和硬件配置等确定,可以根据SparkStreaming的可视化监控界面,观察Total Delay等指标来进行batchDuration的调整。

2.控制消费的最大速率

比如SparkStreaming和Kafka集成,采用direct模式时,需要设置参数spark.streaming.kafka.maxRatePerPartition以控制每个Kafka分区最大消费数。该参数默认没有上线,即Kafka当中有多少数据它就会直接全部拉出。
但在实际使用中,需要根据生产者写入Kafka的速率以及消费者本身处理数据的速度综合考虑。
同时还需要结合上面的batchDuration,使得每个partition拉取的数据,要在每个batchDuration期间顺利处理完毕,做到尽可能高的吞吐量,该参数的调整需参考可视化监控界面中的Input Rate和Processing Time。

3.缓存反复使用的"数据集"

Spark中的RDD和SparkStreaming中的DStream,如果被反复的使用,最好利用cache或者persist算子,将"数据集"缓存起来,防止过度的调度资源造成的不必要的开销。

4.合理的设置GC

JVM垃圾回收是非常消耗性能和时间的,尤其是stop world、full gc非常影响程序的正常运行。
关于JVM和参数配置,建议研读《JVM内存管理和垃圾回收》《JVM垃圾回收器、内存分配与回收策略》《内存泄漏、内存溢出和堆外内存,JVM优化配置参数》

5.合理设置CPU

每个executor可以占用一个或多个core,可以通过观察CPU的使用率变化来了解计算资源的使用情况。
要避免CPU的使用浪费,比如一个executor占用多个core,但是总的CPU利用率却不高。此时建议让每个executor占用相对之前较少的core,同时worker下面增加更多的executor进程来增加并行执行的executor数量,从而提高CPU利用率。同时要考虑内存消耗,毕竟一台机器运行的executor越多,每个executor的内存就越小,容易产生OOM。

6.使用Kryo进行序列化和反序列化

Spark默认使用Java的序列化机制,但这种Java原生的序列化机制性能却比Kryo差很多。使用Kryo需要进行设置:

//设置序列化器为KryoSerializer
SparkConf.set("spark.serializer","org.apache.spark.serializer.KryoSerializer")
//注册要序列化的自定义类型
SparkConf.registerKryoClasses(Array(classOf[CustomClass1],classOf[CustomClass2]))

7.使用高性能的算子

1)使用reduceByKey、aggregateByKey替代groupByKey
2)filter之后进行coalesce操作
3)使用repartitionAndSortWithinPartition
替代repartition与sort操作
4)使用mapPartition替代map
5)使用foreachPartition替代foreach

要结合实际使用场景,进行算子的替代优化。

除了上述常用调优策略,还有合理设置Spark并行度,比如参数spark.default.parallelism的设置等,所有这些都要求对Spark内核原理有深入理解,这里不再一一阐述。


本文转载自公众号: 大数据学习与分享
原文链接:https://mp.weixin.qq.com/s?__biz=MzI0Mjc0MDU2NQ==&mid=2247484099&idx=1&sn=5755c366d08e82886bf0c6af9d6cf6cb&chksm=e976fef9de0177ef1e6d4dad6aa0ab6363e54b316c64f51aef3ac1ba4a5c6d4336d8c2b6ddc4&scene=21#wechat_redirect


阿里巴巴开源大数据技术团队成立Apache Spark中国技术社区,定期推送精彩案例,技术专家直播,问答区近万人Spark技术同学在线提问答疑,只为营造纯粹的Spark氛围,欢迎钉钉扫码加入!

image.png

对开源大数据和感兴趣的同学可以加小编微信(下图二维码,备注“进群”)进入技术交流微信群。
image.png

Apache Spark技术交流社区公众号,微信扫一扫关注

image.png

相关文章
|
并行计算 PyTorch 算法框架/工具
本地部署DeepSeek模型
要在本地部署DeepSeek模型,需准备Linux(推荐Ubuntu 20.04+)或兼容的Windows/macOS环境,配备NVIDIA GPU(建议RTX 3060+)。安装Python 3.8+、PyTorch/TensorFlow等依赖,并通过官方渠道下载模型文件。配置模型后,编写推理脚本进行测试,可选使用FastAPI服务化部署或Docker容器化。注意资源监控和许可协议。
6904 13
|
存储 SQL 缓存
Perf Arm SPE介绍与使用
本次分享的主题是 Perf Arm-SPE 的介绍及使用,本次分享主要介绍如何在倚天 710 平台上利用 Arm-SPE 特性定位伪共享问题、分析内存访问、分析指令延时以及监控访存延时等功能。 1. 背景介绍 2. Arm SPE的原理 3. Arm SPE在倚天服务器上的应用 4. Arm SPE 更多特性与功能的探索
1562 0
|
消息中间件 NoSQL 关系型数据库
一文彻底搞定Redis与MySQL的数据同步
【10月更文挑战第21天】本文介绍了 Redis 与 MySQL 数据同步的原因及实现方式。同步的主要目的是为了优化性能和保持数据一致性。实现方式包括基于数据库触发器、应用层双写和使用消息队列。每种方式都有其优缺点,需根据具体场景选择合适的方法。此外,文章还强调了数据同步时需要注意的数据一致性、性能优化和异常处理等问题。
3240 0
|
缓存 监控 安全
ARMv9-机密计算架构(CCA)深入理解
ARMv9-机密计算架构(CCA)深入理解
|
IDE 搜索推荐 开发工具
deque容器详解
双端数组,可以对头端进行插入删除操作 deque与vector区别: vector对于头部的插入删除,数据量越大,效率越低 vector访问元素的速度比deque快 deque没有容量函数模型,因为它可以扩展 #include<iostream> #include<algorithm> using namespace std; #include<deque>
289 1
|
缓存 PHP 数据安全/隐私保护
php 也有滑板鞋
前言 最近发现PHP网页有点慢 所以配置了xcache PHP缓存加速。就好像php也穿了跑鞋一样。 一、RPM安装配置xcache  1.xcache用于缓存加速  php的第三方扩展,存放在epel源上,安装包为php-xcache,在CentOS6上一般有三倍提升 [r...
1307 0
|
9天前
|
缓存 测试技术 API
Qwen 3.7 Plus 与 Max 实测:性价比与多模态能力差异解析(2026)
2026 年 6 月 1 日,阿里悄无声息地发布了 Qwen 3.7 Plus,距 Qwen 3.7 Max 上线刚好 11 天。同样的 1M 上下文,同样的 35 小时自治上限。但价格才是头条:Plus 是 0.40/M输入,Max是 2.50/M——便宜约 6 倍——并且还能看图、看视频。Vision Arena 上 Plus 已经排到 #16。所以这周真正值得讨论的问题不是”要不要为视觉能力买单”,而是”Max 凭什么用 6 倍价格换来 2 个百分点的 benchmark 领先”。
|
10天前
|
JavaScript 定位技术 API
CodeGraph 爆火:编程 Agent 需要的不是更多上下文,而是一张提前画好的代码地图
CodeGraph 是一款爆火的本地代码智能工具,通过 tree-sitter 解析 AST 构建结构化知识图谱(存于 SQLite),为编程 Agent 提前生成“代码地图”。它显著降低 Agent 在中大型项目中的探索成本——实测工具调用减少71%、Token 降57%、速度提升46%,支持19+语言及主流框架路由识别,完全离线、无需 API Key。
771 11
CodeGraph 爆火:编程 Agent 需要的不是更多上下文,而是一张提前画好的代码地图