腾讯天穹 SuperSQL：统一大数据自适应计算平台技术解析-世界播资讯

导读 本次分享主要介绍腾讯天穹 SuperSQL 统一大数据自适应计算平台的相关的工作。

主要分为四个部分：

1. 背景：大数据普惠时代的困扰

(资料图片仅供参考)

2. 系统：SuperSQL 自适应计算架构

3. 方案：SuperSQL 核心技术特性

4. 成果：SuperSQL 落地与影响力

分享嘉宾｜薛文伟 博士 腾讯 专家工程师

编辑整理｜朱佳佳 北京航空航天大学

出品社区｜DataFun

01

背景：大数据普惠时代的困扰

本节首先介绍一下大数据普惠时代的业务困扰。

1. 大数据技术蓬勃发展，异构数据源成为“孤岛”

首先，因历史原因，不同业务部署到不同的数据库（如 Hive、MySQL 等）上，异构数据源逐渐成为各公司数据孤岛形成的原因。其次公司内不同的数据中心有不同的集群，会存在不同版本的数据源。因为业务的发展，数据中心会部署很多不同的大数据处理引擎，但每个引擎适用的业务场景和技术特性不一样，这导致只能人工做数据搬迁和查询调优，数据安全和效率都难以保证。另外，不同的大数据引擎语法不一样，这导致切换引擎的成本升高，会造成一定的资源浪费。

2. 大数据平台缺少统一的 SQL 入口和一致的使用体验

大数据平台现在缺少统一的 SQL 标准入口和一致的使用体验。大数据不同的语法繁多复杂且又有不同，如 Presto 语法跟 Spark 和 Hive 语法有较明显的差距。用户希望用最简单的 SQL 实现业务逻辑，写出来的 SQL 缺少优化。不同平台的割裂性使得用户需要成为大数据语言的资深玩家。 不同引擎的切换，迁移代价很大。

3. 大数据计算引擎复杂度高，难以解耦

大数据计算引擎庞大复杂，不同的引擎参数调优繁杂，学习曲线陡峭。不同的引擎适合不同的业务，如 Hive 适用于对可靠性要求比较高但对时间要求不高的应用。Spark 适用于 ETL、报表等场景。Presto 和 impala 适用于秒级和分钟级的交互式查询。StarRocks 提供亚秒级到秒级实时数据处理。数据分析人员需要根据不同的数据结构和数据量以及响应时间挑选不同的引擎，这大大提高了使用大数据的门槛。

4. 大数据平台移植性低，环境系统紧耦合，计算链路长而复杂

大数据平台组件包括调度、权限管理、存储管理及计算引擎等，导致一条 SQL 的计算链路长且复杂。平台用户对底层的细节又不甚了解，用户提交 SQL 后一旦发生问题，很难定位，用户、开发、运维无法洞察执行的全过程，导致运维成本很高，需要一个统一的大数据解决方案来处理这个问题。

--

02

系统：SuperSQL 自适应计算架构

SuperSQL 是腾讯大数据的下一代自适应计算平台。通过开放融合的架构，实现一套代码自适应解决公有云、私有云、内网的任何大数据计算问题。

1. SuperSQL 整体架构与目标

SuperSQL 分为核心层、计算层、资源层，存储层。 核心层 主要包含元数据管理和 SQL 自适应优化器，如 CBO（Cost-Based Optimization 即“基于代价的优化器”）、RBO（Rule-Based Optimization 即“基于规则的优化器”），还有自研的基于历史的 HBO（History-Based Optimization）。 计算层 接入了很多大数据生态里的计算引擎，如 Presto、Spark、StarRocks 等，为了保证计算在不同架构下的稳定性，部署了大型 Shuffle 任务自适应应用。 资源层 整合云上和云下资源，做到了算力感知和弹性资源动态调整、动态隔离。 存储层 通过 DOP 系统提供兼容 HDFS 的统一接口，同时也做存储优化等。

SuperSQL 架构的目的是通过 SuperSQL 中间层快速构建自适应的计算平台。同时尽量复用开源的大数据组件，不强依赖于特定引擎，大部分优化工作都放到 SuperSQL 层做。我们会根据用户 SQL 的特征，以效率最高、响应时间最快和资源使用最少为目标，自动选择最合适的引擎。最后我们持续探索技术先进性，支持访问不同类型/版本的数据源，支持外接多类分布式计算引擎，支持跨集群/地域的 SQL 优化调度。

2. SuperSQL 技术沙盘

