1. 数据序列化
默认使用的是Java自带的序列化机制。优点是可以处理所有实现了java.io.Serializable 的类。但是Java 序列化比较慢。
可以使用Kryo序列化机制，通常比Java 序列化机制性能高10倍。但是并不支持所有实现了java.io.Serializable 的类。使用 conf.set("spark.serializer", "org.apache.spark.serializer.KryoSerializer") 开启Kryo序列化。不使用Kryo做为默认值的原因是：需要注册自定义的类。例如：
val conf = new SparkConf().setMaster(...).setAppName(...) conf.registerKryoClasses(Array(classOf[MyClass1], classOf[MyClass2])) val sc = new SparkContext(conf)
注意：如果Object很大，需要在配置中增加 spark.kryoserializer.buffer 的值。如果没有在Kryo中注册自定义的类，Kryo也能正常工作，这些类会完全地保存下来（等于没有序列化就进行传输或保存了），会造成资源浪费。
2. 内存调优
可以考虑3个方面：（1）对象需要的总内存 （2）指向这些对象的指针 （3）GC
通常情况下，指针占用的空间将是原始数据的2~5倍。有以下几个原因：
（1）Java对象的“object header”(对象头)，包含了指向它的类的指针，占用16bytes。对于一些只有很少数据的object，16bytes要比对象本身占用的空间要多。
（2）Java String 中在原始String数据的基础上有另外40bytes的开销（String的保存形式是Char的数组，并且有length的额外数据）。因为String内部使用UTF-16编码，每个char 占用2个byte。因此10个字符的String，将会很轻易地占用60个bytes
（3）诸如HashMap，LinkedList 的集合类，使用链式结构，每个entry(Map.Entry)都有一个包装类。这些类不仅有“object header”，还有指向下一个对象的指针(通常是8个bytes)。
（4）基本类型的集合，通常会被包装成对象类型。
3. 内存管理
Spark中的内存使用主要有两类：执行内存和存储内存。执行内存是指shuffles, joins, sorts and aggregations计算时用到的内存。存储内存主要是指cache和集群间传播的内部数据用到的内存。执行内存和存储内存使用的是同一块区域。当没有计算执行时， 存储将获得所有这块区域的可用内存，反之亦然。执行比存储具有更高的获取内存的优先级，也就是说，如果内存不够时，存储会释放一部分内存给执行用，直到存储需要的最低的阀值。
有两个相关的配置，但是通常来说，用户不需要改变其默认值。
（1） spark.memory.fraction 表示使用的Java 堆内存的比例。默认值0.6. 剩下的40%的内存用于：（a）存储用户数据、Spark内部元数据 （b）防止OOM
（2）spark.memory.storageFraction 表示上面所说的存储内存最少占用的比例。默认值 是0.5
4. 确定内存消耗
最好的方式是生成一个RDD并cache，在web UI 中的 Storage 中查看占用了多少内存。
确定一个指定object 占用内存的大小，可以使用 SizeEstimator.estimate(obj) 方法。
5. 调整数据结构
减少内存消耗，首先应该避免使用基于指针的数据结构和包装对象等诸如此类的Java特性。有以下几种途径：
（1）数据结构优先使用对象数组和基本类型，尽量不使用Java和scala里的集合类（如：HashMap）。可以使用 fastutil (http://fastutil.di.unimi.it/) 提供的集合类和基本类型。
（2）尽量避免使用有很多小对象和指针的内嵌结构
（3）考虑使用数字ID 和枚举类代替作为key的String
（4）如果内存小于32GB，在Spark-env.sh 里设置 -XX:+UseCompressedOops，这样指针使用4bytes 而不是8bytes
6. 序列化RDD 存储
当你的 object 仍然很大，简单的降低内存消耗的方法是使用序列化的存储方法。强烈建议使用kyro序列化机制。
7. 垃圾回收调优
垃圾回收的时间主要是花费在寻找那些不再被引用的对象。因此它跟Java Object 的数量有关。我们应该使用具有较少object的数据结构（如：使用array代替linkedList）。一种较好的方法是用序列化的形式持久化Object，这样每个RDD partition 只有一个字节数组。
测量GC的影响：在Java option 中加入 -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps 后，可在worker 的 stdout 中找到GC的日志。
（1） 在任务完成之前，如果有多次full GC，说明执行任务的内存不够
（2） 如果有多次minor GC，但是 full GC 并不多，可以增大 Eden 区的大小
（3） 在GC的日志中，如果老年代快满了，减少 spark.memory.fraction 以降低cache所用的内存
（4） 尝试使用 G1 垃圾回收器（-XX:+UseG1GC）。如果堆比较大，应该增加 G1 区的大小（通过 -XX:G1HeapRegionSize 设置）
（5） 如果任务是从HDFS上读数据，HDFS 块的大小为 128M，块解压后的大小一般为原始大小的2~3倍，如果要运行4个task，可以估算Eden区需要 4*3*128M。
8. 其它
（1）并行度。除非你手动每步都设置较高的并行度，否则，集群不会被最大化地利用。Spark会自动根据每个文件的大小设置相应的task数量。对于诸如groupByKey，reduceByKey 等 reduce 操作，并行度为最大的父 RDD 的 partition 的数量。可以配置 spark.default.parallelism 设置默认的并行度。一般来讲，建议一个CPU 运行 2~3个task。
（2）Reduce Task 的内存使用。有时候，发生OOM并不是因为内存中放不下RDD，而是因为某个或几个task 分配的内存不够。例如：某个groupByKey 操作处理很大的数据集（因为数据倾斜的缘故）。 简单的解决方法是：设置较高的并行度。
（3）广播大的变量。 使用广播的功能能有效地减少序列化的 task 的大小和集群加载job的花消。如果你的task中需要使用一个来自driver的大的object（如：静态查询表），应该把它转化成广播变量。 Master端会打印序列化后的 task 的大小，通常如果大于20KB 的话，就值得去优化。
（4）数据本地性。数据本地性可分为以下几类：
（a） PROCESS_LOCAL 数据在运行代码的JVM中。
（b） NODE_LOCAL 数据和运行的代码在同一台机器上。如：当前节点上正好有HDFS的数据块。
（c） NO_PREF 数据可以较快获取，但是不在本地
（d） RACK_LOCAL 数据在同一 机架内，需要通过network获取
（e） Any 除上述外的数据
最好的情况就是 task 都运行在最好的数据本地性的环境，但通常不太可能。很多时候，某个executor 上的任务都完成了，而其它忙碌的机器上尚有未处理的data。Spark通常会等一段时间，以等待忙碌的机器空闲下来去处理数据（因为具有较高的本地性）。当超过这个等待时间后，空间的executor会把这些数据拉过来进行处理。每个数据本地性级别对应的等待时间可以查看配置中的 spark.locality 部分。通常默认的配置工作得蛮好的。如果你的task运行时间较长，可以增加这些值。