spark程序优化总结

转行写spark程序快一年时间了，我最深刻的体会是实现功能容易，但如何提高程序的执行效率却是个难题。我们用的spark主要是spark sql框架，使用spark sql实现数据的清洗、抽取以及计算。期间，我们用了大部分的时间对程序做优化，现将对程序的优化方法总结如下：

在数据存储上，经过了从hdfs切换到cassandra，再从cassandra换到内存文件系统alluxio上。

1.1 hadfs存储

hdfs是hadoop的分布式文件系统，被设计成适合运行在通用硬件上的分布式文件系统。能够存储多种格式的数据，包括文本及parquet格式等等。它是一个主从结构，一个hdfs集群是由一个名字节点，它是一个管理文件命名空间和调节客户端访问文件的主服务器，当然还有一些数据节点，通常是一个节点一个机器，它来管理对应节点的存储，如下图1所示。hdfs对外开放文件命名空间并允许用户数据以文件形式存储。

图1 hdfs 架构图

　　hdfs内部是将一个文件分割成一个或多个块，这些块被存储在一组数据节点中。名字节点用来操作文件命名空间的文件或目录操作，如打开，关闭，重命名等等。它同时确定块与数据节点的映射。数据节点负责来自文件系统客户的读写请求。数据节点同时还要执行块的创建，删除，和来自名字节点的块复制指令。

1.2 cassandra存储

cassandra是一个面向带索引的Nosql数据库，数据是以松散结构的多维哈希表存储在数据库中。它最大的优点就是写速度非常快，并且由于有索引，可以避免重复数据的出现，有自动去重的功能，而读的速度却不那么尽如人意。

1.3 alluxio+parquet存储

由于使用hdfs和cassandra加载数据时，数据的加载时间就占用了很大部分，甚至占用了一半的时间。基于数据加载速度的考虑，后来采用alluxio存储需要加载的数据，使用hdfs作为持久层，这样数据可以直接从内存加载，加载的速度大大提高了。
　　现在的spark程序主要使用spark sql框架，程序结构如下图2所示。spark sql程序运行在yarn集群上，直接访问alluxio内存文件系统加载数据，持久化的数据存储在hdfs防止丢失。alluxio作为一个内存的文件系统，也可以存放多种类型的格式的文件，为了节省存储开销，提高访问速度，此处我们在alluxio上使用parquet格式存储数据。

图2 spark程序结构图

2.1 数据加载逻辑优化

由于程序计算需要加载的历史数据较多，而程序的每轮执行都要加载历史数据，历史数据的加载占用了数据加载的大部分时间。因此我们后来改用数据增量加载的形式，即将数据分天存放。每次程序重启时，先加载历史数据，即当天以前的数据，将历史数据加载后进行预处理后，保存在内存中。以后每轮就只需加载当天数据，再跟历史数据合并。这样以后每轮都避免了重新加载历史数据，并进行预处理的时间，显著地提高了程序的执行效率。

2.2 数据分区合并

我们使用alluxio，以parquet的格式存储源数据时，如果小文件过多，数据的加载速度会慢很多。因此在存储源数据时，建议使用coalesce将数据合并到几个分区中，以防止小文件过多。虽然reparation也能够实现分区聚合功能，但reparation会出现shuffle，严重影响spark程序的执行效率。

3.1 任务调度模式修改

spark的任务调度模式分为FIFO（先进先出）和FAIR（公平竞争）。FIFO的调度机制是将队列中的job按照先进先出的方式进行调度执行，而FAIR则按照是使需要资源较少的任务先执行，如所有任务都得按先进先出的方式，则小作业也被阻塞不能执行。设置调度模式的方式，只需一行代码如下：

sparkConf.set(“spark.scheduler.mode”,”FAIR”)


3.2 执行并行度参数设置

并行度决定了spark作业划分task的数量，一般情况下，task越多，程序执行的并行度就越高。但task数量也不能太多，因为task的创建也需要耗时间和内存资源。一般建议设置的并行度是num-executorsexecutor-cores的2-3倍。如果不设置，程序默认的并行度只是num-executorsexecutor-cores的不到2倍。

4.1 定义广播变量

大多数spark作业的性能主要就是消耗在了shuffle环节，因为该环节包含了大量的磁盘IO、序列化、网络数据传输等操作。因此，如果要让作业的性能更上一层楼，就有必要对shuffle过程进行调优。shuffle调优的一个途径就是尽可能地减少shuffle，在两个表join的过程中，如果一个表不会经常改变，同时数据量又不会太大时，将这个表广播出去，这样集群上的每个节点上都会保存这个表，这样需要join操作的另一个表就可以在自己的节点上完成关联操作，可以尽可能地减少shuffle。

4.2 减少数据倾斜

在进行shuffle的时候，必须将各个节点上相同的key拉取到某个节点上的一个task来进行处理，比如按照key进行聚合或join等操作。此时如果某个key对应的数据量特别大的话，就会发生数据倾斜。比如大部分key对应10条数据，但是个别key却对应了100万条数据，那么大部分task可能就只会分配到10条数据，然后1秒钟就运行完了；但是个别task可能分配到了100万数据，要运行一两个小时。因此，整个Spark作业的运行进度是由运行时间最长的那个task决定的。
　　因此出现数据倾斜的时候，spark作业运行得非常缓慢，甚至可能因为某个task处理的数据量过大导致内存溢出。数据倾斜的例子如下图所示，在三个节点上对应的以hello为key的总共有6条数据，这些数据都会被拉取到同一个task中进行处理，而以world为key的只有3条。实际情况中task可能个别key的数据量可能更大，比key少的可能多n多倍。因此key多的task的运行速度可能会比key少的task执行速度要慢n倍，而整个程序的执行速度是由最慢的task决定的。同时，如果某一个task处理的数据量过多的话，还会出现内存溢出的危险。

图3 数据倾斜案例

　　实际写spark程序时，要尽量避免出现数据倾斜的情况，如果出现上述现象时，原则是采用两阶段聚合的方式。首先针对某些key较多的数据，进行拆分，将一个key拆分成多个，比如上图3，对hello进行拆分，将hello前面加上1-10之间的任意随机数，变成1_hello，2_hello直到10_hello，对这些拆分后的key首先聚合，聚合后变成（1_hello,2），(2_hello,2)在再将这些随机数前缀去掉，再进行聚合，实现方式如下图4。

图4 数据倾斜处理案列

还有一种较为有效的办法是升级spark版本，spark 2.1版本较spark 1.6版本性能有更多的提升。其中的优势在《spark sql执行流程》的最后有所介绍。