电话销售外呼软件/搜索seo优化托管

上一篇：spark优化三部曲（一）--瓶颈分析

下一篇：spark-优化三部曲（三）--参数优化

1.优化单个map内的逻辑

我曾经见过同事在单个map内对key做聚合，然后写双重for循环。然后问我webui看没有数据倾斜，但是始终会有一个map跑的很慢。

web ui判断数据倾斜的依据是input和shuffle量，如果输入的block很均匀，而且shuffle量很小，在web ui看起来，就是数据均匀的。

但是上述例子中，会发生在某个map大部分key对应1W的数据，然后某个key有5W的数据。（其实对于大数据而言这个数据量真的还好），双重for循环后直接数据爆炸。所以这种代码逻辑是不合理的，需要想办法减少这种情况。

2.缓存

对于重复使用的rdd/dataset/table等，考虑缓存

需要注意的是，缓存是通常是lazy的，可以加一个count让其强制触发，spark.sql("cache table") 是立即触发的，合理利用这个机制，往往可以起到很好的效果。

rdd的默认缓存为MEMORY_ONLY

dataset和table默认的是MEMORY+DISK

DISK_ONLY在其他文章中通常认为比较低效（因为读写磁盘好像和再从hdfs读一次差不多），但是经过笔者测试，在一定数据范围内（我这里是500G内），dataset/spark sql的DISK_ONLY效果非常棒

3.shuffle优化

mapjoin，调整join的顺序，hint等，其实就是spark cbo和 aqe的思想，但如果是离线作业，中间结果大小相对固定，我们应该可以提前预知应该怎么join才是最合理的。

4.合理的设置分区数

默认值为

spark.sql.shuffle.partitions=200 //建议设置为 num-executors * executor-cores * （2-3），即总并发度的2-3倍。 

对于特殊的任务，可以根据中间的shuffle结果在代码层面强制将其扩大或减小

5.spark rdd改为spark dataset/dataframe，spark sql

spark2以后，尤其是现在已经spark3了。

以spark sql为核心的 dataset/dataframe，正在逐渐替代rdd，基本上所有的业务逻辑都可以实现。

因为钨丝计划（Tungsten）的存在，spark sql通常是比rdd更高效的，感兴趣的同学可以查一下。