广播变量的好处

问题描述：
将来数据量可能很大，所以ip规则肯定是存储在HDFS中的，这样在读取的时候根据切片数量，会启动相应的Task，但是数据切片中就可能不会包含所有的ip规则，然后你处理的log文件获取的ip就找不到对应的省份了。这样就出现了问题。所以现在需要每个Task都会获取到全部的ip规则。但是ip规则的数据是分片存放的，怎样让Task获取到全部的ip规则尼？这时就需要将每个切片的IP规则拉取到Spark Submit（Driver）端，然后再通过广播变量的形式下发到每个Executor中，每个Executor都会持有一份完整的ip规则，这样Task在处理log文件数据的时候，就可以拉取Executor中的IP规则了。

广播变量的好处
广播变量的好处，不是每个task一份变量副本，而是变成每个节点的executor才一份副本。这样的话，
就可以让变量产生的副本大大减少。

广播变量的用法
广播变量，很简单
其实就是SparkContext的broadcast()方法，传入你要广播的变量，即可
final Broadcast<Map<String, Map<String, IntList>>> dateHourExtractMapBroadcast = sc.broadcast(fastutilDateHourExtractMap);
使用广播变量的时候
直接调用广播变量（Broadcast类型）的value() / getValue()
可以获取到之前封装的广播变量
广播变量，初始的时候，就在Drvier上有一份副本。
task在运行的时候，想要使用广播变量中的数据，此时首先会在自己本地的Executor对应的BlockManager中，
尝试获取变量副本；如果本地没有，那么就从Driver远程拉取变量副本，并保存在本地的BlockManager中；
此后这个executor上的task，都会直接使用本地的BlockManager中的副本。
executor的BlockManager除了从driver上拉取，也可能从其他节点的BlockManager上拉取变量副本。
HttpBroadcast     TorrentBroadcast（默认）

BlockManager
负责管理某个Executor对应的内存和磁盘上的数据，尝试在本地BlockManager中找map
举例来说
50个executor，1000个task。一个map，10M。
默认情况下，1000个task，1000份副本。10G的数据，网络传输，在集群中，耗费10G的内存资源。
如果使用了广播变量。50个execurtor，50个副本。500M的数据，网络传输，
而且不一定都是从Driver传输到每个节点，还可能是就近从最近的节点的executor的bockmanager
上拉取变量副本，网络传输速度大大增加；500M的内存消耗。
10000M，500M，20倍。20倍~以上的网络传输性能消耗的降低；20倍的内存消耗的减少。
对性能的提升和影响，还是很客观的。
虽然说，不一定会对性能产生决定性的作用。比如运行30分钟的spark作业，可能做了广播变量以后，
速度快了2分钟，或者5分钟。但是一点一滴的调优，积少成多。最后还是会有效果的。
没有经过任何调优手段的spark作业，16个小时；三板斧下来，就可以到5个小时；
然后非常重要的一个调优，影响特别大，shuffle调优，2~3个小时；应用了10个以上的性能调优的技术点
，JVM+广播，30分钟。16小时~30分钟。
那最后我们做一下，怎么做？就是把dateHourExtractMap做成广播变量Broadcast