【实践】spark streaming中的广播变量应用

1. 广播变量

我们知道spark 的广播变量允许缓存一个只读的变量在每台机器上面，而不是每个任务保存一份拷贝。常见于spark在一些全局统计的场景中应用。通过广播变量，能够以一种更有效率的方式将一个大数据量输入集合的副本分配给每个节点。Spark也尝试着利用有效的广播算法去分配广播变量，以减少通信的成本。
一个广播变量可以通过调用SparkContext.broadcast(v)方法从一个初始变量v中创建。广播变量是v的一个包装变量，它的值可以通过value方法访问，下面的代码说明了这个过程：

scala> val broadcastVar = sc.broadcast(Array(1, 2, 3))
broadcastVar: org.apache.spark.broadcast.Broadcast[Array[Int]] = Broadcast(0)

scala> broadcastVar.value
res0: Array[Int] = Array(1, 2, 3)

2. Spark Streaming 广播变量的更新

广播变量的声明很简单，调用broadcast就能搞定，并且scala中一切可序列化的对象都是可以进行广播的，这就给了我们很大的想象空间，可以利用广播变量将一些经常访问的大变量进行广播，而不是每个任务保存一份，这样可以减少资源上的浪费。

但是，现在项目中遇到一种这样的需求，用spark streaming 通过一些离线全局更新好的数据对用户进行实时推荐（当然这里基于一些spark streaming的内部机制，不能实现真正的时效性）：（1）日志流通过kafka获取 （2） 解析日志流数据，融合离线的全局数据，对每个Dtream进行计算（3）计算结果最后发送到redis中。

其中就会涉及这样的问题：（1）离线全局的数据是需要全局获取的，不能局部进行计算 （2）这部分数据是离线定期更新的，而spark streaming一旦开始，就长时间运行。如果离线数据更新了，如何在开始的流计算中，获取到这部分更新后的数据。

针对上述问题，我们可以直接想的一种方法是，在driver端开启一个附属线程，周期性去获取离线的全局数据，然后通过diver分发到各个task中。但是考虑到这种方式：spark streaming整体的性能开销会很大，并且重新开启的后台线程的不易管理。结合spark中的广播变量，我们采用另一种方式来解决以上问题：
1> spark中的广播变量是只读的，通过unpersist函数，可以内存中的相关序列化对象
2> 通过Dstream的foreachRDD方法，做到定时更新 (官网上有说明，该方法是在driver端执行的)

import java.io.{ObjectInputStream, O