腾讯大数据｜天穹SuperSQL执行核心剖析

“随着大数据技术的蓬勃发展，在大数据平台构建过程中也面临着很多挑战和困扰”

1. 数据孤岛：由于历史原因以及不同数据中心的业务差异性，众多异构数据源形成了数据孤岛，导致大量且繁重的人工数据搬迁。与此同时，由于不同国家的数据安全法限制，很多数据无法搬迁，数据安全和查询效率都难以保证

2. SQL标准不统一：SQL on Hadoop计算引擎百花齐放，但缺少统一的SQL标准，不同引擎的语法方言各不相同。用户需要学习并掌握各个引擎的语法特性，使用门槛陡增

3. 计算引擎强耦合：不同引擎适合的业务特性不同，例如，Spark适用于 ETL、报表等场景。Presto适用于秒级的交互式查询。用户需要根据不同数据量与响应耗时手动挑选不同的计算引擎，随后业务将强耦合且固化在特定引擎之上，不同引擎间的切换代价巨大

4. 计算链路复杂：大数据平台包括调度系统、权限管理、统一元数据、存储管理、计算引擎等组件，导致一条SQL的执行计算链路冗长且复杂。由于没有统一的计算平台，无法洞察执行全过程，导致运维成本高且问题定位困难

为解决以上痛点问题，SuperSQL应运而生。SuperSQL是腾讯自研的统一大数据自适应计算平台，以自适应作为串联，整合了不同的大数据组件。通过开放融合的架构，实现一套系统解决公有云、私有云、内网的大数据痛点问题。

SuperSQL整体架构可分为四层：核心引擎层、计算层、资源层、数据编排层。其中，核心层作为SQL中间件，基于社区开源组件Apache Calcite改造扩展，聚焦SQL转换与查询优化处理，提供计算解耦和计算融合的能力。解耦特定计算引擎，将SQL特性集中在核心层扩展，不对计算引擎进行侵入性修改，不强依赖于单一的引擎特性。融合各类计算引擎，实现跨数据中心、跨集群、跨数据源的计算能力。本文内容将主要围绕核心层进行展开，介绍SuperSQL的核心技术功能。

01 多SQL方言兼容

SuperSQL目标是提供统一的 SQL 入口，可灵活切换多种计算引擎。为兼容不同引擎的SQL方言，SuperSQL在Calcite的基础上，以 ANSI 2003语法为标准，制定通用的语法规范。针对不同引擎的特殊语法，基于Parser解析插件和Dialect方言插件扩展实现。通过SuperSQL可兼容多SQL方言，助力业务实现引擎间的透明与平滑迁移，提升查询性能。

02 多阶段混合优化器

SuperSQL与具体的计算执行解耦，更多专注在最优执行计划生成。Calcite计划树优化Program程序，默认基于单阶段VolcanoPlanner（火山模型）进行CBO优化，初始优化规则达100多条。由于查询优化是一个NP-hard问题，复杂SQL在多项式时间内找到最优解是非常困难的，存在严重的性能瓶颈，经常卡住到分钟级别或者直接无法生成可执行计划。为了解决优化阶段的长耗时问题，SuperSQL设计出多阶段混合优化器，相较于单阶段优化，其效率提升达5倍多。

多阶段混合优化器的优化实现主要包括：

1.动态超时机制：(1). 针对长耗时的优化规则，允许在运行中动态开启/禁用，(2). 加入软/硬超时阀值，若耗时达到软超时阈值，将禁用未执行的长耗时规则；若耗时达到硬超时阈值，则强制终止并选择当前最优的执行计划返回

2.多阶段Planner：基于优化范畴拆分规则集，各规则子集串行执行，显著降低CBO优化的搜索空间。除此之外，多阶段Planner支持CBO和RBO混合优化，针对转换后等价计划树更优的规则子集，直接采用执行效率更高的RBO优化

3.逻辑验证：增加额外检测验证逻辑，检测相互冲突的规则，避免形成"死锁"似的循环规则匹配

03 CBO代价优化

在CBO优化器中，代价模型（Cost Model）和统计信息（Statistics）是两个重要的概念，对优化效果具有显著影响。

