天穹SuperSQL：腾讯下一代大数据自适应计算引擎｜文末送书

作者 | yikonchen，腾讯大数据计算平台负责人 专家工程师

SuperSQL 是腾讯自研的下一代大数据自适应智能计算平台。通过开放融合的架构，实现一套代码高效解决公有云、私有云、内网的任何大数据计算场景问题。我们通过将异构计算引擎 / 异构存储服务、计算的智能化 / 自动化、SQL 流批一体纳入内部自适应闭环，给用户提供极简统一的大数据计算体验。用户能够从繁杂的底层技术细节中解脱出来，专注于业务逻辑的实现，像使用“数据库”一样使用“大数据”，实现业务逻辑与底层大数据技术的解耦。

SuperSQL 作为腾讯大数据智能计算平台的入口和决策中心，整合不同的大数据系统组件，旨在解决传统大数据架构下的痛点和难点问题，诸如大数据的语言门槛高、大数据引擎多而杂、大数据计算链路长而复杂、资源利用率低、存储异构、数据孤岛等。SuperSQL 以自适应作为串联不同系统的能力抓手，通过自动、智能的方式解决传统大数据架构中的痛点问题：

语法自适应：统一不同的计算入口，自动适配不同的 SQL 语法和标准，降低大数据系统使用门槛

引擎选择自适应：根据 SQL 特点和历史执行信息，实现 SQL 引擎的智能选择与加速，自适应调优计算参数，提升整体计算性能，降低失败率

计算运行时自适应：根据运行时状态和信息反馈，动态调整计算执行拓扑，解决大数据计算执行链路复杂，稳定性低的问题

资源自适应：统一资源管理，屏蔽各类资源的性能差异，使业务能透明地使用资源；通过自适应地弹性扩缩，资源借调，最大化资源使用效率

数据编排自适应：实现不同异构存储场景下的存储加载策略，自适应不同架构下的数据融合计算需求，通过自动数据冷热分层，多级缓存，提升存储访问性能

场景架构自适应：适配多云混合架构，实现最优的跨集群、跨 DC、跨云计算路由，打通数据链路，解决数据孤岛

融合计算平台已在腾讯大数据落地，服务微信、QQ、游戏等关键业务。平台每天承载百万级的计算任务，百 PB 级数据处理，百万级核数资源调度。本文将正式揭开新一代计算平台的面纱，揭秘如何实现大数据平台的自治化、智能化。

1

计算平台整体架构

图 1 自适应智能计算平台整体架构

SuperSQL 提供了完整的端到端的大数据解决方案，适配公有云、私有云、内网不同的场景。整个架构可以分为四层：

核心引擎层、计算层、资源层、数据编排层。?核心引擎层是统一计算入口和智能决策中心。对外提供一套通用 SQL 语法，并自动适配计算引擎的不同 SQL 标准。同时汇总来自元数据、历史流水、底层集群状态等不同信息，通过组合算法做出 SQL 自适应优化、物化视图自主构建、引擎智能选择、计算参数调优等重要决策，从而影响整个计算的生命周期。

计算层会根据不同场景，采用不同的计算引擎，其中 Spark 负责 ETL、报表场景，Presto 负责交互式查询场景，Hermes 负责日志检索、用户画像场景，Doris 负责数据湖查询分析，PowerFL 负责安全数据计算。核心引擎层根据 SQL 特点和使用场景选择最佳的计算引擎。为了保证计算在不同架构下的计算稳定性，Remote Shuffle Service（RSS）提供统一的数据 Shuffle 服务，实现计算执行拓扑自适应。

资源层整合云上和云下资源，把能够把所有资源统一管理起来，对计算提供统一的资源池。通过资源自适应调整、租户间资源弹性调度、集群中资源借调等手段，统筹管理调度资源，提升资源整体利用率。

数据编排层适配不同异构存储，透明化存储差异，解耦计算和存储。自主学习数据访问模式，自适应缓存热点数据和元数据，加速数据访问性能，提升集群稳定性。

2

语法自适应：解耦大数据语法和业务逻辑

SuperSQL 支持对接不同类型的外部计算（执行）引擎，包括 Presto、Livy、Hive、Flink，以及丰富多样的数据源，如 MySQL、PostgreSQL/TBase、Hive、TDW Hive (tHive)、SparkSQL/Livy、Oracle、Phoenix (HBase)、ElasticSearch、Kylin、ClickHouse、Hermes、Druid、H2、Presto。引擎之间、数据源之间所使用的 SQL 语法存在一定的差异，SuperSQL 作为计算平台的入口能够有效屏蔽语法差异做到语法自适应，从而为整合不同的大数据系统组件提供基石。提供一套通用 SQL 语法，并通过SQL 兼容转换功能来实现不同 SQL 语法之间的转换；做到在用户无需更改 SQL 语法的前提下实现底层执行引擎的切换，通过一套 SQL 语法，自动适配不同计算引擎和数据源语法。

