导读 本文将介绍腾讯自研的大数据计算平台——天穹SuperSQL，以及在应对数据湖场景中的复杂多维分析方面的实践。

【资料图】

全文目录：

1.SuperSQL架构

2.自适应计算引擎

3.实时湖仓融合

4.未来展望

分享嘉宾｜程广旭 腾讯 高级工程师

编辑整理｜杨文铸 哈尔滨理工大学

出品社区｜DataFun

01

SuperSQL架构

首先介绍一下腾讯自研的下一代大数据计算平台SuperSQL的技术架构。

1.SuperSQL的整体架构

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

SuperSQL提供了完整的端到端的大数据解决方案，适配公有云、私有云和内网等不同的云场景。通过下图我们可以看到SuperSQL的整个架构主要分为四部分，这四部分互相之间不存在耦合关系，都是独立存在的：

（1）核心引擎层

核心引擎层是SuperSQL的核心所在，是统一计算的入口和智能决策的中心，对外提供了通用的SQL语法并自动适配计算引擎的不同SQL标准，同时汇总来自元数据、历史流水、底层集群状态等不同的信息，通过组合算法实现SQL自身语法的优化、物化视图的自主构建、引擎的智能选择等，从而影响到整个计算的生命周期。

（2）计算层

主要根据每个SQL的特点以及使用场景选择最佳的计算引擎，从而保证了在不同架构下的计算稳定性，其中Remote Shuffle Service则提供了统一的数据Shuffle服务，实现了计算、执行、拓扑的自适应。

（3）资源层

主要整合了云上和云下的资源，能够对所有的资源进行统一管理，从而为计算提供统一的资源池，通过资源的自适应调整、租户间资源弹性调度、集群中资源借调等手段统筹资源的管理，提升整个资源的使用效率。

（4）数据编排层

主要适配了系统的异构存储、透明化的存储差异、解耦计算和存储、自主学习、数据访问模式、自适应缓存（热点数据和元数据），从而加速数据访问的性能，提升集群的稳定性。

2.SuperSQL的目标

（1）SuperSQL整体的目标

（2）计算融合

（3）计算解耦

3.SuperSQL技术沙盘

下图具体展示了SuperSQL 的技术沙盘。

在整个技术沙盘的应用层提供了多种多样的接口来适配业务的不同使用方式；中间层是SuperSQL的核心能力，包括元数据管理、查询的解析和优化（兼容常用引擎的方言等）、智能计算等；最下面一层则是SuperSQL对接的数据源，目前SuperSQL已经对接了超过17种的数据源，从而满足不同的业务诉求。

02

自适应计算引擎

第二部分介绍SuperSQL自适应计算引擎是如何进行选择的。

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

引擎之间或者数据源之间所使用的语法存在一定差异，所以选择引擎的时候需要对SQL进行转化使其能够满足引擎的正确识别并执行。SuperSQL作为计算平台的一个入口能够有效兼容不同语法之间的差异，从而做到对数据语法的自适应，为整个大数据计算平台奠定了基石。

SQL语法的转化过程主要分为两部分：SQL的兼容和SQL的转化。

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

通过长期不断地迭代，从人工选择不同的计算引擎到实现了智能选择。智能选择的主要过程为：SQL通过SuperSQL时，SuperSQL会对SQL进行解析并进入计算引擎的选择过程；目前的引擎选择框架采用了先进的RBO+CBO+HBO的组合进行初步的引擎选择，基于机器学习算法再进一步进行优化（采用这种方式的原因是希望从人工专家经验平稳过渡到基于算法模型的方案）。

引擎选择规则：

03

实时湖仓融合

这部分主要介绍腾讯新一代的实时湖仓融合平台。

1.湖仓一体架构

（1）传统实时湖仓一体架构

从下图可以看出，一般DataSource里的用户数据会通过Flink同步到Iceberg中用于实时读取或批量查询。

该方案优点：增量读取，实时性好；相比MQ更稳定；

该方案缺点：借用外部查询引擎，查询性能一般。

（2）实时湖仓融合架构

常见的数据湖使用场景主要是四种：实时写入离线查询，实时写入实时查询，离线写入离线查询，以及离线写入实时查询。

