第2.9章：StarRocks表设计--Colocation Join

在分布式集群中，每张表的数据都会分散在集群多个节点上，所以当我们进行join时避免不了节点间数据网络传输带来额外的延迟和其他开销。为了加速查询，StarRocks设计了Colocation Join。

在Colocation Join中，StarRocks引入了Colocation Group（CG）和Colocation Group Schema（CGS）的概念，CGS是指CG的分桶键，分桶数以及副本数等信息。Colocation Join实现的核心就是将同一个Colocation Group中的表采用一致的CGS也即使用一致的分桶键（字段数量、顺序及字段类型一致即可，名称不需要一致）、一致的副本数量和一致副本放置方式，进而保证这些Table对应的分桶副本会落在相同一组BE节点上。这样如果join列为分桶键，则计算节点只需做本地join，而无需从其他节点获取数据，进而实现大表join的加速。

在表设计文档中，我们先不细述Colocation Join的原理和实现，仅简单说明一下使用方式。创建表table12：

CREATE TABLE table12(

k1 int,

v1 int sum

)

DISTRIBUTED BY HASH(k1) BUCKETS 8

PROPERTIES(

"colocate_with" = "group1",

"replication_num" = "1"

);

在建表时，我们在PROPERTIES中指定属性"colocate_with" = "group_name"，即表示这个表是一个Colocation Join表，并且归属于一个指定的Colocation Group。

如果指定的Group不存在，则StarRocks会自动创建一个只包含当前这张表的Group。如果Group已存在，则StarRocks会检查当前表是否满足Colocation Group Schema。如果满足，则会创建该表，并将该表加入Group。同时，表会根据已存在的Group中的数据分布规则创建分片和副本。Group归属于一个Database，Group的名字在一个Database内唯一。

为了使得Table能够有相同的数据分布，同一CG内的Table必须保证下列约束：

1、同一CG内的Table的分桶键的类型、数量和顺序完全一致（字段名称可以不一致），并且桶数一致，这样才能保证多张表的数据分片能够一一对应地进行分布控制。

2、同一个CG内所有表的所有分区（Partition）的副本数必须一致。如果不一致，可能出现某一个Tablet的某一个副本，在同一个BE上没有其他的表分片的副本对应。

3、同一个CG内所有表的分区键，分区数量可以不同。

结合上面的约束条件举例，我们创建表table13，将其加入group1中：

CREATE TABLE table13(

uid int,

city varchar(40),

total int sum

)

DISTRIBUTED BY HASH(uid) BUCKETS 8

PROPERTIES(

"colocate_with" = "group1",

"replication_num" = "1"

);

这样当对table12与table13进行关联条件为table12.k1=table13.uid的join时，若Colocation Join生效，理论上查询效率会非常高（此时explain sql，可以发现查询计划中的Hash Join会显示colocate: true）。

我们同样可以通过show语句查看集群内已存在的Group信息：

SHOW PROC '/colocation_group';

对一个已经创建的表，我们也可以增加、修改或删除表的colocate_with属性。例如修改table12的Colocation Group为group2：

ALTER TABLE table12 SET ("colocate_with" = "group2");

如果该表之前没有指定过Group，则该命令检查Schema，并将该表加入到该 Group（Group不存在则会创建）。如果该表之前有指定其他Group，则该命令会先将该表从原有Group中移除，并加入新Group（Group不存在则会创建）。

我们也可以将表的colocate_with属性设置为空，以删除其Colocation Group属性。比如删除table12的colocate_with属性：

ALTER TABLE table12 SET ("colocate_with" = "");

当Group中最后一张表彻底删除后（彻底删除是指从回收站中删除。通常，一张表通过DROP TABLE命令删除后，会在回收站默认停留一天的时间后，再删除），该Group也会被自动删除。

对于Colocation表，我们在使用过程中还需要注意：

当对一个具有Colocation属性的表进行增加分区（ADD PARTITION）、修改副本数时，StarRocks会检查修改是否会违反Colocation Group Schema，如果违反则会拒绝。

Colocation表的副本分布需要遵循Group中指定的分布，所以在副本修复和均衡方面和普通分片有所区别，前面使用show语句查看Group信息时，我们需要关注其中的IsStable属性，当值不为true时，表示当前Group内有部分表的分片正在做修复或迁移，此时，相关表的Colocation Join将退化为普通Join，在explain join sql时提示：colocate: false, reason: group is not stable。

Colocation表的副本均衡受FE参数disable_colocate_balance控制，为保证查询效率，我们可以在查询频繁的时间临时关闭Colocation表的副本修复和副本均衡，在业务空闲时间再开启。

disable_colocate_balance：是否关闭StarRocks的自动Colocation副本均衡。默认为false，即不关闭。该参数只影响Colocation表的副本均衡，不影响普通表。

这个参数都可以动态修改，关闭自动均衡的写法为：

ADMIN SET FRONTEND CONFIG ("disable_colocate_balance" = "true");

恢复自动均衡：

ADMIN SET FRONTEND CONFIG ("disable_colocate_balance" = "false");

如果想对比使用colocation join前后的join性能，也可以从session级别暂时关闭colocation join功能，SQL写法为：

set disable_colocate_join = true;