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

猜你喜欢

转载自blog.csdn.net/qq_16038125/article/details/80362626