大小是个相对的概念，通常来说，大表与小表尺寸相差 3 倍以上，我们就将其归类为“大表 Join 小表”的计算场景。因此，大表 Join 小表，仅仅意味着参与关联的两张表尺寸悬殊。

对于大表 Join 小表这种场景，我们应该优先考虑 BHJ，它是 Spark 支持的 5 种 Join 策略中执行效率最高的。BHJ 处理大表 Join 小表时的前提条件是，广播变量能够容纳小表的全量数据。

小表数据量超过广播阈值如何处理

小表的数据量超过广播阈值，我们又该怎么办呢？

案例一 维度和维度属性列大

在第一个案例中，大表 100GB、小表 10GB，它们全都远超广播变量阈值（默认 10MB）。因

为小表的尺寸已经超过 8GB，在大于 8GB 的数据集上创建广播变量，Spark 会直接抛出异常，中断任务执行，所以 Spark 是没有办法应用 BHJ 机制的。

在这种情况下，Spark 只好退而求其次，选择 SMJ（Shuffle Sort Merge Join）的实现方式。

SMJ 机制会引入 Shuffle，将上百 GB 的数据在全网分发可不是一个明智的选择。那么，根据“能省则省”的开发原则，我们有没有可能“省去”这里的 Shuffle 呢？要想省去 Shuffle，我们只有一个办法，就是把 SMJ 转化成 BHJ。

因此，可以将关联键做一个哈希操作，把所有的维度熟悉md5一下，然后只拿md5关联做广播。 如果存在哈希碰撞的话，则可以使用2种哈希算法对关联键的结果拼接，这种存在哈希碰撞结果几乎为零。

此文章为4月Day11学习笔记，内容来源于极客时间《gk.link/a/122xw》