SuperSQL：跨数据源、跨DC、跨执行引擎的高性能大数据SQL中间件

导语：SuperSQL是腾讯数据平台部自研的跨数据源、跨数据中心、跨执行引擎的统一大数据SQL分析平台/中间件，支持对接适配多类外部开源SQL执行引擎，如Spark、Hive等。

背景

SuperSQL是一款自研的跨数据源、跨数据中心、跨执行引擎的高性能大数据SQL中间件，满足对位于不同数据中心的不同类型数据源的数据联合分析/即时查询的需求。SuperSQL的目标是成为公司内部统一的SQL分析中间件，实现以下三点的价值：

• 解决业务数据孤岛，最大化数据的使用价值
• 执行引擎最优选择，提升业务使用数据效率
• 优化集群资源使用，解决业务资源使用瓶颈

SuperSQL基于Apache社区Calcite[1]动态数据管理框架构建，并围绕上述目标对Calcite Parser/Planner/MetaStore等组件做了大量的定制、扩展和优化。SuperSql的主要特性包括：

• 跨数据源查询：支持通过JDBC对接MySQL、PostgreSQL、TBase、Hive （ThritServer）、SparkSQL、H2、Oracle、Phoenix (HBase)、ElasticSearch等数据源，且支持对接同一类数据源的不同版本（如Hive 2.3.3与Hive 3.1.1）；
• SQL算子下推：支持常用SQL操作下推数据源执行，具体包括Project、Filter、Aggregate、Join、Sort、Union、Intersect、Except、Limit、Offset、UDF和Nested Query；
• SQL引擎CBO（基于代价优化）：基于Volcano模型，选择最优的查询执行物理计划；
• 跨数据中心CBO：将集群负载、网络带宽等因子纳入代价估算，选择最优的跨数据中心执行计划，拆分子查询到不同DC的多个计算引擎执行；
• 最优计算引擎选择：支持对接多种不同类型的分布式计算引擎 (如Spark, Hive, Flink, Presto)，支持为每个SQL智能挑选最优的执行引擎；
• 标准SQL语法：支持SQL 2003、Oracle12和MySQL5语法。

SuperSQL的主要应用场景包括：

• OLAP数据分析 - 通过SuperSQL对数据分析/挖掘、生成报表等
• 数据即时查询 - 通过SuperSQL对数据采样、小数据交互式查询等
• 数据联邦查询 - 通过SuperSQL联合分析不同数据源（例如Hive、HBase）中的数据
• 割裂的数据版本 - 通过SuperSQL查询不同集群中部署的不同数据源版本中的数据
• 跨数据中心查询 - 通过SuperSQL查询多个数据中心中的数据

性能优势：TPC-DS基准评测

目前我们评估了在1GB和100GB的TPC-DS性能测试基准数据集之上，SuperSQL V0.1版本与社区SparkSQL JDBC基线相比，在Hive和PG数据源上执行99条TPC-DS SQL查询的响应时间。

测试环境

软硬件参数

SuperSQL V0.1版本当前作为组件之一随TBDS套件对外发布。本测试使用的系统版本是TLinux 2.2 64bit Version 2.2 20190320；使用的Hive和PG数据源、Spark计算引擎等SuperSQL系统模块均为套件中自带的其它组件，参数具体如下所示。

测试结果分析

总体情况

上表给出了性能测试的详细结果，其中字段的含义说明如下：

• 重复次数：代表了TPC-DS 99条SQL每条被执行的次数；如果大于1，结果取多次测量的平均值；
• 对比组数：针对SuperSQL和Spark JDBC进行对比，只要有一方能成功执行SQL得到结果，即产生对比；
• 有效对比组数：和对比组数的区别在于，只有SuperSQL和Spark JDBC双方均能拿到测试结果，才产生对比；
• 更快方式：对比SuperSQL和Spark JDBC的99条SQL的平均时间，耗时短的更快；
• 性能提升：Spark JDBC的平均执行时间除以SuperSQL的平均执行时间，表示SuperSQL相比Spark基线查询响应时间降低的倍数；
• 成功组数：能够拿到测试结果的query数目；
• 总时间：有效对比组数的总时间，只有双方都拿到测试结果，才会将这个时间计入；
• 平均时间：有效对比组数的平均时间。

1GB查询时间分析

耗时分布对比

上图展示了在1GB数据规模下，SuperSQL和Spark JDBC针对所有99条TPC-DS SQL（部分SQL带分号拆分为两条串行执行，实际为103条）执行时间的对比情况。通过参数优化等方式解决测试中发现的少量SuperSQL查询执行缓慢问题，目前100%TPC-DS测试用例SQL在SuperSql的执行时间可实现远低于或持平Spark JDBC。测试中，我们认为相差10%以内的响应时间结果数据为等价。

图中横轴代表了SuperSQL某条SQL的查询时间除以对应Spark JDBC该SQL的查询时间，然后按照<50%和50%~100%条目分组，分别代表SuperSQL时间是Spark时间的0.5倍以内和1倍以内。纵轴代表了两个条目每个各自包含的SQL数目。例如，从图中我们可以看到Hive作为数据源时，有45条（占比43.69%）SQL 的SuperSQL查询时间在Spark JDBC的50%以下，PG数据源时这个数目为84条（占比81.55%），Hive+PG时为40条（占比38.83%）。

由于1GB的数据规模实在太小，每条query的执行时间都很短，将时间比值作为性能评价依据存在一定的局限性，因此在100GB的结果分析中中，这种现象将会被更加详细的分析。

平均耗时对比

