Spark调优案例分享

原创 已于 2024-01-25 09:30:41 修改 · 1k 阅读 · 1 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#spark #大数据 #分布式

于 2023-11-13 20:15:49 首次发布
本文分享了作者针对Spark进行性能调优的实践经验，以MacKeynote的形式呈现，提供了实用的优化技巧和注意事项。

做了一个Spark调优案例的分享

最近在整理了Spark相关的调优案例，并做了以下分享:spark调优案例 ，注意是Mac Keynote

大数据技术之Hive on Spark调优
weixin_42158569的博客
02-08 612
hive 优化教程
Spark性能调优案例
epitomizelu的专栏
12-21 4149
在实际工作中，性能调优是必不可少的，虽然业务千种百样，实际落地的解决方案可能也不尽相同，但归根结底，调优的最终目的是使得内存、CPU、IO均衡没有瓶颈。 基本上，思路都是结合实际业务、数据量从硬件出发，考虑如何充分利用CPU、内存、IO。 除了对业务的理解之外，对于Spark本身的机制也要深入理解，这样才能通过各种调整，充分发挥Spark的优势，达成调优的目的。 下面以一个案例尝试总结常用的Spark调优思路和实践。 案例数据来源极客时间Spark 性能调优实战，数据地址百度网盘，提取码 ajs6 。 数
spark 调优
最新发布
qq_40982824的博客
07-29 548
计算集群可用资源总量（YARN队列内存/CPU），确保 spark.executor.instances * (spark.executor.memory + spark.executor.cores) 不超过队列资源的 ‌1/3~1/2‌，避免资源耗尽影响其他任务‌。Task延迟高‌ → 提高并行度（spark.default.parallelism 设为 executor数 × 核数 × 2-3‌）；云平台优化‌：阿里云等支持 spark.adb.acuPerApp 自动推导资源配置‌；
Hive on Spark调优（大数据技术6）
zy345293721的博客
05-19 1376
若参与join的表均为分桶表，且关联字段为分桶字段，且分桶字段是有序的，且大表的分桶数量是小表分桶数量的整数倍。此时，就可以以分桶为单位，为每个Map分配任务了，Map端就无需再缓存小表的全表数据了，而只需缓存其所需的分桶。Map端负责读取参与join的表的数据，并按照关联字段进行分区，将其发送到Reduce端，Reduce端完成最终的关联操作。若参与join的表中，有n-1张表足够小，Map端就会缓存小表全部数据，然后扫描另外一张大表，在Map端完成关联操作。162900000000（约160g）
hive on spark调优学习笔记
jyd730_的博客
06-17 701
hive on spark 调优学习笔记
Hive on Spark调优
张伟的专栏
07-28 1981
Hive on Spark调优
我的Spark调优心得：从课程项目到实战踩坑经验分享
2302_81755506的博客
03-09 373
欢迎在评论区交流你的调优故事~- **executor-memory**：根据数据量设置（推荐4-8g），避免频繁GC。- **executor-cores**：建议3-4核（并行执行task能力）- **mapPartitions**：替代低效的map+外部连接。- **foreachPartition**：数据库写入时批量操作。- **num-executors**：集群资源允许时适当增加。4. **源码学习**：推荐《Spark内核设计的艺术》- **过滤法**：直接剔除异常数据（需业务允许）
Spark原理及调优
ALX3li的博客
09-22 1327
spark 的原理及优化
Spark 调优
奔赴彼岸
01-14 229
Spark调优一、Spark资源参数调优二、开发调优 **调优思路：**优先使用参数调优，如果参数调优不能满足我们的业务场景，这里就要涉及到代码调优 一、Spark资源参数调优 • num-executors：该作业总共需要多少executor进程执行 – 建议：每个作业运行一般设置50~100个左右较合适 • executor-memory：设置每个executor进程的内存， num-executors* num- executors代表作业申请的总内存量（尽量不要超过最大总内存的1/3~1/2） –
结合案例详细说明Spark的部分调优手段
weixin_38290062的博客
12-21 1355
当谈到优化 Apache Spark 应用程序时，有一些更加详细和具体的优化策略和技术，可以帮助提高性能并最大化集群资源利用。coalescecachepersistbucketBy这些优化方法需要结合具体的应用场景和需求来实施。根据数据特点、集群配置和任务类型，综合使用这些方法可以显著提高 Spark 应用程序的性能和效率。
spark调优案例分享
11-13
spark的调优案例分享
Spark全面精讲（基于Spark2版本+含Spark调优+超多案例）【不是王家林版本】
01-05
0基础spark，基于spark2，内容完整全面，学完精通spark
spark 调优解析 spark 企业调优
12-01
### Spark性能优化 #### 调优基本原则 **基本概念和原则** 为了更好地理解Spark的性能调优，首先需要明确一些基本概念： 1. **Worker与Executor：** ...此外，结合实际案例的学习也是提升Spark调优能力的有效途径。
Spark DPP(动态分区裁剪)导致的DataSourceScanExec NullPointerException问题分析以及解决
热门推荐
monkeyboy_tech的博客
02-26 2万+
背景 本文基于spark 3.1.2,且运行在yarn模式下 最近在调试 spark sql的时候遇到了空指针的问题，如下： Caused by: java.lang.NullPointerException at org.apache.spark.sql.execution.DataSourceScanExec.$init$(DataSourceScanExec.scala:57) at org.apache.spark.sql.execution.FileSourceScanExec.<in
SPARK SQL中 CTE(with表达式)会影响性能么？
monkeyboy_tech的博客
03-22 7076
背景及问题 本文基于spark 3.1.2 最近在排查spark sql问题的时候，出现了一系列的(CTE)with操作，导致该任务运行不出来，而把对应的(CTE)with 替换成了临时表以后，任务很快的就能运行出来 对应的最简化的sql如下： with temp1 as ( select null as user_id ,a.sku_id ,int(sum(`可申请数量`)) `开放申请数量` from xxx.xxx `a` where pt between '20
Spark task过多导致任务运行过慢甚至超时
monkeyboy_tech的博客
03-15 6617
背景以及现象 本文基于 spark 3.1.2 设置spark.driver.memory=2g 在调试spark sql任务的时候，发现有几个任务产生了40多万个Task，而且任务长期运行不出来。 分析 运行此sql，可以得到如下的dag（我们只截取产生Task多的Stage），由此可以看到是scan的文件太大了（scan了日志文件半年的数据）。 但是为什么这种情况下会导致任务运行很缓慢甚至会超时呢？ 找到driver端， 用jstat -gcutil查看一下对应的gc情况(对应的内存都是调优完后的镜像
SPARK的计算向量化-已有的向量化项目
monkeyboy_tech的博客
05-30 4150
背景 在SPARK的计算向量化-spark本身的向量化中，我们提到spark是利用代码生成（生成for循环），从而JIT进行向量化。这是有局限的，所以大部分公司都会采用通过其他方式来进行向量化计算。 我们列举几种已知的应用到spark计算引擎的向量化技术。 Velox Meta（也就是Facebook）开源的一个C++实现的SQL执行引擎，输入逻辑执行计划，利用SIMD指令实现向量化操作，输出结果; 结合Apache Arrow作数据交换，可以实现Spark的计算向量化。 项目见facebookincuba
yarn和k8s(kubernetes)混合部署初步方案（利用cgroup资源限制）
monkeyboy_tech的博客
03-09 4064
版本 yarn 2.6.0 k8s v1.15.2 背景 随着k8s的越来越火热以及k8s的可扩展以及自修复优势，k8s势必是互联网的优势，但是很大一部分公司的资源管理工具依旧是yarn，而且yarn和k8s也必然并行很久一段时间， 但是由于yarn的隔离型相对于k8s来说还是很弱的，好在yarn 2.6.0版本也集成了LinuxContainerExecutor（默认是DefaultContainerExecutor），也就是说yarn在好长一段时间是不支持cpu限制的，LinuxContainerExe
SPARK Expand问题的解决(由count distinct、group sets、cube、rollup引起的)
monkeyboy_tech的博客
03-24 3850
背景 本文基于spark 3.1.2 我们知道spark对于count(distinct)/group sets 以及cube、rollup的处理都是采用转换为Expand的方法处理， 这样做的优点就是在数据量小的情况下，能有以空间换时间，从而达到加速的目的。 但是弊端也是很明显，就是在数据量较大的情况下，而且expand的倍数达到上百倍或者千倍的时候，这任务运行的时间很长（这在数分中是非常常见的）。 分析 先来看一组图： 是不是很刺激，数据从2,635,978,109直接扩张到了168,702,598,
深入解析Spark性能调优及Spark SQL项目分享
### 知识点概述 Apache Spark是基于内存计算的大数据处理框架...同时，通过分享一个基于Scala的Spark SQL项目代码，提供了实际的性能调优案例。开发者可以参照这些策略和方法，优化自己的Spark项目，提升性能和效率。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值