Spark 的 Http Broadcast 和 Torrent Broadcast 广播实现类的对比
在 Apache Spark 中，广播机制用于高效地将小型只读数据分发到集群中的各个执行器（Executor）。Spark 中主要有两种不同的广播实现方式：Http Broadcast 和 Torrent Broadcast。这两种方式的核心目标都是将数据高效地分发给所有工作节点，但它们在实现方式、效率和性能方面存在显著差异。以下是对这两种机制的详细对比：
1. 实现机制
- Http Broadcast：
- Http Broadcast 是早期的广播机制，Spark 会在驱动节点上启动一个内嵌的 HTTP 服务器，并将广播的数据上传到该服务器。
- 每个执行器在需要广播数据时，会通过 HTTP 请求从驱动程序的 HTTP 服务器下载数据。
- 驱动程序充当单一数据源，所有执行器从该源获取广播数据。
- Torrent Broadcast：
- Torrent Broadcast 是 Spark 1.5 版本引入的默认广播机制，采用类似 BitTorrent 的分布式数据传输方式。
- 驱动程序首先将广播数据分片成多个小块（chunks），这些块会首先发送给部分执行器。
- 执行器在接收到数据块后，会同时处理这些数据块，并像种子一样，将数据块进一步分发给其他执行器。这种方式形成链式的广播，提高了并发性。
- 每个执行器不仅仅从驱动获取数据，也可以从其他已经持有数据的执行器获取数据。
2. 效率与扩展性
-
Http Broadcast：
- 效率较低：由于每个执行器都必须从驱动节点的 HTTP 服务器下载广播数据，当集群规模较大时，驱动程序会成为瓶颈，导致广播的效率下降。驱动程序的带宽和计算资源都会受到限制，不能充分利用集群的带宽资源。
- 可扩展性差：在大规模集群中，多个执行器同时从驱动程序下载数据时会产生高负载，驱动程序可能会因为过多的网络请求而过载。这种集中式的广播方式难以扩展到大型集群。
-
Torrent Broadcast：
- 高效并发传输：Torrent Broadcast 通过将数据分块，并在多个节点之间形成链式传播，显著提高了广播数据的并发传输效率。每个执行器不必都从驱动程序获取数据，可以从其他执行器获取数据块，从而减轻了驱动节点的负载。
- 可扩展性强：由于数据传输是分布式的，不依赖于单一的驱动程序，Torrent Broadcast 在大规模集群中能够充分利用网络带宽资源，具备更好的扩展性。
3. 网络负载
- Http Broadcast：
- 集中式负载：驱动程序承载了所有广播数据的下载请求，因此网络负载集中在驱动节点。网络传输压力集中在驱动程序与各执行器之间的网络链路，容易形成传输瓶颈。
- Torrent Broadcast：
- 分布式负载：数据块通过多个节点以链式方式传播，网络负载分散在各个执行器之间。每个执行器既是数据的消费者也是数据的传播者，网络负载能够均匀分配，避免了集中式的网络瓶颈。
4. 容错性
- Http Broadcast：
- 容错性低：如果驱动程序的 HTTP 服务器出现故障，所有广播数据的分发都将受到影响。此时，广播任务可能会失败，甚至导致作业无法完成。
- Torrent Broadcast：
- 容错性强：由于 Torrent Broadcast 采用分布式传播方式，即使部分节点出现故障，其他节点仍可以继续传播数据。Spark 可以通过重试从其他节点获取数据块，从而具备更强的容错能力。
5. 驱动程序的负担
- Http Broadcast：
- 驱动程序压力大：由于所有执行器都从驱动节点的 HTTP 服务器下载广播数据，随着集群规模的增长，驱动程序承受的负载会显著增加。
- Torrent Broadcast：
- 驱动程序压力小：驱动程序只需要向一部分执行器发送数据块，之后这些执行器会承担起数据的传播工作。驱动节点的负载大大减轻，尤其是在大规模集群中表现尤为明显。
6. 使用场景
- Http Broadcast：
- 适用于较小规模的集群和广播数据量较小的场景。在这些场景中，驱动程序的负载不会太重，且广播效率能够满足要求。
- Torrent Broadcast：
- 适用于大规模集群和需要频繁广播大量数据的场景。Torrent Broadcast 能更好地利用集群的网络资源，减轻驱动节点的压力，提升整体广播效率。
7. 默认设置
-
Http Broadcast：在 Spark 1.5 版本之前，Spark 默认使用 Http Broadcast 作为广播机制。
-
Torrent Broadcast：自 Spark 1.5 起，Torrent Broadcast 成为默认的广播机制。该机制在大规模分布式计算环境中的性能要远远优于 Http Broadcast。
8. 性能对比
- Http Broadcast：
- 延迟较高：由于所有执行器都从同一源获取数据，当执行器数量较多时，网络拥塞和等待时间会显著增加。
- Torrent Broadcast：
- 延迟较低：通过分块并行传输，多个执行器可以同时接收不同的数据块，并相互之间传递数据，传输效率大大提升，延迟减少。
总结对比表
| 特性 | Http Broadcast | Torrent Broadcast |
|---|---|---|
| 实现方式 | 中央化的 HTTP 服务器传输 | 分布式数据块传输，链式传播 |
| 效率 | 随着集群规模增大，效率迅速下降 | 高效并发，适合大规模集群 |
| 可扩展性 | 可扩展性差 | 可扩展性强，适合大型集群 |
| 网络负载 | 网络负载集中在驱动节点 | 网络负载分散在多个节点之间 |
| 容错性 | 容错性较差，驱动程序故障会导致广播失败 | 容错性强，部分节点故障不会影响整体传播 |
| 驱动程序负担 | 驱动程序负载较高 | 驱动程序负担轻，依赖分布式节点传播 |
| 适用场景 | 小规模集群和小数据集 | 大规模集群和频繁的大数据广播 |
| Spark 默认方式 | Spark 1.5 之前 | Spark 1.5 之后 |
总结
- Http Broadcast 是 Spark 早期采用的广播机制，它简单且适合小规模集群，但随着集群规模的增大，它的效率和可扩展性会显著下降。
- Torrent Broadcast 是更现代的广播机制，通过分块并行传输、分布式传播和链式分发，大大提高了广播数据的传输效率，并且适用于大规模集群的场景。因此，自 Spark 1.5 起，Torrent Broadcast 成为了默认的广播机制。
在大规模分布式计算场景中，Torrent Broadcast 具有明显的性能优势，减少了驱动程序的负载，提升了广播的效率和容错性。