由于公司内部存在着大量的跨数据中心、跨数据源的查询场景，因此跨源网络传输对查询性能会产生显著影响。为了更加准确地适配跨源查询的代价估算，SuperSQL新增估算要素：网络传输。基于Converter节点识别出跨源计算，针对跨源算子的代价模型引入网络传输成本。

为提升CBO优化的有效性，SuperSQL进行了一系列改进，包括：优化算子的代价模型，扩展统一元数据组件获取统计信息，采用抽样和合并处理实现统计信息的增量更新，基于近等高直方图的方案优化估算准确率等。

04 复杂计算下推

SuperSQL最优执行计划生成的一个核心点在于：计算下推。在跨源查询中，尽可能将与跨源无关的算子下推到数据源执行，使得计算贴近存储，避免跨源过程中产生的大量网络传输和数据I/O操作。

在跨源查询中，如果算子的物理属性与数据源相关，则该算子将在指定数据源中计算。基于计划树优化的思想，计算下推可等价理解为：尽可能将算子的物理属性转为与数据源相关的物理属性，即EnumerableConvention 转为JdbcConvention。计算下推发生在CBO优化阶段，为实现计算下推，数据源相关的算子代价应该小于数据源无关的算子代价。因此，下推后计划树的CBO代价会更优/更小，以实现计算下推的计划树等价转换。

需要注意的是，由于不同数据源对SQL功能的支持存在差异，下推过程并不是将将所有算子直接无差别地下推到数据源执行。例如，MySQL数据源支持CONCAT_WS函数计算，但ClickHouse数据源不支持，因此不能将CONCAT_WS下推到ClickHouse执行。

为保证计算下推的可执行性，SuperSQL在下推前会进行一系列校验处理，主要包括：语义特征识别、UDF可行性判断、字段类型判断等。目前，SuperSQL已扩展实现60多条下推规则，能够完整地支持常用SQL算子和UDF的下推处理。

05 引擎智能选择

SuperSQL引擎智能选择，旨在实现自适应计算加速，为SQL自动选择“更合适”的计算引擎，提升SQL的执行效率和成功率。然而，如何选择“更合适”的引擎需要从不同维度考虑，主要包括：

1.资源有效性：引擎选择RBO实现，评估计算引擎的资源是否可用。例如，选择Presto引擎的前提是执行应用组已绑定Presto计算资源

2.语义可行性：引擎选择RBO实现，由于不同计算引擎的SQL能力各不相同，必须保证SQL在所选引擎下具备可执行性。例如，Presto不支持Lateral View语句，相关SQL会排除Presto引擎选择

3.算力感知：引擎选择CBO实现，对于算力敏感的计算引擎，例如StarRocks，提前感知集群的负载状态，评估是否有足够的运行资源，避免在执行侧长时间等待

4.计算数据量：引擎选择CBO实现，估算数据扫描量，评估JOIN处理，对于数量量级敏感的MPP引擎，若量级超过阈值，则排除MPP引擎选择

5.执行历史：引擎选择HBO实现，将SQL生成唯一签名并匹配历史执行的资源消耗量和成功率，根据历史执行特征选择更优的计算引擎

SuperSQL在解析阶段，选择并维护最优引擎；在执行阶段，基于最优引擎的连接信息创建连接并下发执行。其中，最优引擎选择可分为四类场景：

1.强制引擎选择：基于Session参数设置，强制指定计算引擎类型

2.MPP引擎选择：由于MPP引擎的执行效率明显优于BSP引擎，因此，SuperSQL系统会优先选择MPP引擎，可选引擎包括：Presto、StarRocks等

3.BSP引擎选择：如果MPP引擎选择匹配失败，则继续BSP引擎选择，可选引擎包括：Spark、Hive等

4.NATIVE引擎选择：对于单一数据源查询，NATIVE引擎的优先级高于BSP引擎。例如，查询单源ClickHouse表，直接基于ClickHouse JDBC的查询效率远高于Spark查询

06 跨源联邦计算

SuperSQL的核心思想是“联邦计算”，将SQL中涉及到不同数据源的子计算部分（子查询SQL），尽可能下推到对应的数据源本地执行，计算引擎完成不同数据源中间结果的联接与合并。