顾名思义，SQL 兼容转换功能整体可以划分为两个模块，即SQL 兼容与SQL 转换。

1.SQL 兼容：在进行 SQL 兼容时，为解决部分大数据平台语法与业务强耦合、定制化严重，以及不同语法强行融合易导致歧义的问题，SuperSQL 遵循干净、可扩展、可替换、多场景兼容的兼容准则，提供插件式的解析模块，将 SQL 语法模板化，分类管理，形成可扩展、多样的 SQL 生态。SuperSQL 将 SQL 语法分为两大类即通用型（如 SQL 标准语法，以及常见的 Spark、Hive、Flink 等大数据查询语法）、独特型（自定义语法，不具有普适性），基于分类语法模板、语义扩展定义、配置文件生成多样的 SQL 解析器，并且支持动态切换解析器，灵活性强。任意解析器得到的语法树均将转换为 SuperSQL 统一的逻辑计划，SuperSQL 可基于此逻辑计划生成符合不同引擎或数据源方言语法的执行语句（这一过程即 SQL 转换）。SuperSQL 默认使用通用 Parser，其基于 SQL 标准语法，支持大部分通用大数据语法（如 Spark、Hive 语法），适用于大部分的大数据系统组件。而对于一些与业务逻辑强耦合的自定义语法，支持自定义 SQL 模板，生成自定义解析器，通过这种做法，结合上文提及的生成 SuperSQL 统一执行计划以及下文提及的 SQL 转换，可以灵活地将业务任务切换到指定引擎。

2.SQL 转换：SQL 转换发生在两个阶段，一阶段是通过解析器得到抽象语法树后，进行语法树重写以确保该语法树能转换为 SuperSQL 统一逻辑计划；另一阶段是基于 SuperSQL 统一逻辑计划与不同引擎或者数据源语法之间的等价映射关系，能够将 SuperSQL 逻辑计划转换为不同的引擎或数据源语法，做到执行引擎的无感切换，也为下文的智能引擎选择功能奠定基石。

这种执行引擎的无感切换，不光能让 SuperSQL 平滑进行智能引擎选择，充分发挥引擎的优势特点，增加 SQL 执行效率；还能支持业务无感迁移，做到在用户无需更改 SQL 语法的前提下实现底层执行引擎的切换，并且尽量最小程度地更改用户的使用习惯。

通过 SQL 兼容和 SQL 转换，SuperSQL 能够统一计算入口，整合大数据平台组件，降低大数据系统使用的门槛和繁琐程度。

3

引擎选择自适应：智能选择引擎，加速 SQL 计算

智能引擎选择是自适应智能计算的核心功能之一，作为决策中心，SuperSQL 通过组合算法，自动为每条用户 SQL，挑选合适的不同类型的计算引擎（如 Presto、Spark 等）来执行，以提升用户体验（如响应时间快、可靠性高等）和资源利用率（CPU、内存等）。传统基于 RBO/CBO 的 SQL 优化框架，存在规则人工定制、统计信息缺失、历史流水闲置、失效资源浪费等几个主要问题。针对这些问题，SuperSQL 设计实现了基于历史负载的查询优化（History-Based Optimization，HBO）和基于机器学习的引擎选择。HBO 目标是分析处理历史用户 SQL 流水，以通用、抽象化的 HBO 策略，增强补充（非取代）已有的具体化 RBO/CBO 策略。机器学习算法可以自动学习 SQL 特征，更好地弥补人为规则的黑角。把 HBO 和机器学习结合起来，可以更好地降低日均提效失败（即错误选择引擎后执行失败）的 SQL 数，提升用户 SQL 的平均执行时间，减少引擎集群无效负载的同时节省宝贵的计算资源。

HBO 框架的设计实现包括四个子模块，如下图中标示；它们也代表了一条用户 SQL HBO 优化的四个串行阶段。基于引擎选择（SQL 优化）的实时性要求，整个 HBO 耗时必须控制在毫秒级。

1. 查询签名：SuperSQL 执行的所有计算类 SQL 语句（DQL/DML），无论执行结束后状态是成功还是失败，流水入库时都新增生成查询签名（Query Signature，QS）字段。

查询签名是 SuperSQL 自研设计的 SQL 文本的 “浓缩” 表示，包含 SQL 访问库表名和关键子句（Filter/Join/GroupBy/Orderby）中包含的列名。SuperSQL 通过 QS 来匹配判断当前用户 SQL 与哪些历史 SQL “HBO 等价”，然后通过分析汇总这些历史等价 SQL 的执行特征，来决定当前 SQL 是否应选某类引擎执行。

