Apache spark 是否可以仅使用RDD在高度倾斜的数据上胜过Catalyst优化器

我正在阅读《高性能Spark》，作者介绍了一种技术，该技术可用于对高度倾斜的数据执行连接，方法是有选择地过滤数据，用包含最常见键的数据构建哈希映射。然后将该HashMap发送到所有分区以执行广播连接。结果数据在最后用union操作连接起来

事先表示歉意，但本文没有给出使用代码的这种技术的示例，因此我无法共享代码片段来说明它

案文如下

有时，并非所有较小的RDD都能放入内存，但一些密钥在大型数据集中的比例过高，以至于您只想广播最常见的密钥。如果一个键太大以至于不能放在一个分区上，这一点尤其有用。在这种情况下，您可以在大型RDD上使用CountByKeyAppro，大致了解哪些键最能从广播中获益。然后，只为这些键过滤较小的RDD，并在HashMap中本地收集结果。使用sc.broadcast，您可以广播HashMap，以便每个工作进程只有一个副本，并手动对HashMap执行联接。使用相同的HashMap，您可以过滤大RDD，使其不包含大量重复键，并执行标准联接，将其与手动联接的结果结合起来。这种方法非常复杂，但可能允许您处理以其他方式无法处理的高度倾斜的数据

对于那些不知道的人来说，广播连接是一种技术，用户可以通过将较小的数据块发送给每个执行者来避免连接两个数据块时产生的混乱。然后，每个执行器自己执行联接。其想法是，洗牌非常昂贵，让每个执行者执行连接，然后丢弃它不需要的数据有时是最好的方法

本文描述了一种情况，其中可以使用广播连接提取和连接数据块的一部分。然后，联接的结果与其余数据合并

之所以有必要这样做，是因为通常可以通过确保由两个块中的相同键组成的数据都存在于同一分区中，从而由同一个执行器来处理，从而避免过多的洗牌。但是，在某些情况下，单个键太大，无法放在单个分区上。在这种情况下，作者建议将过度呈现的密钥分离成HashMap，并仅对过度呈现的密钥执行广播连接可能是一个好主意

这是个好主意吗？此外，像这样的技术看起来非常情景化，因此Catalyst可能不使用这种技术。对吗？Catalyst真的没有使用这种技术吗？如果是这样的话，这是否意味着在高度倾斜的数据上，使用RDD的技术可以击败在数据帧或数据集上运行的Catalyst