在画像标签的加工和写入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 问题也是需要注意的
当然大家,也可以继续看看前面写的用户画像系列文章