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 是 Spark 早期采用的广播机制，它简单且适合小规模集群，但随着集群规模的增大，它的效率和可扩展性会显著下降。
• Torrent Broadcast 是更现代的广播机制，通过分块并行传输、分布式传播和链式分发，大大提高了广播数据的传输效率，并且适用于大规模集群的场景。因此，自 Spark 1.5 起，Torrent Broadcast 成为了默认的广播机制。

        在大规模分布式计算场景中，Torrent Broadcast 具有明显的性能优势，减少了驱动程序的负载，提升了广播的效率和容错性。