Colocate Join ：ClickHouse的一种高性能分布式join查询模型

1. ClickHouse分布式加入

• 广播加入

• 舒弗加盟

• 共置联接

1.1 舒弗加盟

• ClickHouse 普通分布式JOIN查询并未按JOIN KEY去Shuffle数据，而是每个节点全量拉取右表数据跟左表分片进行join计算;

• 如果右表为分布式表，则集群中每个节点会去执行分布式查询，查询会存在一个非常严重的读放大现象。假设集群有N个节点，右表查询会在集群中执行N*N次;

• ClickHouse 的这种join方式和业界MPP的区别：虽然是叫做Shuffle join/redistribute join，但是从根本来说不是真正的redistribute join，存在查询放大问题，也是性能较差的一种查询方式。

1.2 广播加入

• 右表的查询在initiator节点完成后，通过网络发送到其他节点，避免其他节点重复计算，从而避免查询放大问题;

• GLOBAL JOIN 可以看做一个不完整的Broadcast JOIN实现。如果JOIN的右表数据量较大，就会占用大量网络带宽，导致查询性能降低;

• ClickHouse的global join方式和业界MPP的区别：

• ClickHouse会将右表过滤结果汇总到一个节点，然后又发送到所有节点，对单节点内存/磁盘空间占用较大，全量数据发送到所有节点，对网络带宽消耗也较大;

• 而业界MPP数据库每个节点并行的将自己一部分数据广播发到所有节点，之后就可以直接进行下一阶段的本地join动作，多个节点都能并行执行，同时数据也不需要从一个节点发送到所有节点，对网络和单节点磁盘及内存消耗较少。

1.3 共置联接

• 由于数据已经进行了预分区/分布，相同的JOIN KEY对应的数据一定存储在同一个计算节点，join计算过程中不会进行跨节点的数据交换工作，所以无需对右表做分布式查询，也能获得正确结果，并且性能较优。

2. ClickHouse 共置加入

2.1 共置连接原理：

2.2 共置连接性能：

• colocate_join_a_local数据按照2分片（
  id % 2或哈希取模
  ）进行数据分布;

• 相同分布列的字段key的数据会分布到同一个节点;

• 数据通过分布式表colocate_join_a_dis把数据写入分布到各数据节点。

• colocate_join_a_local_rand数据（
  rand（）
  ）随机分布;

• 相同分布列的字段key数据会随机分布到各节点;

• 数据通过分布式表colocate_join_a_dis_rand写入进行分布。

• 结果对比

2.3 共置加入场景约束

• 如果对数据写入时效性要求不太高的场景，可通过分布式表进行生成数据，生成数据简单快捷，性能较慢；

• 如果对数据写入时效性要求较高的场景，可通过应用/中间件写入数据到local表，中间件需要实现入库数据分布算法，入库性能较好。

• 扩缩容完成后，需要将全部数据重写/重分布一遍，缺点：耗时长，占用存储可能暂时会翻倍，一种节省空间的方式是：逐个表进行重分布，每个表数据重分布完成后可删除重分布前的数据，避免占用过多存储。将来的改进/增强：重分布过程中支持可写在线，重分布尽量少或不影响写入查询的在线操作，减少重分布过程中对客户业务的影响。

3. 总结