Spark性能优化.docxVIP

Spark性能优化本文章来自于阿里云云栖社区摘要：?Spark的性能分析和调优很有意思，今天再写一篇。主要话题是shuffle，当然也牵涉一些其他代码上的小把戏。以前写过一篇文章，比较了几种不同场景的性能优化，包括portal的性能优化，web service的性能优化，还有Spark job的性能优化。Spark的性能优化有一些特殊的地方，比如Spark的性能分析和调优很有意思，今天再写一篇。主要话题是shuffle，当然也牵涉一些其他代码上的小把戏。以前写过一篇文章，比较了几种不同场景的性能优化（原文链接：/3658?spm=5176.100239.blogcont53509.5.zDcgU3），包括portal的性能优化，web service的性能优化，还有Spark job的性能优化。Spark的性能优化有一些特殊的地方，比如实时性一般不在考虑范围之内，通常我们用Spark来处理的数据，都是要求异步得到结果的数据；再比如数据量一般都很大，要不然也没有必要在集群上操纵这么一个大家伙，等等。事实上，我们都知道没有银弹，但是每一种性能优化场景都有一些特定的“大boss”，通常抓住和解决大boss以后，能解决其中一大部分问题。比如对于portal来说，是页面静态化，对于web service来说，是高并发（当然，这两种可以说并不确切，这只是针对我参与的项目总结的经验而已），而对于Spark来说，这个大boss就是shuffle。首先要明确什么是shuffle。Shuffle指的是从map阶段到reduce阶段转换的时候，即map的output向着reduce的input映射的时候，并非节点一一对应的，即干map工作的slave A，它的输出可能要分散跑到reduce节点A、B、C、D …… X、Y、Z去，就好像shuffle的字面意思“洗牌”一样，这些map的输出数据要打散然后根据新的路由算法（比如对key进行某种hash算法），发送到不同的reduce节点上去。（下面这幅图来自《Spark Architecture: Shuffle》链接：https://0/spark-architecture-shuffle/?spm=5176.100239.blogcont53509.6.zDcgU3）为什么说shuffle是Spark job的大boss，就是因为Spark本身的计算通常都是在内存中完成的，比如这样一个map结构的RDD：(String, Seq)，key是字符串，value是一个Seq，如果只是对value进行一一映射的map操作，比如（1）先计算Seq的长度，（2）再把这个长度作为元素添加到Seq里面去。这两步计算，都可以在local完成，而事实上也是在内存中操作完成的，换言之，不需要跑到别的node上去拿数据，因此执行的速度是非常快的。但是，如果对于一个大的rdd，shuffle发生的时候，就会因为网络传输、数据序列化/反序列化产生大量的磁盘IO和CPU开销。这个性能上的损失是非常巨大的。要减少shuffle的开销，主要有两个思路：减少shuffle次数，尽量不改变key，把数据处理在local完成；减少shuffle的数据规模。先去重，再合并比如有A、B这样两个规模比较大的RDD，如果各自内部有大量重复，那么二者一合并，再去重：1A.union(B).distinct()这样的操作固然正确，但是如果可以先各自去重，再合并，再去重，可以大幅度减小shuffle的开销（注意Spark的默认union和Oracle里面的“union all”很像——不去重）：1A.distinct().union(B.distinct()).distinct()看起来变复杂了对不对，但是当时我解决这个问题的时候，用第二种方法时间开销从3个小时减到20分钟。如果中间结果rdd如果被调用多次，可以显式调用cache()和persist()，以告知Spark，保留当前rdd。当然，即便不这么做，Spark依然存放不久前计算过的结果（以下来自官方指南链接：/docs/latest/programming-guide.html?spm=5176.100239.blogcont53509.7.zDcgU3）：Spark also automatically persists some intermediate data in shuffle operations (e.g. reduceByKey), even without users calling persist. This is done to avoid recomputing the entire input if a node fails during the shuffle.