上图显示了SuperSQL和Spark JDBC在不同数据源下的平均执行时间对比情况。Hive作为数据源时，SuperSQL执行一条TPC-DS SQL的平均时间为11.66s，而Spark JDBC为21.68s，性能上SuperSQL较Spark JDBC提升了约86%；PG作为数据源时，性能提升约60%；Hive + PG跨源时，SuperSQL性能提升约83%。

整体而言，在测试数据集规模比较小1GB时，SuperSQL整体较Spark JDBC可匹配或快不到一倍，但是由于整体平均查询时间仅在十几秒左右，计算耗时的比重较小，SuperSQL的性能提升优势并不是很明显，当数据规模增大时这一情况将会完全改观。

100GB查询时间分析

耗时分布对比

上图展示了在103条TPC-DS查询中，SuperSQL和Spark JDBC查询时间的对比情况。将每条查询的SuperSQL执行时间除以Spark JDBC执行时间，按照20%以下、20%~50%和50%~100% 3个区间段进行区分。横轴代表了不同数据源时上述各分组，纵轴代表的是各分组的数目。从图中我们可以观察到，在Hive单源下，有101条（98.1%）SQL的SuperSQL查询时间只占到Spark JDBC查询时间的20%以下；在100GB Hive+PG的混合源下，有88条（85.4%）SQL的SuperSQL的查询时间只占到Spark JDBC查询时间的20%以下。

需要说明的是，在100GB Hive + PG的组别中，Spark JDBC有46组查询过程中抛出异常，没有返回结果，但是SuperSQL则不会出现类似的情况。针对这种情况，上图的表述为：Spark JDBC的异常组别（无结果）作为时间比值<20%处理，实际上这种处理合乎常理，因为Spark JDBC的异常查询组别显得艰难无比，往往需要40min以上才给出报错，这种反应完全可以当作Spark JDBC的查询时间在40min以上，也有可能更长，而SuperSQL往往在400s以内就能够返回结果，所以上述处理是合理的。这也反映了SuperSQL在相同参数配置的情况下，比Spark JDBC应对复杂query的处理能力整体更加优异，对原SQL的优化和处理是卓有成效的。

平均耗时对比

上图给出了SuperSQL以及Spark JDBC所有查询平均时间的对比。可以看到，在Hive数据源下，SuperSQL执行TPC-DS SQL的平均执行时间仅为1.15min，而Spark JDBC则需要31.27min，SuperSQL较Spark JDBC性能提升了约26倍。在Hive + PG跨源的情况下，SuperSQL执行TPC-DS SQL的平均时间为4.63min，而Spark JDBC需要25.7min，性能提升约4.5倍。相比于1GB数据规模，100GB数据规模时SuperSQL的查询优势更加明显，这也与事实相符：在数据规模更加大时，计算耗时的比重更加大，总体耗时更能反映出查询过程的性能优劣。

有一点需要注意的是，从结果上看居然发现Spark JDBC跨源时的平均查询时间反而比单源更快，事实上，正如上一小节所述，Hive + PG作为跨源数据源时，Spark JDBC有将近一半（46条）query 查询失败，而在计算平均时间时这些组别是无法进行统计的，所以在能够执行的query范围内，Spark JDBC的跨源平均查询时间才比单源快，因此这个只是偶发现象，对整体而言是不准确的结论。正是因为Spark JDBC存在诸多异常组别（无结果），平均时间的对比并不能完全反应SuperSQL的性能优势，若是Spark JDBC有更多的组别不会因为资源限制拿不到结果，预计SuperSQL在数值上的性能提升将会更加可观。

测试结果总结

SuperSQL 性能测试结果汇总如下表所示，SuperSql在海量数据下相比社区基线（Spark JDBC）性能优势明显：

1. TPC-DS 100GB基准测试集，98%的Hive和86%的Hive + PG查询，SuperSQL执行时间不到Spark JDBC时间的20%；
2. TPC-DS 1GB基准测试集, 44%的Hive、82%的PG和39%的Hive + PG查询，SuperSQL执行时间不到Spark JDBC时间的50%。

SuperSQL作为公司自研的跨DC多数据源的数据分析平台，不管是单源还跨源的情况下都比开源Spark JDBC有着极为突出的性能优势，且在应对复杂查询时对资源的要求远比Spark要低，具有更好的鲁棒性。SuperSQL性能测试后续将持续进行并获取新的结果，同时在后续版本中针对性能测试发现的问题持续优化，进一步提升SuperSQL的可用性与稳定性。

未来规划

现在的SuperSQL即将融合现网落地，但仍有很多特性需要完善和改进，之后的主要方向包括：

• 兼容存量业务和数据：兼容各个BG存量的业务和数据，这包括不同的数据版本、不同的业务类型等；
• 高效统计信息采集：统计信息（CBO Stats）是代价估算的基础 ，高效的Stats采集是SQL引擎必不可少的一部分，包括支持基于并发采样与增量更新的采集机制、兼容对接第三方Stats接口或仓库，基于历史查询负载的智能自动采集，等等；
• 基于多代价因子的优化：扩展优化Calcite的VolcanoPlanner CBO模型，支持包括：规则集切分优化、单DC CBO网络代价与字节数估算扩展、多计算引擎的跨DC分布式查询执行、下推并发子查询切分，等等；
• 最优执行引擎的智能选择：不同的SQL可能适合于不同类型的计算引擎（Hive，Spark，Flink，Presto等）来执行，目前路由基于简单的规则和启发性代价，未来要开发一套智能规则，根据每个SQL的特征选择其最适合的引擎来执行。

参考

[1] Calcite: https://calcite.apache.org/