目录
1. 高吞吐的优化方式
1.1 更改序列化的方式
1.2 修改Receiver接受到的数据的存储级别
1.3 广播配置变量
1.4 调大接收器的个数
1.5 设置合理的批处理间隔
1.6 多给点资源
1.7 内存比例管理
1.8 垃圾回收机制
1.9 使用合适的算子
1.10 反压机制
2. 高可靠的保障
2.1 可重放的上游
2.2 checkpoint
2.3 wal
2.4 对运行状况做监控
3. 参考
作为Spark的流式处理框架，Spark Streaming基于微批RDDs实现，需要7*24小时运行。在实践中，我们需要通过不断的优化来保证它的高可靠，高吞吐。
本文从高吞吐和高可靠两个角度来简单介绍一下Spark Streaming中常用的一些优化方式。
1. 高吞吐的优化方式
1.1 更改序列化的方式
Spark在变量落盘或者序列化的时候会涉及到序列化。
Spark提供了Java自带的序列化和Kryo序列化。Kyro序列化比Java序列化更快，推荐使用Kyro序列化。
在Spark2.0后将Kyro序列化作为简单类型的默认序列化方式。对于我们自己的类，可以通过registerKyroClasses来注册。
1.2 修改Receiver接受到的数据的存储级别
Spark Streaming通过Receiver来接收数据，接收后会以StorageLevel.MEMORY_AND_DISK_SER_2的存储级别来存储数据。
将接收到的数据存储两份是为了有更好的容错性，如果你的Streaming程序做了其他的容错，就可以修改为其他的存储级别。
1.3 广播配置变量
对于要在多个Executor中都会用到的变量，可以将变量广播到每个节点上，减少数据传输的开销。
1.4 调大接收器的个数
对数据有序性要求不是很高的场景下，可以多起几个接收器来接收数据。
1.5 设置合理的批处理间隔
对于Streaming系统来说，只有系统的处理速度能赶上接受速度，整个系统才能稳定的运行，不然可能会出现OOM等问题。
批处理间隔的设置可以根据自己的数据量、处理速度、业务峰值等指标来合理估算一个适合自己的。
1.6 多给点资源
这是最基本的了，多分点CPU、内存，吞吐量蹭蹭的就上来了。
1.7 内存比例管理
内存主要用来存储和计算，可以根据自己的场景调整内存的占比。
1.8 垃圾回收机制
基于JVM运行的程序都能通过垃圾回收调优来获得一定的优化。
根据自己的场景选择使用CMS、G1....
1.9 使用合适的算子
对于要读写数据库的场景，肯定是在每个foreachPartition中维护一个连接，而不是每个foreach维护一个。
map和mapPartition同理了。
1.10 反压机制
上游太快，压力太大怎么办。
Spark Streaming中也提供了反压机制，可以设置参数来开启反压机制。
2. 高可靠的保障
2.1 可重放的上游
有个可重放的上游，就不是很怕丢数据了，起码可以保证至少一次。
2.2 checkpoint
通过开启checkpoint将元数据写到文件中，在程序失败重启后可以直接读取checkpoint
2.3 wal
预写日志。
上面也提到了Recevier会将接收到的数据存两份，但是那个可能会丢数据。
如果对可靠性要求较高，还是老老实实的开启wal，缺点就是会损失吞吐量。
2.4 对运行状况做监控
这个的话方法就多了：
记得Spark Streaming提供了一个接口，在每个批次处理前后可以做处理。感兴趣的可以研究。
写脚本对streaming程序进行监控报警
.....
3. 参考
《Spark Streaming实时流式大数据处理实践》
