spark2.x-广播变量

广播变量允许程序员保持只读变量，在每个机器上缓存，而不是用任务来发送它的副本。它们可以有效的方式给每个节点提供一个大的输入数据集的副本。spark尝试使用高效广播算法来分发广播变量以减少通信成本。注意，对象在广播后不应修改以确保所有节点获得广播变量的相同值


Broadcast 就是将数据从一个节点发送到其他的节点上; 例如 Driver 上有一张表，而 Executor 中的每个并行执行的Task (100万个Task) 都要查询这张表的话，那我们通过 Broadcast 的方式就只需要往每个Executor 把这张表发送一次就行了，Executor 中的每个运行的 Task 查询这张唯一的表，而不是每次执行的时候都从 Driver 中获得这张表！

Broadcast 是分布式的共享数据，默认情况下只要程序在运行 Broadcast 变量就会存在，因为 Broadcast 在底层是通过 BlockManager 管理的，Broadcast 是在创建 SparkContext 时被创建的！你也可以手动指定或者配置具体周期来销毁 Broadcast 变量！Broadcast 一般用于处理共享配置文件，通用的数据子，常用的数据结构等等；但是不适合存放太大的数据在Broadcast。Broadcast 不会内存溢出，因为其数据的保存的 Storage Level 是 MEMORY_AND_DISK 的方式（首先优先放在内存中，如果内存不够才放在磁盘上）虽然如此，我们也不可以放入太大的数据在 Broadcast 中，因为网络 I/O 和可能的单点压力会非常大！
没有广播的情况：通过网络传输把变量发送到每一个 Task 中，会产生4个Number的数据副本，每个副本都会占用一定的内存空间，如果变量比较大，会导致则极易出现OOM。
使用广播的情况：通过Broadcast把变量传输到Executor的内存中，Executor级别共享唯一的一份广播变量，极大的减少网络传输和内存消耗！

假设你 A 节点用了这个数据，A 节点也会作为一个数据来源或者是供应源，这个时候就有两个节点可以供应原数据，然后第三个节点用完之后也变成一个供应源，愈多节点用这副广播数据，会愈多供应源。

val broadcastVar = sc.broadcast(Array(1, 2, 3))
broadcastVar.value

HttpBroadcast(spark2.0+已经废弃）

第一种就是 HttpBroadcast，在 Driver 中创建一个文件夹，搞一个 HttpServer，你需要的话 Executor 通过 Http 抓一份过来，放在 BlockManager 中，下一次再用的话就首先到 BlockManager 取，BlockManager 没有再去 Driver 去取，所以这存在单点故障，和网络IO性能问题。

使用HTTP方式实现的广播机制。第一次HTTP广播变量（作为task的一部分发送）任务在执行器中被反序列化，从Driver中获取广播数据。
（通过在Driver运行的HTTP服务）并存储executor的BlockManager中 加速后续访问

最开始的时候数据放在 Driver 的本地文件系统中，Driver 在本地会创建一个文件夹来存放 Broadcast 中的 data，然后启动 HttpServer 来访问文件夹中的数据，同时写入到BlockManager (Storage Level 是MEMORY_AND_DISK) 中获得 BlockId (BroadcastBlockId) ，当第一次 Executor 中的 Task 要访问 Broadcast 变量的时候，会向 Driver 通过 HttpServer 来访问数据， 然后会在 Executor 中的 Broadcast 中注册该 Broadcast 中的数据，这样后续需要的 Task 访问的 Broadcast 的变量的时候会首先查询BlockManager 中有没有该数据，如果有就直接使用；
BroadcastManager 是用来管理 Broadcast，该实例是在 SparkContext 创建 SparkEnv 的时候创建的。

在实例化 BroadcastManager 的时候调用 initialized 方法，这个方法通过创建 BroadcastFactory 工厂类来构建具体的实际的 Broadcast 类型，默认是情况下是 TorrentBroadcastFactory

HttpBroadcast 存在单点故障，和网络IO性能问题，所以默认使用 TorrentBroadcast 的方式，开始数据在 Driver 中，假设 A 节点用了数据，B 访问的时候 A 节点就变成数据源，依次类推，都是数据源，你数据的节点愈多，你获取数据的选择性就愈多，这样就不是导致一个节点压力太大，也不会导致在特定的节点上网络压力太大，数据源越多，节点压力会大大降低，当然是被 BlockManager 进行管理的。
TorrentBroadcast 按照 Block_Size (默认是 4MB) 讲 Broadcast 中的数据划分为不同的 Block

然后将分块信息也就是 meta 信息存放到 Driver 的 BlockManager 中，同时会告诉 BlockManagerMaster，此时就会变成全局信息说明 Meta 信息存放完毕。

TorrentBroadcast
第二种就是 TorrentBroadcast，首先是 Driver 中有，创建一个文件夹，它是向 BroadcastManagerMaster 注册，然后 Executor 需要的话自己拿一份，拿一份的时候它要通知 BlockManagerMaster 就有另外一份副本，后绩 Executor 要拿副本就有多种选择。

Driver将序列化对象分成小块和将这些块存储在驱动程序的块管理器中。
在每个执行器上，执行器首先尝试从其块管理器中提取对象。如果它不存在，然后使用远程获取从驱动器和/或获取小的块。其他执行器，如果可用。一旦获得了块，它就把块放在自己的块中。块管理器，为其他执行器做好准备。
*这防止了驱动程序发送多个副本的瓶颈。广播数据（每个执行者一个）。