Spark Streaming 底层原理图以及性能

一、底层原理图

二、优化方案
2.1 使用Direct直连方式

Spark1.3中引入了Direct方法，这种方法不是使用接收器来接收数据，而是定期向Kafka查询每个topic和partition中的最新偏移量，并相应地定义要在每个批次中处理的偏移量范围。当启动处理数据的作业时，Kafka的简单消费者API用于读取Kafka定义的偏移范围（类似于从文件系统读取的文件）。该方法是直接将RDD中的分区连接到Kafka的分区上，使用kafka的底层API，这样读取数据的效率更高。但是需要自己维护偏移量

2.2 任务启动调优

如果每秒钟启动的task过于多，比如每秒钟启动50个，那么发送这些task去Worker节点上的Executor的性能开销会比较大，而且此时基本就很难达到毫秒级的延迟了。这时可以使用Task序列化：使用Kryo序列化机制来序列化task，可以减小task的大小，从而减少发送这些task到各个Worker节点上的Executor的时间。（Kryo序列化使用方法：val conf = new SparkConf().setAppName(s"${this.getClass.getName}").setMaster("local[*]") .set("spark.serializer","org.apache.spark.serializer.KryoSerializer")）

2.3并行度调优

并行度指的是Spark作业中，各个stage的task数量，代表了Spark作业的在各个阶段（stage）的并行度。
官方是推荐task的数量设置成spark application总cpu core数量的2-3倍，比如150个cpu core，基本要设置task数量为300~500。
这是因为在实际运行中，有些task会运行的快一点，比如50s就完了，有些task，可能会慢一点，要1分半才运行完，所以如果你的task数量，刚好设置的跟cpu core数量相同，可能还是会导致资源的浪费。比如150个task，10个先运行完了，剩余140个还在运行，但是这个时候，有10个cpu core就空闲出来了，就导致了浪费。那如果task数量设置成cpu core总数的2~3倍，那么一个task运行完了以后，另一个task马上可以补上来，就尽量让cpu core不要空闲，同时也是尽量提升spark作业运行的效率和速度，提升性能。

2.4 设置合理的批处理时间(batchDuration)。

在构建StreamingContext的时候，需要我们传进一个参数，用于设置Spark Streaming批处理的时间间隔。Spark会每隔batchDuration时间去提交一次Job，如果你的Job处理的时间超过了batchDuration的设置，那么会导致后面的作业无法按时提交，随着时间的推移，越来越多的作业被拖延，最后导致整个Streaming作业被阻塞，这就间接地导致无法实时处理数据。另外，虽然batchDuration的单位可以达到毫秒级别的，但是如果这个值过小将会导致因频繁提交作业从而给整个Streaming带来负担，所以尽量不要将这个值设置为小于500ms。在很多情况下，设置为500ms性能就很不错了。值就是我们要的最优值。
那么，如何设置一个好的值呢？我们可以先将这个值位置为比较大的值（比如10S），如果我们发现作业很快被提交完成，我们可以进一步减小这个值，直到Streaming作业刚好能够及时处理完上一个批处理的数据，那么这个值就是我们要的最优值。