02 | 性能调优的本质：调优的手段五花八门，该从哪里入手？
先入为主的反例
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
本文深入探讨了性能调优的本质和方法，强调了性能调优是一个动态、持续不断的过程。作者指出，性能调优的关键在于找到性能瓶颈并针对瓶颈进行优化。文章提出了两种定位性能瓶颈的途径：专家经验和运行时诊断，并介绍了从应用代码和Spark配置项两个层面展开性能调优的方法。性能调优的最终目的是在所有参与计算的硬件资源之间寻求协同与平衡，达到无瓶颈的状态。作者总结了性能调优的本质和系统化的方法论，强调了动态、灵活地切换调优方法的重要性。最后，作者提出了两个问题供读者思考，并欢迎读者在评论区留言交流。整体而言，本文为读者提供了系统化的性能调优方法论，帮助他们更好地理解性能调优的本质和方法。
《Spark 性能调优实战》，新⼈⾸单¥59
全部留言(15)
- 最新
- 精选
October老师讲到可以通过运行时诊断来定位系统瓶颈，可借助于spark ui以及系统级监控工具，但是我依然不清楚怎样查看spark ui的各个指标，怎样查看每个应用程序的各种硬件负载，不知道老师后边的课程有没有相关内容作者回复: 好问题，不过专栏最开始的计划没有包含这部分，原因是这部分其实网上都能查到，不过如果后续大家对这块疑问较多，到时候咱们也可以加餐，专门说说监控的事儿。
2021-03-172122
seed1. 还遇到的调优手段：直接从网上copy过来一些参数，在没有理解真正的原理的情况下，先怼上去，跑一下，任务时间缩短了就算调优了 2. 对于性能调优的收敛状态，需要量化；如何量化这些指标？ 其实就是从我们需要调优的点出发；文中提到：从硬件的角度来看，计算负载划分为计算密集型、内存密集型和 IO 密集型。 首先需要确认我们的任务属于哪一类型的任务或者说任务的短板在哪一块 其次从Spark任务执行时长，系统的cpu/memory/io等方面按照任务类型有针对性的进行监控 然后从应用代码和Spark配置项两个方面入手进行调优 最后在每次调优后重点关注任务时间是否下降，对比下降前后系统的cpu/memory/io的使用量，就可以做到量化作者回复: 说得非常好！ 1的场景非常常见，很多时候都是知其然，而不知其所以然，稀里糊涂就算完事了，交差就行。 2的回答满分💯，无可挑剔。
2021-03-17319
裘元飞希望老师可以稍微讲一讲例如spark UI等工具如何监控指标等，主要很多时候都不知道有这些工具的存在。作者回复: 可以的，后面找机会讲一讲，到时候看大家需要，可以开个直播当面讲，比较直观，图文讲UI很多细节都说不到。
2021-03-1810- Sandy老师，已经学完课了，发现没有讲运行时诊断分析析定位性能瓶颈呢？
作者回复: 好问题，这部分咱们主要是给出了方法论，确实没有介绍具体的监控方法。是这样的，一般定位性能瓶颈，我们都会从硬件的计算资源出发。我们往往把一项操作、或者计算，归类为CPU密集型、内存密集型、I/O密集型和网络密集型。对于不同硬件资源的消耗，我们会推荐使用不同的系统命令，或是可视化的监控工具（如Ganglia、Prometheus等），工具这块咱们文中有举例。 这块不太好讲，难点在于，我们需要结合非常具体的cases，来介绍具体的方法，但是介绍的方法，不见得适用你日常开发中遇到的cases。所以咱们只抛出了方法论，却没有深入介绍具体的方法。 不过，其实即便没有这些工具辅助，或者没有案例分析，结合经验，我们也能大概知道哪些操作属于哪种密集型操作，从而有的放矢地去调整不同资源消耗的平衡，比方说： CPU密集型：（解）压缩、（反）序列化、hash、排序 内存密集型：大量的RDD Cache、DataFrame Cache、数据倾斜场景，等等 磁盘密集型：Shuffle 网络密集型：Shuffle 实际上，不止是磁盘与网络，Shuffle会消耗所有的计算资源，因此一般来说，在Spark的应用当中，99%的性能瓶颈，都来自Shuffle。因此，一旦把Shuffle这头拦路虎干掉，性能往往呈数量级地提升。 东一榔头、西一棒子，说的有点乱，不知道能不能回答你的困惑，有问题再讨论哈~
2021-07-079 
Shockang王家林，段智华，夏阳编著的《Spark大数据商业实战三部曲》里面提到——大数据性能调优的本质是什么?答案是基于硬件的调优,即基于CPU、Memory、I/O(Disk/Network)基础上构建算法和性能调优! 无论是Hadoop,还是Spark,还是其他技术,都无法逃脱。 老师也在文章中提到——性能调优的最终目的，是在所有参与计算的硬件资源之间寻求协同与平衡，让硬件资源达到一种平衡、无瓶颈的状态。 我认为有异曲同工之妙！作者回复: 没错，性能调优的本质，其实就是用软件驱动硬件，让硬件在运行时能够高效协同，充分压榨每一类硬件资源的“剩余价值”。最早在IBM那会，可能是2011年吧，我们做IBM智能分析系统一体机，就是用软硬搭配的方式做数仓。那会对于硬件资源的协同，我们甚至有量化的比例，我记得是1:4:8，1cpu：4g内存：8块SAS盘。那会很早了，还用RAID阵列来提高I/O效率，当时网络用了最高配置，应该是万兆网我记得。虽然说场景不同，但是以硬件资源平衡为导向的思路，如出一辙。
2021-03-1739- Geek_32772e吴老师，我没听说过有文章说不建议使用UDF，您能给我发几个链接证实下吗？
作者回复: 太多了，可以随便在搜索引擎里面搜“Spark UDF performance”之类的关键字，（用Google或是Bing的国际版），比如这里：https://stackoverflow.com/questions/38296609/spark-functions-vs-udf-performance，非常详尽地介绍了UDF与Spark原生的SQL functions性能差在哪里~ 另外，建议关注Databricks官方的技术博客，里面也有几篇讲到UDF与Spark原生SQL functions之间的性能差异，我稍后翻到了再发给你~
2021-05-267 
薛峰第一个估计大家都有过那样的经验 第二个问题，我用过两种方法： 1. 用Prometheus+grafana监控系统利用情况。结果意外发现spark不会自动清除应用目录，导致过段时间磁盘都被塞满了。不知道是不是因为spark配置的错误导致的？ 2. 用不同的参数跑同样的数据N次，然后平均处理时间，看看哪种最短。但经常会发现这个运算时间有较大幅度的浮动，不知道是不是跟aws系统整体的忙闲有关。作者回复: 1. 对，两个不错的监控工具～ 运行时监控系统利用率。另外，spark应该自动清除临时目录，听上去是个bug。 2. 后验是最实在的方式，不过这块，就像你说的，要注意系统误差，也就是你得保证n次尝试的运行时环境是一样的，否则的话很难判断，是调优的作用，还是系统变化。
2021-04-094
L3nvy1. 不知道怎么分析性能瓶颈问题，按照自己的理解把业务逻辑Spark SQL重写了一遍，虽然时间下降了，但是引入了数据质量等问题。 2. 需要监控组件对机器的状态和系统metrics进行收集对比优化效果作者回复: 没错，1是典型的盲目调优，2的思路很赞～
2021-03-172
浩然我想讨论一个问题。那个38分钟的执行结果，资源配置上很足，但是执行效率不好。能认为是把CPU用的太多了，资源调度有问题？比如CAS自旋锁以及锁升级？作者回复: 好问题，我倒不觉得是资源调度的问题，而是任务调度的问题。可以看到，执行效率不高的几个case，都把并行度设置的很大，并行度高就会存在任务调度开销过大的隐患，从而造成CPU看上去很忙，但忙的都不是“正事”，都忙着去调度任务了，而不是忙着执行任务。后面的CPU利用率那一讲，会详细聊这些内容，不妨关注一下~
2021-10-111
西南偏北1. 最初在写Spark应用的时候，网上搜一些调优手段，动不动就是让增加内存、增加CPU，什么问题都是增加内存CPU 2. 如果是搭建的CDH平台的话，可以结合Spark WebUI和Cloudera Manager Web UI做一些监控资源的对比，比如任务运行时间、cpu使用率、内存使用率等指标。另外，也可以安装Prometheus+Grafana进行更精细化的监控。 希望老师在之后的篇章中，讲具体调优方法的时候，能多结合一下原理和源码来分析下为什么要这样调优。作者回复: 对，第一个是非常的典型case~ 第二个监控也没问题，可以结合你说的这些工具，对硬件资源的消耗情况进行量化监控，现在的UI都做得比较到位了，指标既丰富又直观。 另外，后面的章节安排，大体上就是按照你说的思路展开的哈~ 😁
2021-05-011
