Doris总结-Join方式

Doris总结-Join

1.Broadcast Join
2.Shuffle Join
3.Colocation Join
4.Bucket Shuffle Join
5.Runtime Filter
顺序：Colocate Join -> Bucket Shuffle Join ->Broadcast Join -> Shuffle Join

1.Broadcast Join

系统默认实现的一种join方式，类似于hive 的Map join ，将小表加载到内存中，形成一张Hash内存表，然后将Hash表广播到大表所在的各个节点，然后流式读取大表数据进行Hash join。如果小表数据过大，Doris将自动转换为Shuffle join。

2.Shuffle Join

小表数据无法放入内存则进行shuffle join ，将两张表都按照key进行Hash，然后进行join，分布到各个计算节点进行join。

3.Colocation Join

Colocation group：一个CG包含一个或多个表，同一个CG中标的CGS一致，并且数据分片一致。
Colocation group Schema：描述CG的table，包含分桶列类型，分桶数量，副本数量等信息。

主要是提供本地性能优化，减少数据在节点上的传输耗时

将一组拥有 CGS 的表组成一个 CG。保证这些表对应的数据分
片会落在同一个 be 节点上，那么使得两表再进行 join 的时候，可以通过本地数据进行直接
join，减少数据在节点之间的网络传输时间

4.Bucket ShuffleJoin

为join提供本地性能优化，减少数据在节点传输的消耗。
在 FE 之中保存了 Doris 每个表的数据分布信息，如果 join 语句命中了表的数据分布列，
使用数据分布信息来减少 join 语句的网络与内存开销，这就是 Bucket Shuffle Join。
与 Colocate Join 不同，它对于表的数据分布方式并没有侵入性，这对于
用户来说是透明的。对于表的数据分布没有强制性的要求，不容易导致数据倾斜的问题。

5.Runtime Filter

在join的时候动态生成过滤条件，减少数据扫描量，从而加快查询
Runtime Filter是在运行时动态生成的过滤条件，将小表中的数据计算出一个过滤条件，然后将这个过滤条件加到大表中，从而减少大表的数据扫描量。

比如：大表Ajoin小表B，B数据量较小，优先加载完成，此时可以将B表的数据根据ON字段计算出过滤条件，将这个过滤条件应用到A表中，减少A表数据的扫描。