简单搞定Spark性能优化:性能优化概览

一、spark性能优化概览

  由于Spark的计算本质是基于内存的，所以Spark性能程序的性能可能因为集群中的任何因素出现瓶颈：CPU、网络带宽、或者是内存。如果内存能够容纳得下所有的数据，那么网络传输和通信就会导致性能出现瓶颈。但是如果内存比较紧张，不足以放下所有的数据（比如在针对10亿以上的数据量进行计算时），还是需要对内存的使用进行性能优化的，比如说使用一些手段来减少内存的消耗。

Spark性能优化，其实主要就是在于对内存的使用进行调优。因为通常情况下来说，如果你的Spark应用程序计算的数据量比较小，并且你的内存足够使用，那么只要运维可以保障网络通常，一般是不会有大的性能问题的。但是Spark应用程序的性能问题往往出现在针对大数据量（比如10亿级别）进行计算时出现，因此通常来说，Spark性能优化，主要是对内存进行性能优化。当然，除了内存调优之外，还有很多手段可以优化Spark应用程序的性能。

 

二、spark性能优化方向

Spark的性能优化，主要手段包括：

1、使用高性能序列化类库

2、优化数据结构

3、对多次使用的RDD进行持久化 / Checkpoint

4、使用序列化的持久化级别

5、Java虚拟机垃圾回收调优

6、提高并行度

7、广播共享数据

8、数据本地化

9、reduceByKey和groupByKey的合理使用

10、Shuffle调优

 

三、spark性能优化的重要性

实际上Spark到目前为止，在大数据业界的影响力和覆盖度，还远没有达到Hadoop的水平，——虽然说，我们之前一再强调，Spark Core、Spark SQL、Spark Streaming，可以替代MapReduce、Hive查询引擎、Storm。但是事实就是，Spark还没有达到已经替代了它们的地步。

根据我在研究Spark，并且在一线使用Spark，与大量行业内的大数据相关从业人员沟通的情况来看。Spark最大的优点，其实也是它目前最大的问题——基于内存的计算模型。Spark由于使用了基于内存的计算模型，因此导致了其稳定性，远远不如Hadoop。虽然我也很喜欢和热爱Spark，但是这就是事实，Spark的速度的确达到了hadoop的几倍、几十倍、甚至上百倍（极端情况）。但是基于内存的模型，导致它经常出现各种OOM（内存溢出）、内部异常等问题。

说一个亲身经历的例子，曾经用Spark改写几个复杂的MapReduce程序，虽然MapReduce很慢，但是它很稳定，至少慢慢跑，是可以跑出来数据的。但是用Spark Core很快就改写完了程序，问题是，在整整半个月之内，Spark程序根本跑不起来，因为数据量太大，10亿+。导致它出现了各种各样的问题，包括OOM、文件丢失、task lost、内部异常等等各种问题。最后耗费了大量时间，最一个spark程序进行了大量的性能调优，才最终让它可以跑起来。的确，用了Spark，比MapReduce的速度快了十倍，但是付出的代价是惨痛的，花了整整一个月的时间做这个事情。

因此，当我在公司推广Spark的使用时，很多人都不无担心地说，听说Spark还不够稳定，经常出现问题，比如OOM等，它的稳定性，导致业界的人们不太敢轻易尝试它，在复杂的大数据系统，要求极高稳定性的线程系统中使用。——当然，如果你就是开发一个针对公司内部的，稳定性要求不高的系统，当然不用担心这个问题。所以，我认为，Spark的基于内存的本质，就导致了上述的问题，导致了它目前还无法完全提到Hadoop中的某些技术。但是，纵然Spark有各种问题，其优点就是缺点，缺点也是优点——它实在是很快。优秀的Spark应用程序，性能完全可以达到MapReduce、Hive查询引擎的数倍、甚至数十倍。因此，纵使有各种担忧，Spark还是吸引着大量的人们以及公司去探索，和尝试攻克它，使用它，让它为我们所用，用它开放更棒的大数据系统。