- 系统背景
- spark streaming + Kafka高级API receiver
- 目前资源分配（现在系统比较稳定的资源分配），独立集群
--driver-memory 50G
--executor-memory 8G
--num-executors 11
--executor-cores 5
- 广播变量
1. 广播变量的初始化
1.1.executor端，存放广播变量的对象使用非静态，因为静态变量是属于类的，不能使用构造函数来初始化。在executor端使用静态的时候，它只是定义的时候的一个状态，而在初始化时设置的值取不到。而使用非静态的对象，其构造函数的初始化在driver端执行，故在集群可以取到广播变量的值。
2. 广播变量的释放
2.1.当filter增量为指定大小时，进行广播，虽然广播的是同一个对象，但是，广播的ID是不一样的，而且ID号越来越大，这说明对于广播来说，它并不是一个对象，而只是名字一样的不同对象，如果不对广播变量进行释放，将会导致executor端内存占用越来越大，而一直没有使用的广播变量，被进行GC，会导致GC开销超过使用上线，导致程序失败。
2.2.解决方案：这广播之前，先调用unpersist()方法，释放不用的广播变量
- 使用Kafka 的高级API receiver
1. 在使用receiver高级API时，由于receiver、partition、executor的分配关系，经常会导致某个executor任务比较繁重，进而影响整体处理速度
1.1.最好是一个receiver对应一个executor
2. 由于前段时间数据延迟比较严重，就想，能不能让所有executor的cores都去处理数据？所以调整receiver为原来的四倍，结果系统启动时，就一下冲上来非常大的数据量，导致系统崩溃，可见，receiver不仅跟partition的分配有关，还跟数据接收量有关
3. 在实际处理数据中，由于消息延迟，可以看到，有的topic处理速度快有的慢，原因分析如下：
3.1.跟消息的格式有关，有的是序列化文件，有的事json格式，而json的解析相对于比较慢
3.2.有时候拖累整个集群处理速度的，除了大量数据，还跟单条数据的大小有关
以下是程序跑挂的一些异常，和原因分析