SuperSQL实时湖仓主要解决了实时写入实时查询的场景。

该方案优点：数据写入实时性更高，接入简单；查询性能更优；

该方案缺点：相比较于Iceberg等湖格式，支持的能力有所欠缺。

整个架构的流程主要是：用户可以将数据导入到MQ中，借助实时数仓能力（目前能力主要依赖于StarRocks开源引擎）进行实时写入并构建不同层级的数据仓库，在StarRocks中主要存储热数据（最近n天的数据），n天之前的数据自动/手动降冷至数据湖中，入湖之后主要借助SuperSQL跨源跨引擎能力来实现湖仓数据的实时查询。

2.数据入仓

（1）实时/离线数据入仓

具体来看，实时/离线数据入仓的整体架构如下图。

实时数据会通过MQ，或导入至Flink再通过Flink写入至实时数仓，然后实时数仓中数据会经过t+1或t+n模式降冷至数据湖。这种方式的问题是数据湖中的数据会有一定时间的延迟，即湖仓数据可能不一致（部分业务会有数据湖数据批量实时查询的诉求，因此我们也有一种实现双写入的方案，即数据通过MQ后，同时写入数据仓库和数据湖中，但双写方案对写入性能会有一定的影响）。

离线数据通过内部离线调度平台的插件，允许用户通过Hive、Iceberg、Hudi中的数据离线同步至数据湖中。同时对湖、仓数据进行分区映射。

（2）离线数据入仓

离线数据的入仓，对于Iceberg数据源我们借助了StarRocks中Routine Load的能力。通过Iceberg数据组织架构图可以看到，数据湖中的数据每进来一批之后会生成一个新的metadata file文件，通过最新的S0或S1文件之间的差异比较确认增量的数据内容有哪些，得到增量数据后通过StarRocks内部FE侧的处理生成不同的task任务，再把这些task任务提交到StarRocks BE端，从而实现离线数据的写入。

（3）实时数据入仓及降冷

对于实时数据入仓和降冷也是借助StarRocks中Routine Load的能力把MQ中的数据写入StarRocks；降冷这部分首先会去支持降冷的操作，用户创建降冷任务，并指定具体表的降冷及降冷至什么位置（例如降冷至Iceberg或Hudi等）。降冷任务创建后就会储存到实时数仓集群中，实时数仓则会定时轮询调度已提交的降冷任务并进行判断哪些分区数据需要降冷、哪些分区数据不需要降冷，假如所有的分区数据都不需要降冷，则进入下一次轮询；假如有分区数据需要降冷则会提交对应的降冷任务至任务队列中，后续再从队列中取出降冷任务并真正执行，从而实现数据降冷。

3.自适应融合查询

降冷后的数据和数据仓库的数据是可以实现融合查询的，这种融合查询是在SuperSQL侧实现的，通过自适应判断哪些数据来自于数据仓库、哪些数据来自于数据湖。

假如SQL查询指令完全命中热数据，则会把该命令下发至实时数仓；假如未完全命中热数据或完全命中冷数据，则会进入自适应选择流程。其中元数据的关联就是冷数据和热数据哪些表是有关联的以及可能产生的分区映射，映射关系的做法是在数据湖的表属性中映射热数据相关信息。

除湖仓一体架构之外，在StarRocks访问Iceberg的性能方面也做了很多优化。以下是主要的优化点：

Iceberg源数据是缓存在磁盘上的，当文件比较多或宽表场景下，读取源数据文件可能会成为性能的瓶颈，所以为了缓解集群访问HDFS带来的IO开销，读取时会自动将源数据cache到Alluxio中。整个写的流程没有太多的变化，读流程中会自动判断Alluxio有没有cache到最新的源数据，假如没有则会在读取到源数据后自动cache到Alluxio中，从而达到性能的提升。

下面是我们基于融合查询新一代湖仓一体平台做的性能测试，通过TPC-H数据集对比了SR内表、使用SR和Presto查询Iceberg的性能对比，结果显示Presto查询相比于StarRocks较低，SR内表查询性能分别是Presto查询和SR直接查询的4-65倍、1-25倍，通过SuperSQL融合查询预期可以带来3倍左右的性能提升。

04

未来展望

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