SuperSQL 对外提供 JDBC API、SQL 命令行界面、SDK Toolkit、Python 语言客户端及 Restful API 等接口。SuperSQL 还包含元数据管理、SQL 查询解析和校验，对外提供一套通用的符合 ANSI03 标准的 SQL 语法，并通过对应的 SqlDialect 将优化后的 SQL 自动作语法改写适配后，下推各类计算引擎（如 Hive、SparkSQL、Presto）或数据源（如 MySQL、ClickHouse、PostgreSQL 等十多种）执行。SuperSQL 还实现了基于历史负载的查询优化，在安全方面，我们做一些数据脱敏的工作。

--

03

方案：SuperSQL 核心技术特性

1. SQL 兼容：插件式解析模块，支持多引擎

SuperSQL 的目标是提供统一的 SQL 入口，可灵活切换多种执行引擎。但是大数据引擎异构多样，存在语法差异，SuperSQL 在开源 SQL 解析工具 Apache Calcite 的基础上，以 ANSI 2003 语法为基础，制定通用语法规范，但对于不同引擎中的特殊语法，会通过 Parser 插件的形式扩展。通过 SuperSQL 实现透明引擎迁移，将 Hive SQL 迁移到 Presto，可带来 7 到 16 倍的性能提升。

2. 统一联邦计算：复杂 SQL 算子/函数下推

SuperSQL 的第二个特性是复杂 SQL 算子/函数下推，由于部分引擎支持算子下推的能力有限，需要通过 JDBC 拉取大量数据，使得网络和计算引擎负载压力大、资源使用不合理。SuperSQL 层做了统一的复杂 SQL 算子下推，支持常用 SQL 操作下推数据源执行，这样拉取的数据就小了，既利用了数据源引擎的计算能力，又避免了计算引擎负载过重。与传统的 Spark JDBC 相比，在 100G 的数据量下，有两倍的性能提升，数据量越大，计算下推的性能提升越明显。

3. CBO 统计信息：采样与增量

CBO（基于代价的优化）需要预估 SQL 执行计划中每个物理计划的代价，包括 CPU、IO、Network 等，一个物理计划就是其树型结构上所有的算子代价之和，在所有的候选物理计划中，CBO 挑选代价最小的计划作为最优计划执行。在估算 SQL 算子的代价时，就需要预估其输出和处理的行数或字节数。

我们在 SuperSQL 扩展了 CBO 模型，通过采集对应数据源表的统计信息（包括表级和列级）来计算算子的代价。传统大数据引擎 CBO 在计算统计信息时，每次都是整个分区或表采样一遍，如果分区或表很大且数据有更新时，没有办法做到增量更新。 SuperSQL 采用抽样和合并的逻辑实现统计信息的增量更新。 对于直方图，设计了近等高直方图的方案，在确保增量更新代价低的基础上最大程度确保预测精度。

4. 计算引擎自适应：人工到智能的实践

SuperSQL 基于元数据提供统一的数据查询分析入口，提取 SQL 特征如 CBO、HBO 的统计信息，利用一些机器学习模型去预测引擎执行是否成功，从而动态智能地挑选的计算引擎，从而降低提效失败的 SQL 数，日均节省 MPP 计算引擎数十 TB 内存和上百 CPU 核的计算资源。

5. 计算提效 CBO

为了防止“代价”过高的 SQL，例如 Presto 大内存查询导致引擎集群挂掉，SuperSQL 通过估算 SQL 算子的数据量是否超过历史阈值，过滤执行代价过高的 SQL，使用如 Spark 等其他引擎执行。

6. 跨 DC CBO：融入网络带宽因子，估算传输代价

对于跨 DC（数据中心）的场景，由于网络带宽资源有限，将网络带宽纳入 CBO 代价估算，挑选最优引擎执行查询任务，或者拆分子查询到不同 DC 的多个计算引擎执行，从而节省网络资源。

7. HBO：历史负载萃取，失效 SQL

由于 CBO（基于代价的查询优化）和 RBO（基于规则的查询优化）的局限性，不能将 HDFS 隔离、隐式转换、内存分区超限等因素考虑在内，导致仍有日均 2000 多 SQL 任务在 Presto 上执行失败。我们设计了 基于历史负载的查询优化 HBO（History-Based Optimization）方案 ，把与当前 SQL “相似”的历史负载的执行特征（如执行时间、占用内存、Shuffle 信息等）考虑在内，尤其存在一些定时任务，是非常有效的。

8. HBO 技术方案

SuperSQL 在执行 SQL 语句时实时生成 HBO 查询签名，其为 SQL 文本的“浓缩”表示，包含 SQL 访问的库表名和关键子句中包含的列名，通过查询签名来匹配判断当前用户 SQL 与哪些历史 SQL 等价。SuperSQL 获取这个等价历史 SQL 集后，提取汇总它们的执行特征并融合 RBO/CBO 输出，使用统计分析、机器学习等方法决策当前 SQL 是否应选某类引擎执行。HBO 增强补充（非取代）已有的具体化 RBO/CBO 策略。

