都说spark那么牛，有没有啥坑啊( 四 )
2.HiveConf的初始化过程占用太多时间
频繁的hiveConf初始化，需要读取core-default.xml,hdfs-default.xml,yarn-default.xml
,mapreduce-default.xml,hive-default.xml等多个xml文件，而这些xml文件都是内嵌在jar包内的。
第一，解压这些jar包需要耗费较多的时间，第二每次都对这些xml文件解析也耗费时间。
3.广播broadcast传递的hadoop configuration序列化很耗时
lconfiguration的序列化，采用了压缩的方式进行序列化，有全局锁的问题
lconfiguration每次序列化，传递了太多了没用的配置项了，1000多个配置项，占用60多Kb。我们剔除了不是必须传输的配置项后，缩减到44个配置项，2kb的大小。
4.对spark广播数据broadcast的Cleaner的改进
由于SPARK-3015 的BUG，spark的cleaner 目前为单线程回收模式。
大家留意spark源码注释
其中的单线程瓶颈点在于广播数据的cleaner，由于要跨越很多台机器，需要通过akka进行网络交互。
如果回收并发特别大，SPARK-3015 的bug报告会出现网络拥堵，导致大量的 timeout出现。
为什么回收量特变大呢？ 其实是因为cleaner 本质是通过system.gc（）,定期执行的，默认积累30分钟或者进行了gc后才触发cleaner,这样就会导致瞬间，大量的akka并发执行，集中释放，网络不瞬间瘫痪才不怪呢。
但是单线程回收意味着回收速度恒定，如果查询并发很大，回收速度跟不上cleaner的速度，会导致cleaner积累很多，会导致进程OOM（YDB做了修改，会限制前台查询的并发）。
不论是OOM还是限制并发都不是我们希望看到的，所以针对高并发情况下，这种单线程的回收速度是满足不了高并发的需求的。
对于官方的这样的做法，我们表示并不是一个完美的cleaner方案。并发回收一定要支持，只要解决akka的timeout问题即可。 所以这个问题要仔细分析一下，akka为什么会timeout，是因为cleaner占据了太多的资源，那么我们是否可以控制下cleaner的并发呢？比如说使用4个并发，而不是默认将全部的并发线程都给占满呢？这样及解决了cleaner的回收速度，也解决了akka的问题不是更好么？
针对这个问题，我们最终还是选择了修改spark的ContextCleaner对象，将广播数据的回收 改成多线程的方式，但现在了线程的并发数量，从而解决了该问题。
推荐阅读
- 古人都说：“一颗绿萝七个鬼”，家中为什么忌讳养绿萝？
- 都说冬天要“少浇水”，家里有“4种花”要勤浇水，预防黄叶
- 为啥电器实体店的价格比淘宝贵那么多
- 为啥开通了百度云超级会员下载速度还是会那么慢
- 白皮书一般是政府发布的正式报告或文件，那么现在物联网、智慧城市等热门领域这么多企业发布的白皮书算咋回事呢
- 为啥网上那么多诈骗的都没人管
- 车神探|探闻丨C-NCAP提升标准！这一批测试的结果还那么水吗？
- 汽车驾驶|设计师邀海外人士，变速箱寄人篱下，弯道超车，哪有那么容易
- 凯迪拉克CT6|都说新辉昂回归百万级质感，看完后发现不假
- 趣头条|都说科三太难，但这些“技巧”没有掌握，就不要再说自己努力过