spark rddストレージオーバーヘッド分析

背景

多くの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()

では、b.connt()がコミットした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
本実験では,1 Mは単一パーティション,1 Gは80パーティション(10ノード),10 Gは144パーティション(18ノード)を用いた.
1 Mと1 G要素の規模の結果が一致してよかったので、信じられませんでしたが、テストした結果はこうでした.これはsparkがデータ規模の拡張性において本当に完璧であることを証明しています.各要素のストレージオーバーヘッドについて、要素がjavaオブジェクトストレージの場合、各要素は少なくとも18個の追加オーバーヘッドをもたらし、基本データ型で格納されると、追加オーバーヘッドは発生しません.テストの結果、同じ要素の規模の場合、IntとLongの占有空間は同じで、(Int,Int)は(Long,Long)とは異なるが、(Int,Int,Int)は(Long,Long,Long)と同じである.1 M Intの正味記憶空間は4 MBであるが、32 MBの空間を占有し、占有空間は一般的に整数様式である.