Spark性能优化之如何使用广播变量以及Kryo序列化

广播变量

在Spark Application中,经常会使用到一个共享变量,众所周知的,Spark是一个并行计算框架,对于这个变量,每一个executor的task在访问它的时候,都会去拷贝一份副本去使用。如下图所示:

对于这种默认方式,它会极大的系统的内存,我们可以假设一个集群中有1024个task,这个共享变量大小假设为1M,那么就会去复制1024份到集群上去,这样就会有1个G的数据在网络中传输,并且系统需要耗费1G内存去为这些副本分配空间,这样对于系统有什么影响呢?

如果系统内存不足,RDD持久化的时候无法在内存中持久化,需要持久化到磁盘中,那么后续的操作会因为频繁的磁盘IO使得速度变慢,性能下降。
当task中创建对象时,发现堆中内存不足,那么就需要进行GC操作,进行GC的时候,会导致工作线程暂停,如果内存严重不足,频繁的GC对于Spark作业的速度的影响是可想而知的。
对于以上问题,我们该怎么进行性能优化呢?

这时,我们可以使用Broadcast,将这种每个task需要用到的共享变量广播出去。

从上面的图中可以看到,当每一个task需要使用这个变量的时候都会拷贝一份。如果使用广播变量,首先该广播变量会拷贝一份副本到Driver中,当每一个executor的task使用到该变量时,首先会去每个executor的BlockManager中去检查是否有该变量的副本,如果没有,接着会去Driver中去拷贝一份副本到BlockManager中,然后供该executor中的每一个task使用,到下一个executor的task需要使用这个变量时,它的BlockManager可以去Driver中拷贝副本,也可以去距离比较近的executor的BlockManager中去拷贝。(每一个executor中的BlockManager的作用是负责管理每一个executor对应的内存和磁盘的数据。)其原理图如上所示:

在默认情况下,如果是1024个task需要消耗1G内存,但是如果我们有50个executor来平分这些task,那么只需要50个副本即可,总共消耗了50M内存,那么在内存的消耗了节省了大约20倍。而且副本的复制有时不需要从Driver拷贝,而是从其他executor中拷贝,那么,网络 传输带来的性能消耗也会小很多,可想而知,使用广播变量可以节省很多内存,从而使得性能显著提升。

如何使用广播变量呢?

比如我们的共享变量是一个map类型的变量,我们可以使用Spark上下文来创建广播变量:

Broadcast<Map<String>> broadcast=sc.broadcast(map);

在task中使用的时候可以使用value方法或者getValue方法来获取它的值:

Map<String> map=broadcast.value;

Kryo序列化

在上面通过广播变量降低网络传输压力以及节省了不少内存之后,我们可以再进一步的优化,序列化是一种不错的选择,可以减少数据占用的内存大小。

默认的Spark使用的是java序列化机制,即通过ObjectOutputStream / ObjectInputStream,对象输入输出流机制,来进行序列化。

使用默认的这种序列化机制,好处在于简单方便,不需要你自己进行任何配置,只需要在需要序列化的类上实现Serializable接口;缺点在于序列化的效率不高,序列化的速度比较低,序列化之后的数据占用空间依旧很大。因此,我们在必要时可以手动指定序列化方式进行优化。

Spark支持Kryo序列化机制,Kryo序列化机制,比默认的Java序列化机制,速度要快,序列化后的数据要更小,大概是Java序列化机制的1/10。

因此,使用Kryo序列化机制可以让 网络中传输的数据更小,而且在集群中耗费的内存也大大减少。

Kryo序列化作用的地方

Kryo序列化一旦启用,在以下几个地方将会生效:

算子函数中使用的外部变量。算子函数中使用到的外部变量,使用Kryo以后,优化网络传输的性能,可以优化集群中内存的占用和消耗
持久化RDD时进行序列化,比如StorageLevel.MEMORY_ONLY_SER。持久化RDD,优化内存的占用和消耗;持久化RDD占用的内存越少,task执行的时候,创建的对象,就不至于频繁的占满内存,频繁发生GC。
shuffle时进行序列化,可以优化网络传输的性能。
如何使用Kryo序列化

第一步:在SparkConf中设置序列化属性spark.serializer,值为org.apache.spark.serializer.KryoSerializer。

第二步:注册你需要使用Kryo序列化的一些自定义类,使用SparkConf.registerKryoClasses()
方法进行注册。

例如:

new SparkConf()
.set("spark.serializer", "org.apache.spark.serializer.KryoSerializer")
.registerKryoClasses(new Class[]{CategorySortKey.class})

使用广播变量和序列化很简单,但是我们不能忽视它对于系统性能的影响,也许一个小小的修改就能对系统的性能提升很多倍,这也是我们性能优化的重点,不能忽略每一个细节,一昧的去追去高大上的优化技巧。

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 204,793评论 6 478
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 87,567评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 151,342评论 0 338
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,825评论 1 277
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,814评论 5 368
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,680评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,033评论 3 399
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,687评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 42,175评论 1 300
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,668评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,775评论 1 332
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,419评论 4 321
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,020评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,978评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,206评论 1 260
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 45,092评论 2 351
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,510评论 2 343

推荐阅读更多精彩内容