Spark Streaming使用场景及优化总结

SparkStreaming适合场景

Storm 流式计算（扶梯）
优点： 数据延迟度很低，Storm的事务机制要比SparkStreaming的事务机制要完善（什么是事务机制？对于一条数据，不多处理也不少处理，对于一条数据恰好处理一次，比如金融，股票等要求实时性比较高，那么就需要选Storm）

缺点：一直持有着资源，每一条数据都要在集群中某一台节点处理，要计算的数据会进行网络传输，吞吐量小，另外Storm不适合做复杂的业务逻辑（适合汇总）

SparkStreaming 微批处理（类似于电梯），它并不是纯的批处理
优点：吞吐量大，可以做复杂的业务逻辑(保证每个job的处理小于batch interval)
缺点：数据延迟度较高

公司中为什么选用SparkStreaming要多一些？
1.秒级别延迟，通常应用程序是可以接受的，
2.可以应用机器学习，SparkSQL...可扩展性比较好，数据吞吐量较高

Spark性能优化

代码优化

• 多个Action计算最好基于同一个RDD进行计算操作, 并且对相同的RDD进行Cache操作，避免重复计算，增加任务的执行时间；并且持久化级别最好使用MEMORY_ONLY_SER来减少内存使用；

• 在使用join的地方看是否可以使用map算子和广播变量的方式替代；

• 使用高效的算子， 例如：使用reduceByKey/aggregateByKey来代替groupByKey,因为前者可以进行combiner操作，减少网络IO;

当进行联合规约操作时，避免使用 groupByKey。举个例子，rdd.groupByKey().mapValues(_ .sum) 与 rdd.reduceByKey(_ + _) 执行的结果是一样的，但是前者需要把全部的数据通过网络传递一遍，

• 使用MapPartition来代替Map操作， 尤其是在需要网络连接的地方；

• 使用foreachPartition代替foreach操作，可以对数据进行批量处理；

• 在filter操作后，可以使用colease操作，可以减少任务数;

• 序列化尽量使用Kyro方式, 其性能更好;

• 减少对复杂数据结构的使用，可以有效减少序列化时间;

• 对应简单的函数，最好使用闭合结构，可以有效减少网络IO;

• 使用Repartition操作可以有效增加任务的处理并行度；

参数调整优化部分

经过实践验证，调整后有效的参数如下:

设置合理的资源；
Java垃圾回收器；
清理不必要的空间；

• 根据资源情况，可以添加Executor的个数来有效，参数为 spark.executor.instances

• 调整每个Executor的使用内核数, 参数为 spark.executor.cores

• 调整每个Executor的内存， 参数为 spark.executor.memory

• shuffle write task的buffer大小， 参数为 spark.shuffle.file.buffer

• shuffle read task的buffer大小， 参数为 spark.reducer.maxSizeInFlight

• 每一个stage的task的默认并行度， 默认为200， 建议修改为1000左右， 参数 spark.default.parallelism

• 用于RDD的持久化使用的内存比例，默认0.6, 参数 spark.storage.memoryFraction

• 用户shuffle使用的内存比例， 默认为0.2， 参数 spark.shuffle.memoryFraction

其它优化

• 增加数据读取的并行度，比如读取Kafka的数据，可以增加topic的partition数量和executor的个数；

• 限制读取Kafka数据的速率，参数 spark.streaming.kafka.maxRatePerPartition

• 对于存在数据倾斜问题，有两类情况:

• 进行join操作，产生skew问题， 可以使用map+广播变量类进行处理；

• 对redece/aggregate等聚合操作，参数skew问题， 可以进行两次聚合的思想来解决， * 核心是先进行key进行随机数操作，是数据分布均匀，并进行聚合，最后是剔除随机数据，用实际数据来进行聚合操作。

SQL 优化

• 开启spark.sql.autoBroadcastJoinThreshold；

• 合理配置spark.sql.shuffle.partition；

作者：分裂四人组
链接：https://www.jianshu.com/p/c896e2bdb6cb