orc parquet区别 spark_spark 1.6 下parquet vs orc

背景

这都是现在大数据下比较火热的两种存储格式，orc和hive的关系可能要密切一点，但spark 对parquet寄予了厚望，

最近我们在测一个有join场景下的多个dataset的读取情况，这里简单写一下测试的一个结果，测试环境是spark1.6，数据在hdfs上，spark是local模式，集群的测试下周进行

join 后group，最后count

user的数据量在4000w左右，字段为4个字段，play选择的是1月1号，记录是1084966

先对比存储：

存储中横向对比了orc格式和parquet格式：

datatype\format

orc

parquet

playinfo

7.7M

7.6M

userinfo

97M

87M

此时存储可以看出两者差别不大，parquet略小于orc，不过在海量数据下这个差距会被放大，此时的字段毕竟只是4个字段的user和3个字段的play

再对比性能：

执行类似：

user.joinWith(play,"$"userUid"===$"playUid","inner").groupBy($"_1.thirdPartyName").count().show()

执行结果：

left

joinType

right

duration/ms

foramt

user

inner

play

44213

orc

user

outer

play

82484

orc

play

inner

user

43229

orc

play

outer

user

81112

orc

play

inner

user

23288

parquet

play

outer

user

62150

parquet

user

inner

play

22549

parquet

user

outer

play

64828

parquet

解释下这张表，left表示在左边的，因为数据量是不完全对称的，而join方式也测试了inner和outer两种jointype，duration是指这个job执行的时间，而format是两种数据格式

不过网络也很重要，在测试时候我的下载大概是3M/s

join 后groupBy 最后avg

第二步我测试了

user.joinWith(play,"$"userUid"===$"playUid","inner").groupBy($"_1.thirdPartyName").toDf.agg(sum("_2.durationsum")).show()

测试结果：

playDate

format

duartion

2016/01/01

parquet

27967

2016/01

parquet

93854

2016/01/01

orc

49551

2016/01

orc

116043

初步看1.6用spark作为执行引擎使用parquet格式性能有一定的提升，后期会集群再测一次，而且我观察到两种格式的shuffle size好像相差挺大，这一个也是后期要看的一个指标