首先引见一下腾讯自研的下一代大数据计算平台SuperSQL的技术架构。
SuperSQL是腾讯自研的下一代大数据自顺应计算平台，经过放开融合的架构成功了一套代码，高效处置私有云、私有云、内网的任何大数据计算场景的疑问，将异构计算引擎、异构存储服务、计算引擎的智能化和智能化、SQL的流批一体、算力感知等智能调度归入到外部的系统闭环当中，为用户提供极简的、一致的大数据计算体验，用户能够从复杂的底层技术细节当中脱离进去，专一于业务逻辑的成功，像经常使用数据库一样来经常使用大数据，成功业务逻辑和底层大数据技术的解耦。
SuperSQL提供了完整的端到端的大数据处置方案，适配私有云、私有云和内网等不同的云场景。经过下图咱们可以看到SuperSQL的整个架构关键分为四局部，这四局部相互之间不存在耦合相关，都是独立存在的：
**引擎层是SuperSQL的**所在，是一致计算的入口和智能决策的中心，对外提供了通用的SQL语法并智能适配计算引擎的不同SQL规范，同时汇总来自元数据、历史流水、底层集群形态等不同的消息，经过组合算法成功SQL自身语法的优化、物化视图的自主构建、引擎的智能选用等，从而影响到整个计算的生命周期。
关键依据每个SQL的特点以及经常使用场景选用最佳的计算引擎，从而保障了在不同架构下的计算稳固性，其中Remote Shuffle Service则提供了一致的数据Shuffle服务，成功了计算、口头、拓扑的自顺应。
关键整合了云上和云下的资源，能够对一切的资源启动一致控制，从而为计算提供一致的资源池，经过资源的自顺应调整、租户间资源弹性调度、集群中资源借调等手腕兼顾资源的控制，优化整个资源的经常使用效率。
关键适配了系统的异构存储、透明化的存储差异、解耦计算和存储、自主学习、数据访问形式、自顺应缓存（热点数据和元数据），从而减速数据访问的性能，优化集群的稳固性。
2、SuperSQL的目的
下图详细展现了SuperSQL 的技术沙盘。
在整个技术沙盘的运行层提供了多种多样的接口来适配业务的不同经常使用方式；两边层是SuperSQL的**才干，包含元数据控制、查问的解析和优化（兼容罕用引擎的方言等）、智能计算等；最上方一层则是SuperSQL对接的数据源，目前SuperSQL曾经对接了超越17种的数据源，从而满足不同的业务诉求。
第二局部引见SuperSQL自顺应计算引擎是如何启动选用的。
1、SQL兼容：插件式解析模块，支持多引擎
引擎之间或许数据源之间所经常使用的语法存在必定差异，所以选用引擎的时刻须要对SQL启动转化使其能够满足引擎的正确识别并口头。SuperSQL作为计算平台的一个入口能够有效兼容不同语法之间的差异，从而做到对数据语法的自顺应，为整个大数据计算平台奠定了基石。
SQL语法的转化环节关键分为两局部：SQL的兼容和SQL的转化。
2、计算引擎自顺应：人工到智能的通常
经过常年始终地迭代，从人工选用不同的计算引擎到成功了智能选用。智能选用的关键环节为：SQL经过SuperSQL时，SuperSQL会对SQL启动解析并进入计算引擎的选用环节；目前的引擎选用框架驳回了先进的RBO+CBO+HBO的组合启动初步的引擎选用，基于机器学习算法再进一步启动优化（驳回这种方式的要素是宿愿从人工专家阅历颠簸过渡到基于算法模型的方案）。
这局部关键引见腾讯新一代的实时湖仓融合平台。
（1）传统实时湖仓一体架构
从下图可以看出，普通DataSource里的用户数据会经过Flink同步到Iceberg中用于实时读取或批量查问。
该方案好处：增量读取，实时性好；相比MQ更稳固；
该方案缺陷：借用外部查问引擎，查问性能普通。
经常出现的数据湖经常使用场景关键是四种：实时写入离线查问，实时写入实时查问，离线写入离线查问，以及离线写入实时查问。
SuperSQL实时湖仓关键处置了实时写入实时查问的场景。
该方案好处：数据写入实时性更高，接入便捷；查问性能更优。
该方案缺陷：相比拟于Iceberg等湖格局，支持的才干有所短少。
整个架构的流程关键是：用户可以将数据导入到MQ中，借助实时数仓才干（目前才干关键依赖于StarRocks开源引擎）启动实时写入并构建不同层级的数据仓库，在StarRocks中关键存储热数据（最近n天的数据），n天之前的数据智能/手动降冷至数据湖中，入湖之后关键借助SuperSQL跨源跨引擎才干来成功湖仓数据的实时查问。
详细来看，实时/离线数据入仓的全体架构如下图。
实时数据会经过MQ，或导入至Flink再经过Flink写入至实时数仓，而后实时数仓中数据会经过t+1或t+n形式降冷至数据湖。这种方式的疑问是数据湖中的数据会有必定期间的提前，即湖仓数据或许不分歧（局部业务会有数据湖数据批量实时查问的诉求，因此咱们也有一种成功双写入的方案，即数据经过MQ后，同时写入数据仓库和数据湖中，但双写方案对写入性能会有必定的影响）。
离线数据经过外部离线调度平台的插件，准许用户经过Hive、Iceberg、Hudi中的数据离线同步至数据湖中。同时对湖、仓数据启动分区映射。
离线数据的入仓，关于Iceberg数据源咱们借助了StarRocks中Routine Load的才干。经过Iceberg数据组织架构图可以看到，数据湖中的数据每出去一批之后会生成一个新的metadata file文件，经过最新的S0或S1文件之间的差异比拟确认增量的数据内容有哪些，获取增量数据后经过StarRocks外部FE侧的处置生成不同的task义务，再把这些task义务提交到StarRocks BE端，从而成功离线数据的写入。
关于实时数据入仓和降冷也是借助StarRocks中Routine Load的才干把MQ中的数据写入StarRocks；降冷这局部首先会去支持降冷的操作，用户创立降冷义务，并指定详细表的降冷及降冷至什么位置（例如降冷至Iceberg或Hudi等）。降冷义务创立后就会贮存到实时数仓集群中，实时数仓则会定时轮询调度已提交的降冷义务并启动判别哪些分区数据须要降冷、哪些分区数据不须要降冷，假设一切的分区数据都不须要降冷，则进入下一次性轮询；假设有分区数据须要降冷则会提交对应的降冷义务至义务队列中，后续再从队列中取出降冷义务并真正口头，从而成功数据降冷。
降冷后的数据和数据仓库的数据是可以成功融合查问的，这种融合查问是在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倍左右的性能优化。