Spark调优-数据倾斜解决方案 原理及现象分析_spark数据倾斜生产分析

数据倾斜解决方案 原理及现象分析


项目，第一个模块，用户访问session分析模块


1、大数据开发流程（需求分析。。。性能调优）
2、用户行为分析的业务（聚合统计、随机抽取、topn、排序）
3、技术点：大数据项目模块的技术架构、spark core各种算子、自定义Accumulator、随机抽取算法、
分组取topn、二次排序
4、大数据项目中的性能调优和troubleshooting
5、完整的数据倾斜解决方案


数据倾斜


在任何大数据类的项目中，都是最棘手的性能问题，最能体现人的技术能力，最能体现RD（Research    Developer，研发工程师）的技术水平。
数据倾斜 = 性能杀手
如果没有丰富的经验，或者没有受过专业的技术培训，是很难解决数据倾斜问题的


因为上述的特点，数据倾斜解决方案，这块儿内容和技术，在咱们的这个模块，甚至是整个项目中，
都是非常非常核心、有含金量、有价值的。


Spark的数据倾斜解决方案，好好去学习，数据倾斜解决方案，将成为你面试、在公司里的一个个人的杀手锏！！！


假设我们有90万数据，然后有3个task，感觉上，平均来说，应该是每个task分到30万数据
在执行shuffle操作的时候，大家都知道，我们之前讲解过shuffle的原理。是按照key，
来进行values的数据的输出、拉取和聚合的。
同一个key的values，一定是分配到一个reduce task进行处理的。
多个key对应的values，总共是90万。但是问题是，可能某个key对应了88万数据，key-88万values，
分配到一个task上去面去执行。
另外两个task，可能各分配到了1万数据，可能是数百个key，对应的1万条数据。


想象一下，出现数据倾斜以后的运行的情况。
第一个和第二个task，各分配到了1万数据；那么可能1万条数据，需要10分钟计算完毕；
第一个和第二个task，可能同时在10分钟内都运行完了；第三个task要88万条，
88 * 10 =  880分钟 = 14.5个小时；


大家看看，本来另外两个task很快就运行完毕了（10分钟），但是由于一个拖后腿的家伙，第三个task，
要14.5个小时才能运行完，就导致整个spark作业，也得14.5个小时才能运行完。
导致spark作业，跑的特别特别特别特别慢！！！像老牛拉破车！
数据倾斜，一旦出现，是不是性能杀手。。。。


A、数据倾斜的原理
原理比较简单就是大量数据都到某个task里面去了


B、数据倾斜的现象


发生数据倾斜以后的现象：


spark数据倾斜，有两种表现：


1、你的大部分的task，都执行的特别特别快，刷刷刷，就执行完了（你要用client模式，
standalone client，yarn client，本地机器主要一执行spark-submit脚本，就会开始打印log），
task175 finished；剩下几个task，执行的特别特别慢，前面的task，一般1s可以执行完5个；
最后发现1000个task，998，999 task，要执行1个小时，2个小时才能执行完一个task。


出现数据倾斜了
还算好的，因为虽然老牛拉破车一样，非常慢，但是至少还能跑。


2、运行的时候，其他task都刷刷刷执行完了，也没什么特别的问题；但是有的task，就是会突然间，
啪，报了一个OOM，JVM Out Of Memory，内存溢出了，task failed，task lost，resubmitting task。
反复执行几次都到了某个task就是跑不通，最后就挂掉。


某个task就直接OOM，那么基本上也是因为数据倾斜了，task分配的数量实在是太大了！！！
所以内存放不下，然后你的task每处理一条数据，还要创建大量的对象。内存爆掉了。


出现数据倾斜了
这种就不太好了，因为你的程序如果不去解决数据倾斜的问题，压根儿就跑不出来。
作业都跑不完，还谈什么性能调优这些东西。扯淡。。。


C、数据倾斜的产生原因与定位


定位原因与出现问题的位置:


根据log去定位
出现数据倾斜的原因，基本只可能是因为发生了shuffle操作，在shuffle的过程中，
出现了数据倾斜的问题。因为某个，或者某些key对应的数据，远远的高于其他的key。


1、你在自己的程序里面找找，哪些地方用了会产生shuffle的算子，groupByKey、countByKey、
reduceByKey、join


2、看log
log一般会报是在你的哪一行代码，导致了OOM异常；或者呢，看log，看看是执行到了第几个stage！！！
去找找，代码那个地方，是哪个shuffle操作。