Spark Streaming使用场景及优化总结

2017-11-09 本文已影响308人分裂四人组

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

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

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

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

多个Action计算最好基于同一个RDD进行计算操作, 并且对相同的RDD进行Cache操作，避免重复计算，增加任务的执行时间；并且持久化级别最好使用MEMORY_ONLY_SER来减少内存使用；
在使用join的地方看是否可以使用map算子和广播变量的方式替代；
使用高效的算子，例如：使用reduceByKey/aggregateByKey来代替groupByKey,因为前者可以进行combiner操作，减少网络IO;

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

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

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

增加数据读取的并行度，比如读取Kafka的数据，可以增加topic的partition数量和executor的个数；
限制读取Kafka数据的速率，参数 spark.streaming.kafka.maxRatePerPartition
对于存在数据倾斜问题，有两类情况:
进行join操作，产生skew问题，可以使用map+广播变量类进行处理；
对redece/aggregate等聚合操作，参数skew问题，可以进行两次聚合的思想来解决， * 核心是先进行key进行随机数操作，是数据分布均匀，并进行聚合，最后是剔除随机数据，用实际数据来进行聚合操作。

参考：