大表join大表_四十三、SparkSQL两种join详解:BroadcastHashJoin,SortMergeJoin

SparkSQL的3种Join实现原理

Join操作是在传统的关系型数据查询中最常用的操作，关系型数据库在设计表时考虑到表的3NF范式设计，为了更好将数据分散在不同的表中以减少数据的冗余与减少更新容错等机制，而建立表之间关系的最好方式就是关联两张表，即所谓的表之间的join操作。

SparkSQL从Shark到SparkSQL，提供了SQL的实现, 完全兼容HQL语法，并且借鉴了关系型数据库的优化器原理，在分布式的环境下对SparkSQL的SQL引擎(catalyst)进行了极大的优化，其中，join作为SparkSQL中的常见操作，自然Spark对它进行了很大的优化。在SparkSQL中，对于join的实现主要有两种：BroadcastHashJoin和SortMergeJoin。BroadcastHashJoin是Spark对BroadcastJoin与Shufle Hash Join进行的优化，下面来分别介绍这三种join的原理:

一、Broadcast Join

这种join方式来源于传统的基于维度的建模(Kinball), 比如说星型或雪花模型，表分为维度表和事实表。维表一般指相对来说比较固定的表，例如产品维表，客户维表等。而事实表是业务表，表的数据会随着业务和时间的增长而不断发生增删改操作，例如产品的销售表，订单表等。

传统关系型数据库中，对于两张表的等值join, 是对两张表中的相同的字段进行连接。在SparkSQL中，对两张表做join最直接的方式是先根据要join的key进行分区，再在每个分区中把key相同的记录拿出来做连接操作，因为是分布式的计算，就会不可避免地涉及到数据的shuffle, 而shufle在Spark中是耗时耗资源(IO与网络带宽)的操作，所以在设计时应避免大量的shuffle操作。

比如，在数据仓库中维表与事实有进行join操作时，为了避免shuffle, 可以将容量较小的维表全部数据分发到每个Executor中，供事实表使用。这就会在一定程度上牺牲了一定的Executor空间来换取shuffle可能带来的耗时操作，这就是SparkSQL中的Broadcast Join, 其主要原理如下图所示：

Broadcast Join

Broadcast Join需要满足以下几个条件

• 被广播的表需要小于spark.sql.autoBroadcastJoinThreshold所配置的值，默认是10M。或者在SQL语句中加入broadcast joinr的hint。
• 基表不能被广播出去，比如A表leftOuterJoin表B时，只能广播右边的表B;

Broadcast Join适用的场景及缺点

• Broadcast Join只能广播较小的表，否则数据的冗余传输就远大于shuffle的开销；
• 只适合广播较小的表，需要将被广播的表collect到Driver端，会对Driver端与网络造成一定的开销；