Spark性能调优实战
吴磊
FreeWheel机器学习团队负责人
立即订阅
1166 人已学习
课程目录
已更新 10 讲 / 共 32 讲
0/4登录后，你可以任选4讲全文学习。
课前必学 (3讲)
开篇词 | Spark性能调优，你该掌握这些“套路”
免费
01 | 性能调优的必要性：Spark本身就很快，为啥还需要我调优？
02 | 性能调优的本质：调优的手段五花八门，该从哪里入手？
原理篇 (5讲)
03 | RDD：为什么你必须要理解弹性分布式数据集？
04 | DAG与流水线：到底啥叫“内存计算”？
05 | 调度系统：“数据不动代码动”到底是什么意思？
06 | 存储系统：空间换时间，还是时间换空间？
07 | 内存管理基础：Spark如何高效利用有限的内存空间？
通用性能调优篇 (2讲)
08 | 应用开发三原则：如何拓展自己的开发边界？
09 | 调优一筹莫展，配置项速查手册让你事半功倍！（上）
08 | 应用开发三原则：如何拓展自己的开发边界？
吴磊 2021-03-31
你好，我是吴磊。
从今天开始，我们就进入通用性能调优篇的学习了。这一篇，我们会从基本的开发原则、配置项、Shuffle 以及硬件资源这四个方面，去学习一些通用的调优方法和技巧，它们会适用于所有的计算场景。
今天这一讲，我们先从应用开发的角度入手，去探讨开发阶段应该遵循的基础原则。如果能在开发阶段就打好基础、防患于未然，业务应用的执行性能往往会有个不错的起点。开发阶段就像学生时代的考卷，虽然有很难的拔高题，但只要我们稳扎稳打，答好送分的基础题，成绩往往不会太差。
这些“基础题”对应的就是工作中一些“常规操作”，比如 Filter + Coalesce 和用 mapPartitions 代替 map，以及用 ReduceByKey 代替 GroupByKey 等等。我相信，你在日常的开发工作中肯定已经积累了不少。但是据我观察，很多同学在拿到这些技巧之后，都会不假思索地“照葫芦画瓢”。不少同学反馈：“试了之后怎么没效果啊？算了，反正能试的都试了，我也实在没有别的调优思路了，就这样吧”。
那么，这种情况该怎么办呢？我认为，最重要的原因可能是你积累的这些“常规操作”还没有形成体系。结合以往的开发经验，我发现这些“常规操作”可以归纳为三类：
确认放弃笔记？
放弃后所记笔记将不保留。
新功能上线，你的历史笔记已初始化为私密笔记，是否一键批量公开？
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《Spark性能调优实战》，如需阅读全部文章，
请订阅文章所属专栏
请订阅文章所属专栏
立即订阅
登录 后留言
精选留言(6)
October享受Tungsten带来的堆外内存的红利时，除了使用dataframe或dataset API之外，还需要在sparkconf中开启堆外内存吧作者回复: 你说的没错，默认是关闭的，这块细节咱们在后面的配置项章节和内存视角会有详细展开～
2021-03-31 1
斯盖丸老师yarn上实际跑的资源总是和自己spark-submit里提交的资源不一样，会略小一些，这是为什么呢？作者回复: yarn的node manager在创建executor的时候，会预留一部分资源给yarn自己，因此有一部分overhead，所以实际allocate给executor的内存，会比你指定的，要少一些，不过还好，没有少很多。
2021-04-01
布兰特所以，开启AQE之后，就不用手动处理数据倾斜了？完全的扔给Spark是嘛作者回复: 一般的倾斜可以交给aqe，不过aqe处理倾斜本身也有局限性，这个我们后面aqe那一讲再展开哈～
2021-03-31
蠟筆小噺在非Shuffle部分用RDD，在遇到Shufle部分调用toDF转换为DataFrame，这种方式可取吗？作者回复: 为啥不都用dataframe呢？rdd开发框架，享受不到catalyst和tungsten的性能红利，最好都在dataframe api下去开发
2021-03-31- 斯盖丸老师如果两个超大表，但是一张表重复数据很多，那是不是先做distinct，再join会好一些？毕竟虽然distinct会shuffle但最后join的数据量也是成倍减少的
作者回复: 对，在这个场景下，先用distinct节省数据量更合适。咱们能省则省、能拖则拖是一般性原则哈。不过先用distinct其实还是遵循了能省则省的原则。get到核心思想就好，灵活应用～
2021-03-31 1 
乐意至极老师，你好。我在实际工作中遇到这个问题ERROR RetryingBlockFetcher: Exception while beginning fetch of 520 outstanding blocks (after 1 retries) java.io.IOException: Failed to connect to <HOST/IP>:38000 持续了12小时
我有以下观察：
1，这个<HOST/IP>上的Executor已经SUCCESS了
2，这个持续了12小时的task是process local
3，无长时间gc，也无明显倾斜
排查了很久。。希望老师能给点指点~作者回复: 看上去是shuffle fetch的过程中出了问题，总是没办法成功拉取远端数据，之所以时间长，是因为task总是retry，不过居然最后都试成功了。也就是你的task从那个host不停地拉数据、不停地失败、不停地重试，在第4次fail之前，总能成功。基于这个猜测，我觉得看看那台主机的文件系统。如果文件系统没问题，就要看那台主机的负载，需要double check下是否真的没有大gc、数据是不是真的没有倾斜。
2021-03-31 2
收起评论