揭秘TDSQL-A分布式执行框架：解放OLAP关联分析查询性能瓶颈

在“国产数据库硬核技术沙龙-TDSQL-A技术揭秘”系列分享中，5位腾讯云技术大咖分别从整体技术架构、列式存储及相关执行优化、集群数据交互总线、分布式执行框架设计及优化策略、以及向量化执行引擎等多方面对TDSQL-A进行了深入解读。

本期带来了系列分享中腾讯云数据库高级工程师张倩老师主题为“TDSQL-A分布式执行框架设计及优化策略”的分享的文字版。

作为领先的分析型数据库，TDSQL-A是腾讯首款分布式分析型数据库，采用全并行无共享架构，具有自研列式存储引擎，支持行列混合存储，适应于海量OLAP关联分析查询场景。它能够支持2000台物理服务器以上的集群规模，存储容量能达到单数据库实例百P级。

一、执行框架总体设计

1.1 TDSQL-A架构

首先介绍TDSQL-A的总体架构，包括上层的协调节点CN、GTM事务管理器、中间的数据交互总线FN、以及下方的数据节点DN。主要介绍的是协调节点CN和数据节点DN的相关内容，包括用户的查询怎么在CN和DN上执行、最后如何返回结果给用户等问题。

TDSQL-A采用MPP架构，其特性是share-nothing，数据分散在多个DN上，按照不同的分布键分布，并且不同的表可以自定义不同的分布键。如果CN收到了一条查询，它会将这个任务分散到多个DN上并行执行，从而提高执行效率，最后CN获得DN并行执行的最后结果，汇总之后再返回给客户端。

1.2原分布式执行框架

这里先说明一下我们的原分布式执行框架一个最主要的问题。下图是一个简单的Join查询，如果Join查询正好是在这个表的分布键上进行Join，则不涉及数据的重分布，可以直接在每个DN节点上进行Join，DN的结果汇总起来就是最终的查询结果，这是最理想的情况。

但客户的查询往往比较复杂多样，Join经常会涉及不同节点之间的数据交换，Join的两个表的Join键不一定是一个表的分布键，这种情况下就会涉及到数据的重分布。在TDSQL-A中，数据重分布是由Remote Subplan算子来执行。在执行的时候，Remote Subplan算子会并行地创建对应下层的执行进程和对应的DN连接，每个DN都会创建对应其他DN的各个链接，这就会导致链接数和进程数急剧膨胀，给服务器造成很大的压力。

1.3 TDSQL-A分布式执行框架

针对原分布式架构的缺点，我们设计了一套全新的分布式执行框架。在这种执行框架下，查询执行前CN会对查询计划进行分片，并创建DN上的各个执行进程，每个DN的进程间不需要再建立冗余的进程及连接。这可以减少不必要的进程和连接，减轻服务器的负担，并且能够做到比较好的线性扩展性。数据交互则是通过中间的router——FN节点来进行数据交换，这是当前TDSQL-A的分布式执行框架。

二、查询计划分片策略