9. 物化视图：PB 级秒级查询，无感查询加速

物化视图主要用于预先计算并保存表连接或聚合等耗时较多的操作的结果，这样，在执行查询时，就可以避免进行这些耗时的操作，从而快速的得到结果。 SuperSQL 自主构建物化视图，通过内置增量更新规则，自动地更新物化视图的数据，实现大数据下透明加速。

10. 联邦安全计算

关于联邦安全计算工作主要涉及两个方面。一个是 数据脱敏 ，对于用户不能看到的复合结果列数据，首先对结果列进行溯源，并基于不同的脱敏规则（如哈希、数值取整，字符串替换、加密等）统一在 SuperSQL 层数据脱敏，而不需要每个引擎都实现这个脱敏规则。另一个工作是 隐私计算 ，通过在计算引擎上实现的算子，实现中间结果数据的安全计算。

--

04

成果：SuperSQL 落地与影响力

1. 计算引擎自适应

在计算引擎的自适应方面，HBO 目标是分析处理历史用户 SQL 流水，降低提效失败的 SQL 数，经过近一年的迭代优化，已实现从 30% 到 70% 的失败规避率。机器学习算法可以自动学习 SQL 特征，更好地弥补人为规则的黑角。 把 HBO 和机器学习结合起来 ，可以更好地降低日均提效失败的 SQL 数，将规避率提升至 88%，减少引擎集群无效负载的同时节省宝贵的计算资源。

2. 物化视图自适应

在物化视图自适应方面，支持异步构建，自动 SQL 改写透明加速，提供跨多引擎融合的物化视图能力，同时定时增量更新物化视图。 公司内某业务利用物化视图优化天级别 ETL 作业，每天 SQL 耗时从平均 6h 优化到 40min 内，降幅达 89%；内存消耗从 50TB 降低到 3TB，降幅达 94%；CPU 核数消耗从 1.5w 核降到 1k 核。

3. 计算参数自适应

在计算参数自适应方面，将参数设置分为事前和事后两部分 ，在任务执行前，我们基于 HBO 的信息做参数预测。任务执行后，平台大脑定义标准化诊断的框架，提供全流程串联诊断和统一用户界面。根据异常执行信息，自动调整失败 SQL 相关参数并优化计算，已覆盖 OOM、Shuffle、特殊存储格式访问等常见大数据异常问题。

4. 业界平台对比

对比业界平台，SuperSQL 亮点是 能对接各种引擎、提供统一的 SQL 接口，同时支持数据源的动态增删改查，CBO 和 HBO 的执行优化及自适应计算框架及完整的计算下推。未来希望将 SuperSQL 做的越来好，更贴近云上云下的业务痛点。

5. 影响力

在影响力方面，我们参与了一些行业主导标准制定。在社区方面我们培养了两名的 committer 和多名 contributor，累计其实贡献了 70 多个 patch。

--

05

问答环节

Q1：SuperSQL 是否开源计划？

A1：SuperSQL 已经在腾讯内部开源了，外部开源需要对一些代码做整改以满足社区要求，所以还在开展中。

Q2：跨引擎的联邦查询是用 Spark 实现的吗？

A2：目前上线的大部分联邦查询业务都是 Spark 3 实现的，基于 Presto 的联邦正在开展中。

Q3：不同引擎的 SQL 语法是怎么转换的？

A3：SuperSQL 基于 Apache Calcite，以 ANSI 2003 语法为基础提供了一个通用的 SQL 模板。但对于不同引擎中的特殊语法,会通过定制化的 Parser 插件的形式扩展。SuperSQL 收到 SQL 执行任务后，内部会转化成语法树。基于语法树转化成不同引擎的 Dialect 执行。

Q4：各种计算引擎的存储是用什么共享的？

A4：SuperSQL 会根据数据源的一些信息，对于共享的数据，我们有一个这种 DOP 的产品，基本上能对接各种异构存储。对于不共享的数据，通过 JDBC 的方式访问。

Q5：怎么保证相同 SQL 在不同引擎执行结果是相同的？

A5：不同引擎执行结果的正确性是需要整条生态共同支持的，我们的目标是希望更多的工作在 SuperSQL 做完，引擎侧工作尽量少一点。

Q6：不同查询引擎 Hive、MySQL、Starrocks，数据是在所有引擎都存一份吗？

A6：不是的，用户的数据源可以是各种各样的，SuperSQL 是在权限管控的允许下，调用合适的引擎执行，多数据源的 Join 使用 JDBC 连接，同时 SuperSQL 会尽量的做一些算子下推，这样数据源返回的数据量会尽量的少，从而减少引擎侧的压力和带宽。

Q7：HBO 冷启动是怎么解决的？

