笛卡尔积任务自动查杀

一、集群架构说明

GBase 8a MPP Cluster 采用 MPP + Shared Nothing 的分布式联邦架构，节点间通过TCP/IP 网络进行通信，每个节点采用本地磁盘来存储数据，支持对称部署和非对称部署。

sql下发到管理节点，管理节点将sql进行拆分，形成执行计划，按照执行计划将拆分的sql按步骤发给gnode节点执行，gnode将执行的结果返给管理节点。在sql执行过程中，管理节点和数据节点都有各自的任务号，gnode节点的任务会包含下发任务的管理节点ip和管理节点的任务号，便于从gnode层任务追溯管理节点的任务。

二、临时表生成的时机

在SQL执行过程中，当涉及到多表关联、分组排序、union等复杂场景时，数据库会自动创建临时表，临时表中存储的都是SQL执行的中间结果，当整个SQL执行完毕后，中间结果会被自动清理掉，临时空间也会释放。特别的是在执行多表关联查询时，若关联条件写的不合理，或关联字段重复值较多，就会产生笛卡尔积，占用大量的磁盘空间，从而可能把数据盘写满，导致数据库服务挂掉，而且对集群性能有很大的影响。

三、定位问题SQL

用户通过管理节点访问数据库同时下发SQL,管理节点将SQL解析后分派给对应的数据节点，即SQL最终在数据节点执行。数据节点存储SQL运行过程中产生的临时文件的目录主要有两个，一个是tmpdata，一个是gctmpdb。

（1）tmpdata目录中存放的是缓存数据文件，缓存的是sql执行过程中结果集物化的数据，当中间结果集太大，超出了系统分配给gbased的堆内存上限，内存中的数据会以文件的形式存放到tmpdata目录。缓存的文件及文件名如下图：

上图中标红的部分表示的是SQL在当前数据节点的任务session号，可以通过此session号找到当前数据节点上对应的任务，再通过当前数据节点上的任务可以找到租户通过管理节点下发的具体任务。

上面的方法是先在数据节点找到问题SQL，但是最终问题SQL的查杀需要在管理节点实现。GBase 8a通过多管理节点来实现高可用，但是各个管理节点之间部分信息不共享，如通过管理节点a无法查询到管理节点b正在运行的任务，即各管理节点只能获取到本身的任务信息。所以通过数据节点获取session号后，需要访问所有管理节点来获取管理节点的session号，且在对应的管理节点才能对SQL进行查杀。

2. gctmpdb目录存放的是SQL执行过程中创建的临时表，临时表的名字中包含管理节点的session号，通过此session号，即可在管理节点中找到对应租户下发的具体任务。

  gctmpdb 目录可以理解为运算过程中产生的中间表，其本身就是数据表，可在库里直接用sql查询；tmpdata目录是中间结果集物化的结果，可以理解为内存中存不下的数据落盘，其存在形式是加密文件，不能通过sql查询。

四、自动查杀临时空间占用过大SQL的实现

自动查杀临时空间占用过大的SQL功能采用高可用部署，一主一备，当主节点异常时，备节点会接替主节点的工作，进行临时空间占用过大的SQL的记录和终止，从而释放临时空间，避免因为个别问题SQL造成磁盘被写满，影响业务的情况。

脚本分为三部分，主脚本、节点层脚本和配置文件

1. 主脚本：部署在发起节点，负责调度及收集各数据节点返回的信息

2. 节点层脚本：下发到vc下所有数据节点执行，监控各自节点的临时目录大小（du –sh统计目录大小）

3. 配置文件：设置了查杀阈值、主备节点标识及记录SQL的表信息。

在部署节点设置定时任务，定时采集相关信息，当单一SQL语句占用大量临时空间（单节点超过阈值）时，根据上面提到的sessionid信息找到租户的具体任务，将此任务信息插入到记录表中，便于日后分析统计。

当单一SQL语句产生大量临时空间（单节点超过阈值）且磁盘使用率突破90%这一临界点时，能精准识别当前节点是否存在笛卡尔积操作的SQL语句。在获得租户明确的授权后，运维程序将即刻执行中止操作，迅速释放被占用的临时空间。

通过这一系列精细化、智能化的先进管理措施，我们极大地降低了国产化操作系统数据盘空间耗尽的风险，从根本上杜绝了由此引发的系统不可用及数据库单节点停运等严重问题，显著提升了系统的稳定性与可靠性。