云原生数仓如何破解大规模集群的关联查询性能问题

云原生数仓如何破解大规模集群的关联查询性能问题

前言

       近年来，数据库系统服务的数据量呈指数级增长，同时也面临处理的业务需求愈发复杂、实时性要求越来越高等挑战。单机数据库系统已经逐渐不能满足现代的数据库服务要求，因此分布式数据库/数据仓库得到了越来越广泛地运用。

       在实时分析（OLAP）领域，分布式数据仓库可以充分发挥系统的分布式特点，将复杂的OLAP任务分解下发到系统中的所有节点进行计算提升分析性能；分布式数据仓库也可以比较方便地对系统节点进行扩容，应对用户业务数据量增加的需求。但是分布式数据仓库用户无法避免的一个问题是：随着数据仓库集群规模增大，扩容带来的性价比愈发降低。

       造成这种现象的一个原因是，表连接（Join）作为数据库业务中最广泛使用的算子之一，在分布式计算中依赖系统节点间的数据交互；当分布式集群规模增大时，节点之间的数据交互代价会明显增加，这种情况下非常考验分布式系统的网络处理能力，并依赖用户的数据表设计和SQL编写能力以缓解数据交互压力。

针对这个问题，业界不同的分布式数据库系统提出了不同的Join运行时过滤(Runtime Filter)算法。AnalyticDB for PostgreSQL(以下简称ADB PG)是一款PB级的MPP架构云原生数据仓库，同样也面临着上述问题的挑战。本文从ADB PG架构设计的角度出发，探讨Runtime Filter在ADB PG中的实现方案，并介绍了基于Bloom Filter的ADB PG Dynamic Join Filter功能技术细节。

ADB PG架构简介

ADB PG基于开源项目Greenplum构建，在单机PostgreSQL的基础上进行扩展，将多个PG服务同时启动在单个或多个服务器上并组成集群，以分布式的形式提供数据库服务。

ADB PG将每一个PG服务称为一个Segment，并引入了Slice的概念。Slice用于解决分布式系统中的网络结构，当数据库涉及到MPP多阶段计算时，例如Hash Join左右表的Join Key不满足相同的Hash分布，那么就需要对Join Key通过网络传输进行重分布，ADB PG将网络传输的前后阶段切分为不同的Slices。以下是一个ADB PG集群示意图。