doris中的join查询优化要点之Runtime Filter Join 优化

在使用传统sql或者大数据的时候，当我们执行sql语句的时候，一般经常会听到：小结果join大结果，小表join大表。但其实说的最准确的应该是小结果join大结果。这样做的好处主要是减小内存数据的占用，同时减小分布式数据库中的各个节点之间的数据shuffle。但是我们在大数据仓库的构建过程中，我们有时候可能会遇到大表join小表的情况，那这个时候按照我们传统的理解，各节点机器之间的内存量就会飙升，同时各节点之间进行shuffle传输会非常大，最后可能导致sql运行的超时失败或者内存崩溃等，当然最终的耗时也会增长很多。那么在doris中这种问题是如何解决的呢？

doris中的解决方案就是runtime filter join。由于doris在进行join查询的时候，会自动在右表生成一张临时hash表进行数据过滤，那么使用runtime filter join的方式其实就是把这张临时的hash表再带到左表里面来，通过提前把左表的数据按照hash进行过滤一遍，进而减少左表的扫描行数来进行左右表的匹配。进而提升join的速度，减小内存暂用和shuffle。

当然，使用runtime filter join也是有条件的，如下：

第一个要求就是左表大右表小，因为构建 Runtime Filter是需要承担计算成本的，包括一些内存的开销。
第二个要求就是左右表 Join 出来的结果很少，说明这个 Join 可以过滤掉左表的绝大部分数据。

Runtime Filter join支持的类型有：

IN 的优点就是效果过滤效果明显，且快速。它的缺点首先第一个它只适用于 BroadCast，第二，它右表超过一定数据量的时候就失效了，当前 Doris 目前配置的是1024，即右表如果大于 1024，IN 的 Runtime Filter 就直接失效了。
MinMax 的优点是开销比较小。它的缺点就是对数值列还有比较好的效果，但对于非数值列，基本上就没什么效果。
Bloom Filter 的特点就是通用，适用于各种类型、效果也比较好。缺点就是它的配置比较复杂并且计算较高。