原文: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空间,且占用空间一般呈整数样式。