2. 索引宽表：HBO 要求为每个最新提交的用户 SQL，从历史流水库中查找其最近一段时间内等价的历史 SQL 集。SuperSQL 依赖外部的统一元数据服务，固化缓存 HBO 索引宽表来解决检索的实时性能问题。宽表的每一条记录对应一条历史 SuperSQL 查询，包括查询签名、执行时间、引擎类型、结果状态、数据量、引擎 shuffle 数据等信息。

3. 历史检索：基于查询签名的完全匹配（exact match），调用统一元数据服务的 REST API，返回最近历史区间（如一周）内的索引宽表记录集。SuperSQL 通过不同的 API 入参，指定返回记录集的最大行数、起止日期、超时时间等属性，确保检索的实时性能（平均

4. 提效判定：分析统计获取的历史记录集，综合执行时间、失败率、引擎分布等数据，对比系统阈值参数，决定是否对当前 SQL 选择使用的某类计算引擎来执行。

作为业务效果样例，根据对接 SuperSQL 的某数据分析中台的 SQL 流水统计，HBO 加持的 SuperSQL 智能引擎选择，可以大幅减少因为引擎选择错误导致的 SQL failover。HBO 规避的 SQL 类别大都是超大资源占用、海量分区读写、大规模 Join 等高计算开销类，日均可减少 Presto 引擎34TB的无效内存占用以及33 小时的无效 CPU 时间。引擎选择失败规避率（规避率 = HBO 规避 SQL 数 / 提效失败 SQL 总数）在按月稳步提升，到 7 月已达到70%左右。

HBO 不能覆盖所有的 SQL 场景，对于周期性任务较为有效，但如果用户提交了新的查询，签名和历史不匹配，则难以决策。机器学习可以自动学习 SQL 特征，很好地弥补规则的缺失。实践中，直接把 SQL 字符串作为原始数据，具体训练过程如下：

特征处理：使用自然语言处理中的 n-gram TF-IDF 方法，将文本转化为数值特征，供机器学习模型训练。具体做法为，将 SQL 语句按字符（或单词，字符效果更好）进行分割，相邻的 1-5 个字符构成一个元组，选取训练数据中出现频率最高的 50 万个元组，计算全部训练数据中对应元组的词频 - 逆文档词频（TF-IDF）值，从而将每个 SQL 语句转化为 50 万维的特征向量。

特征选择。由于特征维度大，训练数据多，模型训练慢，因此对特征进行降维。使用基于模型的降维方法，先利用逻辑回归（LR）模型在数据上执行训练，之后逻辑回归模型会根据模型系数对特征给出重要性分析，选择最重要的 1 万维特征，供后续模型执行训练

模型训练。采用梯度提升树 XGBoost 拟合训练数据，数据特征为如上所述的 1 万维特征。由于数据类别分布不均（失衡），通过调节模型的类别权重参数，达到最优的拟合效果机器学习可以进一步提升引擎选择的准确性，降低 SQL failover 率。基于内网的 SQL 流水测试，机器学习算法能够在 HBO 的基础上，SQL failover 率降低60%。

4

计算运行时自适应：实时捕捉环境变化，动态调整计算拓扑

传统的大数据架构下，整个计算链路通常是单向的，上层计算缺少底层状态（比如资源状态）的反馈。单向链路虽然简单，但会造成计算资源不均衡、资源利用不充分等问题。算力感知是自适应计算架构里底层反馈的桥梁，让上层计算具备感知资源状态的能力，进而自适应地调整资源使用。通过算力感知，可以获取计算资源整体的资源状态以及单节点详细的算力指标，上层计算借此自适应地动态调整计算决策、资源使用、任务调度等。

以 Presto 为例，作为一款典型的 MPP 架构、纯内存计算的交互式查询引擎，为了追求性能的最大化，Presto 会尽可能地利用节点上可用的资源，包括 CPU/ 内存 / 网络带宽等，节点间的物理资源规格也需要尽可能保持一致。然而在实际的使用场景中，节点的 CPU/ 内存等负载（算力）是随时波动的，而 Presto 的原生任务调度策略并未将节点的算力考虑在内，导致在节点算力明显下降的情况下，计算任务会受到严重的影响，从而产生长尾问题。为此，天穹 Presto 做了针对性的优化，在动态的计算环境中，通过感知节点算力的变化，自适应地调整计算任务的调度，避免低算力节点的影响。

天穹 Presto 自适应任务调度主要分为：Task 自适应调度与 Split 自适应调度，方案实现的核心思想是：根据节点的算力情况动态分配 Split 和 Task，整体架构如下图所示：