基于Calcite的设计理念，跨源查询等价为不同Convention的混合计算，基于Converter节点可识别出对应的跨源转换标识。因此，SuperSQL扩展Implementor，以实现自定义的跨源处理。目前SuperSQL的跨源实现主要有两种方式：临时视图、动态Catalog。

方式一：临时视图

临时视图是SuperSQL最早实现的跨源方案，当时，Spark还未发布DataSource V2的多数据源处理能力，因此，SuperSQL基于Spark临时视图功能实现跨源查询。

临时视图的实现细节可分为三个步骤：

1.拼装临时视图子句：在解析阶段，识别出跨源节点，并根据对应子树生成相应的临时视图SQL子句。SuperSQL不仅维护各个数据源对应的临时视图子句的列表，也会维护基于临时视图改写后的最终执行SQL

2.引擎注册临时视图：在执行阶段，基于维护的临时视图列表，并发执行Spark临时视图注册

3.执行改写跨源SQL：在执行阶段，确认所有临时视图注册成功后，基于Spark执行最终改写后的跨源SQL

方式二：动态Catalog

Presto 是一款支持多数据源查询的MPP计算引擎，计算时可基于Catalog加载Connector连接，以实现不同数据源的数据访问。腾讯天穹Presto实现了动态Catalog加载功能，允许在单一SQL中指定多个数据源Catalog，以实现跨源计算。

SuperSQL通过SQL改写，实现基于Presto的动态Catalog跨源，在解析阶段，遍历计划树的表节点，自动识别表类型并改写为对应的SQL Catalog前缀，最终将改写后跨源SQL下发到Presto引擎执行。

07 子查询并发优化

SuperSQL与数据源的连接都是通过JDBC构建，针对JDBC直连数据源的查询场景，当子查询获取的数据结果量级较大时，会导致查询耗时过长。为了降低查询延迟，SuperSQL基于CBO信息实现下推子查询并发优化，以提升查询性能。

子查询并发优化的实现流程可分三个步骤：

1.挑选切分列：校验子查询的分区/索引信息和并发切分条件，基于CBO信息选择满足条件的切分列

2.子查询切分：基于SQL切分器和已选切分列对下推子查询进行切分，生成Query碎片集合

3.并发执行与结果合并：通过并发方式触发Query碎片执行，等待执行结束，合并组装所有Query碎片的执行结果

08 融合湖仓一体

融合湖仓一体，旨在将数据湖和数据仓库的优势结合起来，实现更高效和更低成本的查询分析和数据存储。在天穹体系下，SuperSQL基于Data Fabric技术理念，设计出虚拟表方案实现湖仓一体。

虚拟表的本质是虚拟化，通过Schema虚拟化和数据虚拟化实现湖仓一体的融合。基于虚拟表的抽象，可屏蔽底层多样化的实现细节，连接不同的异构组件。SuperSQL基于Schema虚拟化自动优化表类型，基于数据虚拟化自动优化数据存储，进行数据加热降冷操作。具体地，用户可根据使用场景设置虚拟表的表模型，在使用中仅需关注虚拟表即可，而无需关注底层的具体表类型和数据存储等细节。

由于虚拟表关联的实体表具有可变性，为保证查询一致性和用户访问透明性，SuperSQL会在SQL层实现自动的虚拟表改写。根据实体表映射关系和冷热数据分布选择最优的执行计划，目前已支持表级别RBO改写优化和分区级别CBO改写优化。

结合虚拟表，SuperSQL可实现湖仓一体的不同范式落地：

1.湖仓跨源计算：基于虚拟表查询改写和跨源联邦计算实现用户无感知的湖仓跨源计算

2.湖仓数据流动：分析历史执行行为，自动将高频访问的分区数据加热到数据仓库，并优化分层存储；自动将低频访问的分区数据降冷到数据湖

3.数据湖加速查询：基于引擎智能选择自动提效到StarRocks数仓引擎执行

4.湖仓分层建模：用户无需关注特定的湖表和仓表，可通过配置不同表模型，实现虚拟表的统一湖仓分层建模

未来SuperSQL会持续专注在统一融合计算平台，打造更快、更稳定、更易用的大数据自适应智能计算架构，聚焦最优执行计划生成，深耕湖仓一体融合。