用户画像系列——Spark任务调优实践

在画像标签的加工和写入hbase中，我们采用了spark来快速进行处理和写入。但是在实际线上运行的过程中，仍然遇到了不少问题，下面来总结下遇到的一些问题

1.数据倾斜问题

其实spark 数据倾斜思路和hive、mapreduce 数据倾斜思路处理类似，先看运行的任务，找到spark监控，active job -> stage -> task, 最终我们就能找到运行的task，可以看一些运行时长远超其他的task，同时处理的数据量也远超其他task，这种情况就是有数据倾斜了。

然后我们就可以对我们自己的数据进行分析：

可以很明显的看到前两条数据要比后面的其他数据量级要大，因此可以看出来存在数据倾斜。

数据倾斜的思路也是比较简单：

(1)可以在id前加随机前缀，先统计一次，然后去掉前缀再统计，这样就能解决数据倾斜问题了。

(2)或者有一些认为这种数据是脏数据可以直接过滤，丢弃掉也可以，需要根据业务场景进行判断。

2.任务处理很慢

一般这种情况，需要我们去看我们运行慢的任务，如果不存在数据倾斜问题，那就需要去分析运行的jstack 堆栈信息。（多观察刷新几次 观察堆栈信息，看看是不是一直在执行某个方法，说明一直在这里执行）

之前遇到代码死循环(这个明显是代码写错了)，一直卡在某个方法里出不来，也是通过查看堆栈信息发现的。

再有的优化手段：textfile 格式 优化成 parquet 格式（parquet格式⽀持⾃动split，当单个文件过大时spark读进来之后可以支持自动split），但是texfile是不支持的。

3.spark oom 问题

(1)driver 端 oom：spark collect 把大数据拉到了driver 端

(2)excutor 端 oom: mapPartitions 提供给了我们更加强大的数据控制力，怎么理解呢？我们可以一次拿到一个分区的数据，那么我们就可以对一个分区的数据进行统一处理，会加大内存的开销，可能会导致 oom 问题也是需要注意的

当然大家，也可以继续看看前面写的用户画像系列文章