天穹 Presto Coordinator 在运行过程中，会实时感知 Worker 节点的算力变化情况，同时计算出对应的节点可用算力权重，在 Task 和 Split 的调度过程中，针对不同的算力权重，根据模型计算出相应的 Worker 上还可分配的 Task 或 Split 数目，对于算力严重下降的节点，少分配或不分配 Task 或 Split，尽量避免长尾问题，从而做到自适应的调度。

自适应调度效果：当计算 Task 在 CPU 波动比较大的节点上，会造成明显的计算长尾的问题大数据计算框架，拖慢整个任务的运行，如下图所示，在没有开始自适应调度的情况下，Task 的执行时间波动很大。

在开启自适应调度后，Task 会避免调度到 CPU 算力差的节点，有效地消除长尾问题。如下图所示，Task 的执行时间更加均衡，避免长尾问题影响整个计算任务的性能。

5

资源自适应：资源统一池化，透明弹性伸缩

面向大规模集群部署，多集群是运维管理的常规手段。但从资源管理的角度，多集群会带来诸多问题：1. 资源对业务不透明，业务在使用计算资源时，需要人为指定特定集群。人为选择集群的方式不仅麻烦，也会带来集群负载不均衡的问题；2. 由于资源不能统筹管理，资源整体利用率不高。资源自适应的目标是把能够把所有资源统一管理起来，对计算提供统一的资源池，对资源统一调度，打破集群间的隔离问题，实现对资源的公平共享，充分利用空闲资源，提高资源利用率，同时对业务透明化。

资源自适应主要包括集群间弹性伸缩和集群内资源调度。每个租户对应一个虚拟 K8S 集群，每个租户都有最低的资源保障，租户之间能借用资源，也可以借用集群空闲资源。通过自适应调配资源，打破集群间的隔离，充分利用不同业务的潮汐效应，错峰使用资源，提升整体的资源利用率。

6

数据编排自适应：融合异构存储，自动查询加速

在公有云、私有云、内网不同场景中，大数据底层存储是异构的，主要涉及 COS、HDFS、Ceph、Ozone 等。面向异构化的存储，统一融合计算平台构建了一层统一的数据编排层（DOP），位于计算和存储之间，透明化存储差异。通过适配不同的权限和认证体系的统一的存储 Client，解耦计算和存储，避免不同计算引擎和不同存储间的相互适配工作，让计算和存储更加专注。在大数据场景中，每天产生海量的数据，而数据治理往往赶不上数据积累的速度，海量元数据以及小文件会给存储 Master 节点（例如 HDFS NameNode）极大压力，造成性能抖动。数据编排层会自适应缓存存储元数据，以及自动小文件合并，减轻 Master 节点压力，同时在跨 DC 数据访问时，加速元数据访问，提升数据访问速度。

数据编排层会针对不同的场景通过热数据缓存，加速计算性能。在内网的 ad-hoc 场景中，采用 LRU/LRFU 相结合的数据缓存策略，整体计算性能加速比 2.6 倍，而对于 IO 密集的 SQL，加速达 6.2 倍。

7

场景架构自适应：多云混合，架构统一

SuperSQL 适配多云混合架构，支持跨 DC、跨云的联合数据分析，打破数据孤岛，打通跨 DC、跨云的数据访问链路，最大化数据价值。通过完善的数据下推、自研的跨 DC CBO，构建最优的计算路由，实现高效、安全的数据分析。在腾讯内跨 DC 访问场景，数据下推和跨 DC CBO 可以有效地降低跨 DC 高峰时段网络流量约 30%。

8

总结 & 未来规划

未来 SuperSQL 会持续专注在统一融合计算平台中，打造更快、更稳定、更易用的大数据自适应智能计算架构，具体会在以下方向上持续探索潜力：

计算任务自适应优化：根据任务本身的特点和历史相似任务的执行状态，通过自动调整计算参数，提升计算任务的稳定性和资源的使用效率。

计算运行时自适应计算框架：构建灵活的自适应计算运行时框架，让引擎动态调整计算执行拓扑，更好地适配不同的计算场景和复杂的计算环境。

热点查询智能缓存：自动学习业务 SQL 查询的 Pattern，自适应地构造视图物化不同 SQL 的共同查询结果，加速（周期性）SQL 执行性能。

高性能融合分布式计算框架：构建属于腾讯的大数据融合计算框架，成为多种计算模式的解决方案，作为一个真正的原生的可扩展的分布式框架。实现用一套代码自动切换不同的计算引擎，解耦业务和底层大数据引擎的强关联。

9

（编辑：温州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!