记录一次spark sql的优化过程

1、背景

集群有一个spark sql的任务，每天需要跑38561秒，噢，来计算一下38561/60/60 这就是10.7个小时呀，就是下面那这种样子：

2、排查过程

2.1 查看任务日志

发现第9个job跑了10.4h，那一定就是这个job有问题了，点进去继续看

Stage_id为23的运行了10.4h，其它的只用不到2min，点进去继续看

按照Task Time倒序排列，发现有个服务器运行了10.4h，并且shuffle spill了1T多的数据，没得说，老毛病，肯定是数据倾斜，继续巴拉巴拉日志

发现该服务除了出现少数几次OutOfDirectMeoryError外大部分的时间，都在写磁盘，从上午8点多写到下午5点47，这就更确认之前的假设是对的，数据倾斜。

2.2  数据倾斜发生的原因

数据倾斜的原因很简单：在进行shuffle的时候，必须将各个节点上相同的key拉取到某个节点上的一个task来进行处理，比如按照key来聚合或者join的时候，这时如果某个key 对应的数据量特别大的话，就会发生数据倾斜。 比如 大部分key对应10条数，而某个key却对应几百万条数，那么大部分task可能就只会分配到10条数据，然后1秒钟就运行完了；但是某个task可能分配到了几百万 条数据，要运行好几个小时。

整个Spark作业的运行进度是由运行时间最长的那个task决定的。因此出现数据倾斜的时候，Spark作业看起来会运行的异常缓慢，甚至可能因为某个task处理的数据量过大导致内存溢出。

数据倾斜发生在shuffle过程中。常用的并且可能会触发shuffle操作的算子：distinct、groupByKey、reduceByKey、aggregateByKey、join、cogroup、repartition等。出现数据倾斜时，可能就是sql中用到这其中某个算子导致的。

2.3 业务背景

大致的业务背景如下：

request –>广告竞价发出的request请求相关信息

response –>广告竞价对request的响应信息

error –> 错误的request信息