Spark性能调优之道——解决Spark数据倾斜（Data Skew）的N种姿势

原文：http://blog.csdn.net/tanglizhe1105/article/details/51050974

背景

很多使用Spark的朋友很想知道rdd里的元素是怎么存储的，它们占用多少存储空间？本次我们将以实验的方式进行测试，展示rdd存储开销性能。 
关于rdd的元素怎么存储，Spark里面实现了好几种不同类型的rdd，如最常见的MapPartitionsRDD，它处理map,filter,mapPartition等不引起shuffle的算子；再如ShuffledRDD它由shuffle操作生成的；像GraphX里面的VertexRDD、EdgeRDD和TripletRDD，它们是分区内构建了大量索引得rdd。不同的rdd拥有不同的元素存储机制，这些机制由rdd具体的分区对象来实现。关于rdd分区对象的存储方式，由于内容过多，这里不便介绍。

测试方法论

rdd到底占用多少空间，使用spark web ui的Executors查看是不够的，它只能显示executor目前已使用内存空间大小，并不能跟踪每个rdd空间使用情况。好在spark提供了cache功能，它能使我们手动控制rdd在内存中贮存。若另外一个rdd使用已cache的rdd，那么它的输入便是cached rdd，rdd的输入在web ui的job信息里是可以查看的。本实验的主要方法便是如此

val a = sc.parallelize( 1 to 1024*1024, 1).cache()
a.count()
val b = a.map( x=> (x, x)).cache()
b.count()
val c = b.map(x => x)
c.count()

• 1
• 2
• 3
• 4
• 5
• 6

• 1
• 2
• 3
• 4
• 5
• 6

那么b.count()提交的job的输入能查看rdd a占用的内存空间大小，c.count()使得我们能查看rdd b占用的内存空间大小。

结果

元素数目	元素类型	rdd占用空间大小
1M	Int	32MB
1M	(Int, Int)	48MB
1M	(Int, Int, Int)	120MB
1M	Long	32MB
1M	(Long, Long)	56MB
1M	(Long, Long, Long)	120MB
1G	Int	32GB
1G	(Int, Int)	48GB
1G	(Int, Int, Int)	120GB
1G	Long	32GB
1G	(Long, Long)	56GB
1G	(Long, Long, Long)	120GB
10G	Int	240GB
10G	Long	246.7GB

本实验1M使用单个分区，1G使用80个分区（10个节点）,10G使用144个分区（18个节点）

1M与1G元素规模的结果吻合的太好了，以至于我都有不敢相信，可是测试出来的结果就是这样的，这也证明spark在数据规模可扩展性方面真是太完美了。 
关于每条元素的存储开销，若元素是Java对象存储，那么每条元素至少会带入18自己额外开销，若以基本数据类型存储，则不会带入额外开销。 
测试结果有一些诡异的地方： 
相同元素规模情况下，Int与Long占用空间相同，(Int, Int)与(Long, Long)不同，但(Int, Int, Int)与(Long, Long, Long)又相同。 
1M Int净存储空间为4MB，但占用32MB空间，且占用空间一般呈整数样式。