A7：首先根据 RBO 和 CBO 提效之后一段时间，再使用 HBO 进行提效的。

Q8：您提到使用 Alluxio 对文件系统的兼容，可以具体说一下吗？

A8：Alluxio（DOP）是另外一个负责 DOP 存储团队实现的，它提供一个兼容的接口，底层存储系统是可以插拔的，任何文件存储系统和对象存储系统都可以集成到 Alluxio 中，包括引擎和 SuperSQL 在内的整个系统是腾讯大数据的自适应计算框架的一部分。

Q9：联邦查询是怎么实现的？

A9：SuperSQL 将用户提交的 SQL，变成好几条串行和并行的 SQL 代码段，然后下推到不同引擎执行一下，最后通过总的 SQL 做聚合。

Q10：SuperSQL 有考虑支持 Doris 吗？

A10：因为一些原因，我们内部选择了 Starrocks 而非 Doris，但是理论上 SuperSQL 是可以接入 Doris 等各种引擎的版本及其变种的。

Q11：有计划支持 Flink SQL 吗？

A11：SuperSQL 希望能集成所有的计算引擎，但是因为有一些其他的安排，所以可能要到明年才会开展相关工作。

Q12：做语法转换的时候，不同引擎上的 UDF 是如何转换的？

A12：对于不同引擎定义不一样的函数，SuperSQL 定义这个函数，然后通过 Dialect 改写后推到不同的引擎执行。如果该函数一个引擎有但另一个引擎没有，就需要调动引擎的团队去把这个函数在引擎里面实现。

Q13：数据脱敏是不同的引擎实现不同的 UDF 吗？

A13：数据脱敏是在 SuperSQL 做的，SuperSQL 会调用元数据的接口，知道脱敏的规则是什么，然后生效加密函数到物理计划推给引擎去执行，引擎不需要再考虑脱敏了。但如果加密函数在某个引擎不存在，那就需要该引擎把这个加密函数实现。

Q14：有哪些强依赖于目前技术的业务场景？跟那个统一的大数据平台相比，在跨地域的业务会比较适合吗？

A14：跨地域这块对私有云场景更好一点，因为私有云客户带宽可能低，SuperSQL 把内网、云上之类的都统一在一个自适应平台上。

Q15：Hive 语法转换到 SQL 是否可以不依赖 MetaStore 信息？

A15：语法转换对元数据的依赖不是很大，但校验对元数据是有依赖的。

Q16：有计划商业化输出吗？

A16：对于我们来讲，商业化分三部分，一部分是 我们内网已经有很多业务在用 ，这就是商业化输出；一部分是 私有云 ，其实我们已经和腾讯云在合作了；另一块是 公有云 ，我们也在腾讯云上做底层的整合。

Q17：SuperSQL 产品核心的动机是什么啊？

A17：多因素综合考虑，通过 SuperSQL 整合底层所有的引擎，长期来讲不管是引擎的替换、升级和运维，能够降低维护的成本和易用性。

Q18：SuperSQL 可以把执行计划直接推给 Presto 或者 Spark 吗？还是说需要转化成对应的 SQL？

A18：目前是转化成对应的 SQL，执行计划还在做。

Q19：SuperSQL 只接受用户提交标准 SuperSQL 语法吗？是否兼容 Hive SQL 这类方言？

A19：SuperSQL 基本上是 ANSI 2003 的标准的语法，所以 Hive 语法是支持的。

Q20：SuperSQL 有适配 TBDS 的组件吗？

A20：有，在私有云上适配了好几个版本。

Q21：不同数据源之间的权限是如何同步管理的？

A21：在我们内部的云上，有专门的权限模块把用户的权限统一管理在一起，我们调接口就可以了。还有一块数据源是用户的，SuperSQL 会鉴别到数据源这个级别，但是数据源里面的表是通过用户给的账号和密码自己去管控的。例如有 MySQL 访问权限的人可以通过 JDBC 连接去访问这个表。

Q22：Starrocks 用的是免费版本吗？还是付费的？

A22：Starrocks 目前用的是开源的，我们也有深度定制 Starrocks 代码的，有一些会反馈到社区。

今天的分享就到这里，谢谢大家。

▌2023数据智能创新与实践大会

4大体系，专业解构数据智能 16个主题论坛，覆盖当下热点与趋势 40+演讲，兼具创新与最佳实践 1000+专业观众，内行人的技术盛会

第四届DataFunCon数据智能创新与实践大会将于⏰ 7月21-22日 在北京召开，会议主题为新基建·新征程，聚焦数据智能四大体系： 数据架构 、 数据效能 、 算法创新 、 智能应用 。在这里， 你将 领略到数据智能技术实践最前沿的景观 。

欢迎大家 点击下方链接 获取大会门票～