spark mapside性能优化

1,314次阅读
没有评论

spark
这周做了一个数据分析,自己也有一段时间没有写spark代码了,一些性能优化的点都忘记差不多了,也可以说对这个还是没有深刻的理解导致的。具体的问题对一批数据聚合,key本身数量还是不多的,只有几千个,但是聚合报错了,核心报错是

Container killed by the ApplicationMaster Exit code is 143

查看原因在于Memory这块分配问题,试着加大executor memory 和 driver 端端,以及java heap space 内存到10g+ 最后勉强可以跑一下,但是这个的确不是最优的,这个设置实太大了,程序本身是有问题的。

ok,回头去看数据,其中一个环节就是groupbykey的操作,实现数据聚合,那么如果一个key 包含几亿的数据,那么聚合在一起就有可能 oom 的问题。现在的问题就在这里,如何优化这个,其实到这一块谷歌搜索一下也能找到答案了。

如果继续看那我就多说几句关于这个优化相关的理论。map-side预聚合闪亮登场。

map-side 预聚合,说的是在每个节点本地对相同的key进行一次聚合操作,类似于MapReduce中的本地combiner。 map-side预聚合之后,每个节点本地就只会有一条相同的key,因为多条相同的key都被聚合起来了。其他节点在拉取所有节点上的相同key时,就 会大大减少需要拉取的数据数量,从而也就减少了磁盘IO以及网络传输开销。

为了说明 map-side预聚合,先看下没有聚合的怎么做的

spark

以上操作问题很大,出现大量的shuffe ,网络io会导致很慢,还有一个问题,在一个进程里某一个key 积累了大量的数据导致oom。这个只有在数据量很大的时候才会有明显的问题,数据少还是感知不到的。

接下来隆重出场的是map-side聚合的操作过程

spark

通过预聚合数据量会急速减少,这样在进行二次聚合的时候数据量很少,速度就更快了。

接下来就直接给结论了:使用reduceByKey/aggregateByKey 替代 groupByKey

admin
版权声明:本站原创文章,由 admin 2022-03-06发表,共计832字。
转载说明:除特殊说明外本站文章皆由CC-4.0协议发布,转载请注明出处。
评论(没有评论)