Doris系列（二十四）doris的Join优化之Bucket Shuffle Join

在doris中，默认的join方式主要是两种，一种是Broadcast Join，另外一种是Shuffle Join。但是在doris中还支持其他的Join方式，例如：Colocate Join和Bucket Shuffle Join，这些join在执行是优先顺序默认是：Colocate Join -> Bucket Shuffle Join -> Broadcast Join -> Shuffle Join。那么这些join都有哪些特点呢？这篇文章我们来介绍下Bucket Shuffle Join。

Bucket Shuffle Join是doris中提供的一种join方式，它主要是在执行join的sql的时候，提供本地性的优化，减少数据在节点之间的传输耗时来达到查询加速的目的。

举个例子：

有一条sql如下：

select * from a join b where a.id =b.anotherId

这时候在doris进行查询执行的时候，首先会去fe上查询A表的数据分布信息，然后再讲B表的数据发送到对应的A表的数据分布的存储计算节点，这样子就不会把无关的数据发送到a表进行匹配，也不会把b表所有的数据都发送到a表的所有数据节点上进行匹配。进而减小了网络和内存的开销，减少了数据在节点之间的数量量，耗时减少，那么查询数据就会加快。

使用Bucket Shuffle Join的优点有：

首先，Bucket-Shuffle-Join降低了网络与内存开销，使一些Join查询具有了更好的性能。尤其是当FE能够执行左表的分区裁剪与桶裁剪时。
其次，同时与Colocate Join不同，它对于表的数据分布方式并没有侵入性，这对于用户来说是透明的。对于表的数据分布没有强制性的要求，不容易导致数据倾斜的问题。
最后，它可以为Join Reorder提供更多可能的优化空间。

那么我们如何使用Bucket Shuffle Join呢？其实很简单就是在当前的session里面设置下

set enable_bucket_shuffle_join = true;

此时我们在session里面查询数据的时候，他就会根据上面的优先顺序选择使用 Bucket Shuffle Join

select * from a join b where a.id =b.anotherId

备注：

1、Bucket Shuffle Join只生效于Join条件为等值的场景，原因与Colocate Join类似，它们都依赖hash来计算确定的数据分布。
2、在等值Join条件之中包含两张表的分桶列，当左表的分桶列为等值的Join条件时，它有很大概率会被规划为Bucket Shuffle Join。
3、由于不同的数据类型的hash值计算结果不同，所以Bucket Shuffle Join要求左表的分桶列的类型与右表等值join列的类型需要保持一致，否则无法进行对应的规划。
4、Bucket Shuffle Join只作用于Doris原生的OLAP表，对于ODBC，MySQL，ES等外表，当其作为左表时是无法规划生效的。
5、对于分区表，由于每一个分区的数据分布规则可能不同，所以Bucket Shuffle Join只能保证左表为单分区时生效。所以在SQL执行之中，需要尽量使用where条件使分区裁剪的策略能够生效。
6、假如左表为Colocate的表，那么它每个分区的数据分布规则是确定的，Bucket Shuffle Join能在Colocate表上表现更好。