在学习spark的过程中，笔者了解到spark中对于广播变量采用的是bt机制，于是去膜拜了一下相关的论文，即《Performance and Scalability of Broadcast in Spark》。于是针对这篇论文中提到的四种广播机制做了一些总结。
本文讨论了四种广播机制： Centralized HDFS Broadcast (CHB) ，Chained Streaming Broadcast (CSB), BitTorrent Broadcast (BTB), and SplitStream Broadcast (SSB)
对于广播机制的评价
广播机制应当满足的4点要求：performance， scalability， falut tolerance， topology independence。其中对于第四点topology independence，由于数据并行作业的集群是根据每个作业分配的，所以广播机制必须满足并不依赖于任何一种固定的拓扑结构。由于上述提到的四种广播机制全部满足topology independence，所以对各个广播机制进行比较时，并不比较此方面。
Centralized HDFS Broadcast (CHB)
概述
spark中最初采取的的广播机制CHB是采用中心化的方式，即sender将数据放在hdfs中，然后receiver去取，不难看出对于这样的广播策略，当集群规模相当大时，hdfs便成为了性能瓶颈。
分析
performance：worker每次都去距离自己最近的副本去读取变量，所以性能很好，但是随着集群规模增加，hdfs将成为性能瓶颈
scalability：在到达分界点之前，广播时间随并发读取文件的节点的数量线性增加，到达分界点之后，呈超线性（如下图）
falut tolerance：具有容错性，因为hdfs中存在变量的多个副本
Chained Streaming Broadcast (CSB)
概述
master节点会维护一个源节点优先队列，这个优先队列中的节点要么拥有这个变量的一部分（称之为leechers），要么整个拥有这个变量的副本（称为seeds）。对于一个共享变量，最初有且只有master节点持有变量的副本，于是master节点会先把自己放置于优先队列中。当有slave节点请求变量时，master节点将从优先队列中挑选出一个源节点（最初是自己）对该slave节点做出响应并且将该slave节点添加至优先队列中。于是便形成一个树形结构，树的根是master节点。
当slave接收到广播的变量以后便成为了seed并进行下一次对其他节点进行广播的操作，于是在整个广播的过程中，形成了多个广播树，即一个森林。
master节点会维护一个tracker来控制对同时存在的多个广播变量进行适当的响应。
优先队列中优先顺序的策略
Lowest leecher count first (LLCF)：这个策略主要思想是每次从优先队列中选出为slave节点广播的次数最少的源节点，这个策略的问题在于如果广播树中的某一个节点响应比较慢，那么就会影响整个广播过程的速度
Highest observed speed first (HOSF):这个策略要求每个slave在收到广播变量时发送一个反馈，所以master可以计算出每个源节点响应的速度，响应越快的优先级就越高
分析
performance：CSB在40个节点以内的集群规模性能和CHB差不多，在大于40时与CHB相比要好更高的数量级
scalability：比CHB更高的扩展性
falut tolerance：一个节点出现故障时，广播树中对应的子树节点都会受到影响，所以当一个slave发现源节点关闭连接时，将会再次请求master试图再次与另一个源节点建立连接。而当其他源节点都不包含这个广播变量时，slave将从master持久化到hdfs中的位置进行读取。
BitTorrent Broadcast (BTB)
概述
BitTorrent机制的大致思想是通过BitTorrent会话将广播变量序列化至torrent文件后从seed分发至多个leecher，其中leecher可以动态的加入或离开会话。
具体来说，当一个节点加入BitTorrent的会话中时将强制贡献出一部分上传带宽。存放广播变量的torrent文件会被分成很多个piece，而每个piece又被分为多个block，会话中的leecher可以同时从多个会话中的节点下载block，对于每一个下载得到的block，将采用SHA1 hash验证其完整后才被允许可以进行下一次转发。整个过程同样需要一个tracker来跟踪每一个节点是否拥有整个或者部分文件。
分析
performance：得益于其针对网络的优化，性能表现相当好
scalability：在30个节点时出现激增，如下图所示
falut tolerance：只要tracker存活就不会出现问题，在hdfs中对tracker进行持久化以保证tracker故障时不会造成问题
SplitStream Broadcast (SSB)
概述
将内容分成多个stripe，分别用一棵广播树来广播一个stripe。节点加入的广播树的数量小于等于他们期望收到的stripe数量和他们可以接受的进行转发stripe的数量上限之和。于是，一个节点在某一棵树中是内部节点，而在其他所有包含它的广播树中，它都是叶子结点。（不难理解，一个节点在多个树中接收多个stripe而在一棵树中为多个节点进行转发）。
分析
performance and scalability：从理论上讲，SplitStream对可用上传带宽的利用率很高，并且具有很高的可伸缩性，但是当集群规模增大后，某些块被丢弃/丢失(实际上它们是由于分布式消息传递中的一些同步问题而丢失的)，而SSB不能容忍这样的故障，因为一个丢失的块将导致一个损坏的变量。所以实验证明SSB的伸缩性有限。
falut tolerance：跨越多个树可以增强SplitStream对节点故障的恢复能力。
