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

640?wx_fmt=gif

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

背景

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

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

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

  • 跨数据源查询:支持通过JDBC对接MySQL、PostgreSQL、TBase、Hive (ThriftServer)、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系统模块均为套件中自带的其它组件,参数具体如下所示。

640?wx_fmt=png

测试结果分析

总体情况

640?wx_fmt=png

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

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

1GB查询时间分析

耗时分布对比

640?wx_fmt=png

上图展示了在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的结果分析中中,这种现象将会被更加详细的分析。

平均耗时对比

640?wx_fmt=png

上图显示了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查询时间分析

耗时分布对比

640?wx_fmt=png

上图展示了在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的优化和处理是卓有成效的。

平均耗时对比

640?wx_fmt=png

上图给出了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%

640?wx_fmt=png

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/

640?wx_fmt=gif

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
©️2022 CSDN 皮肤主题:大白 设计师:CSDN官方博客 返回首页
评论

打赏作者

腾讯技术工程

你的鼓励将是我创作的最大动力

¥2 ¥4 ¥6 ¥10 ¥20
输入1-500的整数
余额支付 (余额:-- )
扫码支付
扫码支付:¥2
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值