Spark数据倾斜的问题

Spark数据倾斜业务背景

Spark数据倾斜表现

Spark的数据倾斜，包括SparkStreaming和Spark SQL，表现主要有下面几种：
1、Excutor lost，OOM，Shuffle过程出错
2、Driver OOM
3、单个Excutor执行器一直在运行，整体任务卡在某个阶段不能结束
4、正常运行的任务突然失败

数据倾斜产生的原因

以Spark使用场景为例，我们再做数据计算的时候会涉及类似 count distinct group by join on 等这种库宽依赖操作，这些都是会划分Stage，都会出发shuffe操作，一旦触发Stagec操作，所有相同的key就会被拉到一个或几个Reduce节点上，容易发生单点计算问题，进而导致数据倾斜。
一般来说，在Spark处理场景中，数据切斜的原因主要有几方面
1、Key分布不均匀：Key分布不均匀，哟躲着情况，比如有几个异常IP，量非常大，那可以先把这些异常大的IP通过抽样找出来，判断是否符合业务逻辑，如果不符合直接干掉，如果服务就把这些单独领出来处理，处理完再合并，当然还有其他情况吧，比如本身IP出现很多空值，group by的时候后者count(distinct)的时候也会出现出现数据切斜，这个时候就要使用随机韩函数打散，先1计算一次，再gourou by NULL的key。
2、建表时考虑不周：用户表和IP表，可能hi不同开发人员做的，用户表的IP默认为null,ip表的ip默认为0,这样去做关联的时候就直接数据切斜，在join on阶段就会直接卡死。
3、业务数据激增：比如上海的业务比较多，我们如果要统计同步城市的订单请款，这样一做group by 就可能直接数据倾斜了

分析解决数据倾斜问题的思路

定位导致数据倾斜的代码

上午的一些思路spark和hive都差不多，但是在分析定位层面因为两个原理不一样，自然就是不一样的。

对于Spark来说，数据倾斜只会发生在shuffle过程中。一般来说出现数据以威胁就是代码中的某些算子导致的，特别是能引起shufle操作的算子，恒可能就是其中一个
第一情况就是某个task执行特别慢的情况
首先要看的，就是数据倾斜发生在地基个Stage中，如果我们是采用clinet模式提交的，从cline的log中就可以看到是第几个stage，如果我们是采用cluster集群模式提交的，那么就是可以同Spark Web UI来查看当前运行的第几个stage,此外无论是使用client模式还是cluster模式，我们都可以在Spaek Web UI上深入的去查看Stage的task任务分配情况，进而确定是不是task分配数据导致的数据切斜，这个时候就需要去看task运行的时间和数据量，看运行时间的话，有些task几秒就我那层了，有些跑了几分钟都没没完，这个时候就能知道哪里出现数据切斜了，此外就是数据量，特别段的task任务可能就几百KB的数据，而运行时间业界长的需要处理几千KB。

指导是哪个Stage之后，一般来说就是其中的一个会造成stage划分的算子，比如count distngt 操作，join操作，group by 操作。

第二种情况就是某个task莫名其妙的出现了内存溢出的情况
这个怎说呢，不能说内存溢出就是数据切斜导致的，具体还是需要根据刚才说的查询方式去定位task的运行时间和原型数量，进而确定是那是不是因为数据切斜导致的内存溢出，因为内存溢出是Spark的一个正常的机制，内存不足就会溢出到磁盘上存储。还是要具体问题具体分析。

查看导致Key数据倾斜分布的代码

对Spark数据切斜的解决方案

Hive ETL预处理的办法，指标不治本，hiveETL也会发生Hive的数据倾斜，但是对于spark来说是非常友好的，避免了在spark任务中执行shuffle算子，各有好处，适合那种需要通过Spark处理hive表的应用场景

过滤少数导致数据切斜的Key，如果发现k导致数据威胁异常的就几个，那就过滤掉这些key，比如某一天SARK左右发生了OOM的时候，追查之后发现，是Hive表中的某一个key在那天的数据异常，导致数据量暴增，因此就采取每次执行前先进行采样，计算出笔记大的集合ley，直接先过滤掉。

提高shuffle的并行度，在解决数据切斜问题的时候，可以有限考虑这中方式，这是处理数据倾斜最简单的一种方式了。这个通通过shuffle read task，原理就是1个task如果要处理5个key，每个key有10条数据，那就是50条数据，现在我增加了并行度，task多了，现在每个task处理一个key，一个task就是只处理10条数据，自然task任务就优化了。

Spark数据倾斜处理小结