漫画全面解释Spark企业调优点

浪尖聊大数据

共 1471字,需浏览 3分钟

 · 2021-09-21

一:资源配置

一般企业中,物理机器的cpu:内存基本上都是1:4+,比如机器24core,一般有128GB及以上内存;48core,一般有256GB及以上内存。

减去系统及hdfs所需core,2个吧;减去系统的2-4GB,减去存储hdfs的相关的假设20GB吧(hbase需要的更多点,但是一般hbase会有独立集群)。

24core,128GB的机器应该还剩还有20core,100GB。

这种情况下,很明显,你1core对应5GB内存才能最大化利用机器,否则往往cpu没了,内存还有大把,应用还容易出现gc问题。

所以,假设你的业务cpu确实消耗比较少,可以在配置yarn的时候虚拟cpu可以设置为物理cpu的n倍。这样才可以满足小白,1:1的分配cpu内存的需求。

yarn.nodemanager.resource.cpu-vcores 

二:数据倾斜

1.对于离线,任务生成文件的时候,可以采用支持分割的压缩算法。常见的压缩算法如下:

对于离线,任务生成文件的时候,也可以合理控制生成文件的大小,落地之前进行均衡。

2.对于实时,生产者生产数据到kafka的时候,进行均衡,一般可以采取随机或者轮训的生产。假设要保证相同用户的数据到相同的分区,也可以对实用hash的方式。

1.遇到shuffle过程中数据倾斜的时候,往往需要做的第一件事情就是增大shuffle并行度,只要不是key过于集中与某一个或者几个key都会有效。

2.假设key过于集中,有以下几个策略可以用来改善:

2.1 先跑采样wordcount,看看key的集中情况。

2.2 个别key特别大,可以拿出来单独处理。

2.2 一堆key特别大,可以如下操作:

key加随机后缀,分两次进行聚合,比如随机后缀的范围是0-100,相当于并行度扩大了100倍,最后再聚合一次即可。

2.3 join的时候key倾斜。

  • 大表 join 小表,广播小表。

  • 大表 join 大表,预先治理,采用相同分桶策略,使得同一个task完成join,减少数据shuffle传输。后面案例详解。

三:大状态

1.用户自己管理的大状态。

    1.1 超时,可以使用具有超时功能的超时的map,如caffeine。

    1.2 确认状态是不是可以进行分区缓存。

    1.3 换外部内存存储,如redis,alluxio。

2.updateStateBykey等算子。

   2.1 设置超时时间,spark新版本都支持了,之前版本需要自己维护超时时间。

   2.2 换外部内存存储,如redis,alluxio。

四:大对象

如下面一段代码:

distData.foreach(each=>{      val map = new mutable.HashMap[String,Int]();      map.put("key",2)      // 逻辑处理      map.clear(); // 不要忘了哦    })


假设处理的数据量大,每条数据区new map而不执行clear清空,等垃圾回收,数据量大的时候,就会超级耗费性能,java或者scala的集合都要排查下。

浏览 11
点赞
评论
收藏
分享

手机扫一扫分享

举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

举报