Spark调优笔记1

一、调优原因

        今年随着一部分原始日志的数据量快速增长，目前已经翻了3-4倍左右，导致目前系统凌晨的etl任务中有一部分spark任务的整体处理时长即将超出阈值，可能会造成不同任务之间的互相干扰。因而此处spark有待调优。

        而且临界新年，新年数据量势必大量增长，不想过年放假的时候处理故障。

二、调优方案

        此处spark任务主体逻辑是，读取hive上的日志文件，过滤主题后经过一些系列的处理、计算，再写入的hdfs上，最后挂载到hive中。计算有一部分采用RDD api实现，有一部分采用DataFrame api实现。

1、优化点一：cache

        回顾代码发现，有一部分写过的cache算子被注释了，原因是因为早期服务器内存太少，cache使用后日志中存在大量block申请不到内存的warn警告，因此注释了（早期理解有偏差，采用磁盘存储级别即可）。目前服务器扩容了一些内存，资源相对可观了点，因此可以继续使用cache算子。

        另外重新梳理一部分代码的处理流程，有一个spark的应用，其中也存在着重复使用的rdd没有cache的情况。此处加上了cache。

2、优化点二：repartition

        首先大数据场景下的小文件问题大家都知道，spark的每个task都会输出一个文件，因此并行度过高的话，小文件的问题是很严重的。

        spark从hdfs读取文件时如果不主动声明并行度的话，他会根据文件大小自动判别并行度，如果只有一个stage的话可能会生成大量的小文件。

        spark再shuffle read阶段默认的并行度为200，如果任务数据量并不大，采用默认并行度的话也会产生大量的小文件。

        为了解决这个问题，spark提供了两个算子coalesce和repartition来显示的调整并行度（根据官方的解释：两者一个是不经过shuffle调整并行度，一个是经过shuffle调整并行度）。我们都知道spark的shuffle是主要影响性能的关键之一，因此早期采用coalesce(1)这样的方式使数据写入到一个文件中（为啥非一个文件我忘记了，可能也是当时理解的偏差）。

        随着前一段对spark内核源码的研究，我对spark的coalesce的功能产生了怀疑，具体可以参考另一篇文章。CSDNhttps://mp.csdn.net/mp_blog/creation/editor/122915099        大体是，由于coalesce不会切分stage，因而如果再当前stage中的coalesce(1)算子之前还有一个或多个map算子的话，这几个map算子的处理并行度也都会下降为1。我们知道，分布式计算就是通过多机、多进程、多线程的分治思想来提高计算性能的，如果这几个map阶段的并行度都只有1的话，其计算性能势必会收到很大影响。

        而reparition不一样，他会切分stage因此缩减分区不会影响前面的map算子的并行度。

        因此，此处我采用的repartition代替coalesce。

三、调优效果

        平均的处理时长缩短了40%左右。

        调优前

        调优后