Spark SQL：为什么 Spark 不一直广播

Question

我在 aws s3 和 emr 上使用 Spark 2.4 开展一个项目，我有一个包含两大部分数据的左连接。 spark执行不稳定，经常因为内存问题而失败。

集群有 10 台 m3.2xlarge 类型的机器，每台机器有 16 个 vCore、30 GiB 内存、160 GB SSD 存储。

我有这样的配置：

          "--executor-memory",
          "6512M",
          "--driver-memory",
          "12g",
          "--conf",
          "spark.driver.maxResultSize=4g",
          "--conf",
          "spark.sql.autoBroadcastJoinThreshold=1073741824",

left join 发生在 150GB 的左侧和 30GB 左右的右侧之间，因此有很多 shuffle。我的解决方案是将右侧切到足够小，例如 1G，因此将广播数据而不是随机播放。唯一的问题是在第一次左连接之后，左侧已经有来自右侧的新列，所以下面的左连接将有重复列，如 col1_right_1、col2_right_1、col1_right_2、col2_right_2，我必须重命名 col1_right_1/col1_right_2到 col1_left，col2_right_1/col2_right_2 到 col2_left。

所以我想知道，为什么 Spark 允许随机播放，而不是到处使用广播。广播不应该总是比随机播放快吗？为什么 Spark 不像我说的那样加入，将一侧切成小块并播放？

Answer 1

让我们看看这两个选项。 如果我理解正确您正在为数据帧的每个片段执行广播和连接，其中片段的大小是最大广播阈值。 这里的优点是您基本上只通过网络发送一个数据帧，但您正在执行多个连接。每个要执行的连接都有一个开销。 From:

一旦广播的数据集在执行器机器上可用，它 与另一个数据集的每个分区连接。也就是说，对于 的每一行（在每个分区中）的连接列的值 其他Dataset，从广播中取出对应的行 数据集和连接被执行。

这意味着对于每批广播连接，在每个分区中，您都必须查看整个其他数据集并执行连接。

Sortmerge 或散列连接必须执行 shuffle（如果数据集没有平均分区），但它们的连接效率更高。