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