作者 | yikonchen,腾讯大数据计算平台负责人 专家工程师
SuperSQL 是腾讯自研的下一代大数据自适应智能计算平台。通过开放融合的架构,实现一套代码高效解决公有云、私有云、内网的任何大数据计算场景问题。我们通过将异构计算引擎 / 异构存储服务、计算的智能化 / 自动化、SQL 流批一体纳入内部自适应闭环,给用户提供极简统一的大数据计算体验。用户能够从繁杂的底层技术细节中解脱出来,专注于业务逻辑的实现,像使用“数据库”一样使用“大数据”,实现业务逻辑与底层大数据技术的解耦。
SuperSQL 作为腾讯大数据智能计算平台的入口和决策中心,整合不同的大数据系统组件,旨在解决传统大数据架构下的痛点和难点问题,诸如大数据的语言门槛高、大数据引擎多而杂、大数据计算链路长而复杂、资源利用率低、存储异构、数据孤岛等。SuperSQL 以自适应作为串联不同系统的能力抓手,通过自动、智能的方式解决传统大数据架构中的痛点问题:
1 计算平台整体架构
图 1 自适应智能计算平台整体架构
SuperSQL 提供了完整的端到端的大数据解决方案,适配公有云、私有云、内网不同的场景。整个架构可以分为四层:
2 语法自适应:解耦大数据语法和业务逻辑
SuperSQL 支持对接不同类型的外部计算(执行)引擎,包括 Presto、Livy、Hive、Flink,以及丰富多样的数据源,如 MySQL、PostgreSQL/TBase、Hive、TDW Hive (tHive)、SparkSQL/Livy、Oracle、Phoenix (HBase)、ElasticSearch、Kylin、ClickHouse、Hermes、Druid、H2、Presto。引擎之间、数据源之间所使用的 SQL 语法存在一定的差异,SuperSQL 作为计算平台的入口能够有效屏蔽语法差异做到语法自适应,从而为整合不同的大数据系统组件提供基石。提供一套通用 SQL 语法,并通过 SQL 兼容转换功能来实现不同 SQL 语法之间的转换;做到在用户无需更改 SQL 语法的前提下实现底层执行引擎的切换,通过一套 SQL 语法,自动适配不同计算引擎和数据源语法。
顾名思义,SQL 兼容转换功能整体可以划分为两个模块,即 SQL 兼容与 SQL 转换。
1.SQL 兼容:在进行 SQL 兼容时,为解决部分大数据平台语法与业务强耦合、定制化严重,以及不同语法强行融合易导致歧义的问题,SuperSQL 遵循干净、可扩展、可替换、多场景兼容的兼容准则,提供插件式的解析模块,将 SQL 语法模板化,分类管理,形成可扩展、多样的 SQL 生态。SuperSQL 将 SQL 语法分为两大类即通用型(如 SQL 标准语法,以及常见的 Spark、Hive、Flink 等大数据查询语法)、独特型(自定义语法,不具有普适性),基于分类语法模板、语义扩展定义、配置文件生成多样的 SQL 解析器,并且支持动态切换解析器,灵活性强。任意解析器得到的语法树均将转换为 SuperSQL 统一的逻辑计划,SuperSQL 可基于此逻辑计划生成符合不同引擎或数据源方言语法的执行语句(这一过程即 SQL 转换)。SuperSQL 默认使用通用 Parser,其基于 SQL 标准语法,支持大部分通用大数据语法(如 Spark、Hive 语法),适用于大部分的大数据系统组件。而对于一些与业务逻辑强耦合的自定义语法,支持自定义 SQL 模板,生成自定义解析器,通过这种做法,结合上文提及的生成 SuperSQL 统一执行计划以及下文提及的 SQL 转换,可以灵活地将业务任务切换到指定引擎。
2.SQL 转换:SQL 转换发生在两个阶段,一阶段是通过解析器得到抽象语法树后,进行语法树重写以确保该语法树能转换为 SuperSQL 统一逻辑计划;另一阶段是基于 SuperSQL 统一逻辑计划与不同引擎或者数据源语法之间的等价映射关系,能够将 SuperSQL 逻辑计划转换为不同的引擎或数据源语法,做到执行引擎的无感切换,也为下文的智能引擎选择功能奠定基石。
这种执行引擎的无感切换,不光能让 SuperSQL 平滑进行智能引擎选择,充分发挥引擎的优势特点,增加 SQL 执行效率;还能支持业务无感迁移,做到在用户无需更改 SQL 语法的前提下实现底层执行引擎的切换,并且尽量最小程度地更改用户的使用习惯。
通过 SQL 兼容和 SQL 转换,SuperSQL 能够统一计算入口,整合大数据平台组件,降低大数据系统使用的门槛和繁琐程度。
3引擎选择自适应:智能选择引擎,加速 SQL 计算
智能引擎选择是自适应智能计算的核心功能之一,作为决策中心,SuperSQL 通过组合算法,自动为每条用户 SQL,挑选合适的不同类型的计算引擎(如 Presto、Spark 等)来执行,以提升用户体验(如响应时间快、可靠性高等)和资源利用率(CPU、内存等)。传统基于 RBO/CBO 的 SQL 优化框架,存在规则人工定制、统计信息缺失、历史流水闲置、失效资源浪费等几个主要问题。针对这些问题,SuperSQL 设计实现了基于历史负载的查询优化(History-Based Optimization,HBO)和基于机器学习的引擎选择。HBO 目标是分析处理历史用户 SQL 流水,以通用、抽象化的 HBO 策略,增强补充(非取代)已有的具体化 RBO/CBO 策略。机器学习算法可以自动学习 SQL 特征,更好地弥补人为规则的黑角。把 HBO 和机器学习结合起来,可以更好地降低日均提效失败(即错误选择引擎后执行失败)的 SQL 数,提升用户 SQL 的平均执行时间,减少引擎集群无效负载的同时节省宝贵的计算资源。
HBO 框架的设计实现包括四个子模块,如下图中标示;它们也代表了一条用户 SQL HBO 优化的四个串行阶段。基于引擎选择(SQL 优化)的实时性要求,整个 HBO 耗时必须控制在毫秒级。
1. 查询签名:SuperSQL 执行的所有计算类 SQL 语句(DQL/DML),无论执行结束后状态是成功还是失败,流水入库时都新增生成查询签名(Query Signature,QS)字段。
查询签名是 SuperSQL 自研设计的 SQL 文本的 “浓缩” 表示,包含 SQL 访问库表名和关键子句(Filter/Join/GroupBy/Orderby)中包含的列名。SuperSQL 通过 QS 来匹配判断当前用户 SQL 与哪些历史 SQL “HBO 等价”,然后通过分析汇总这些历史等价 SQL 的执行特征,来决定当前 SQL 是否应选某类引擎执行。
2. 索引宽表:HBO 要求为每个最新提交的用户 SQL,从历史流水库中查找其最近一段时间内等价的历史 SQL 集。SuperSQL 依赖外部的统一元数据服务,固化缓存 HBO 索引宽表来解决检索的实时性能问题。宽表的每一条记录对应一条历史 SuperSQL 查询,包括查询签名、执行时间、引擎类型、结果状态、数据量、引擎 shuffle 数据等信息。
3. 历史检索:基于查询签名的完全匹配(exact match),调用统一元数据服务的 REST API,返回最近历史区间(如一周)内的索引宽表记录集。SuperSQL 通过不同的 API 入参,指定返回记录集的最大行数、起止日期、超时时间等属性,确保检索的实时性能(平均 < 100ms)。
4. 提效判定:分析统计获取的历史记录集,综合执行时间、失败率、引擎分布等数据,对比系统阈值参数,决定是否对当前 SQL 选择使用的某类计算引擎来执行。
作为业务效果样例,根据对接 SuperSQL 的某数据分析中台的 SQL 流水统计,HBO 加持的 SuperSQL 智能引擎选择,可以大幅减少因为引擎选择错误导致的 SQL failover。HBO 规避的 SQL 类别大都是超大资源占用、海量分区读写、大规模 Join 等高计算开销类,日均可减少 Presto 引擎 34TB 的无效内存占用以及 33 小时 的无效 CPU 时间。引擎选择失败规避率(规避率 = HBO 规避 SQL 数 / 提效失败 SQL 总数)在按月稳步提升,到 7 月已达到 70% 左右。
HBO 不能覆盖所有的 SQL 场景,对于周期性任务较为有效,但如果用户提交了新的查询,签名和历史不匹配,则难以决策。机器学习可以自动学习 SQL 特征,很好地弥补规则的缺失。实践中,直接把 SQL 字符串作为原始数据,具体训练过程如下:
4 计算运行时自适应:实时捕捉环境变化,动态调整计算拓扑
传统的大数据架构下,整个计算链路通常是单向的,上层计算缺少底层状态(比如资源状态)的反馈。单向链路虽然简单,但会造成计算资源不均衡、资源利用不充分等问题。算力感知是自适应计算架构里底层反馈的桥梁,让上层计算具备感知资源状态的能力,进而自适应地调整资源使用。通过算力感知,可以获取计算资源整体的资源状态以及单节点详细的算力指标,上层计算借此自适应地动态调整计算决策、资源使用、任务调度等。
以 Presto 为例,作为一款典型的 MPP 架构、纯内存计算的交互式查询引擎,为了追求性能的最大化,Presto 会尽可能地利用节点上可用的资源,包括 CPU/ 内存 / 网络带宽等,节点间的物理资源规格也需要尽可能保持一致。然而在实际的使用场景中,节点的 CPU/ 内存等负载(算力)是随时波动的,而 Presto 的原生任务调度策略并未将节点的算力考虑在内,导致在节点算力明显下降的情况下,计算任务会受到严重的影响,从而产生长尾问题。为此,天穹 Presto 做了针对性的优化,在动态的计算环境中,通过感知节点算力的变化,自适应地调整计算任务的调度,避免低算力节点的影响。
天穹 Presto 自适应任务调度主要分为:Task 自适应调度与 Split 自适应调度,方案实现的核心思想是:根据节点的算力情况动态分配 Split 和 Task,整体架构如下图所示:
天穹 Presto Coordinator 在运行过程中,会实时感知 Worker 节点的算力变化情况,同时计算出对应的节点可用算力权重,在 Task 和 Split 的调度过程中,针对不同的算力权重,根据模型计算出相应的 Worker 上还可分配的 Task 或 Split 数目,对于算力严重下降的节点,少分配或不分配 Task 或 Split,尽量避免长尾问题,从而做到自适应的调度。
自适应调度效果:当计算 Task 在 CPU 波动比较大的节点上,会造成明显的计算长尾的问题,拖慢整个任务的运行,如下图所示,在没有开始自适应调度的情况下,Task 的执行时间波动很大。
在开启自适应调度后,Task 会避免调度到 CPU 算力差的节点,有效地消除长尾问题。如下图所示,Task 的执行时间更加均衡,避免长尾问题影响整个计算任务的性能。
5 资源自适应:资源统一池化,透明弹性伸缩
面向大规模集群部署,多集群是运维管理的常规手段。但从资源管理的角度,多集群会带来诸多问题:1. 资源对业务不透明,业务在使用计算资源时,需要人为指定特定集群。人为选择集群的方式不仅麻烦,也会带来集群负载不均衡的问题;2. 由于资源不能统筹管理,资源整体利用率不高。资源自适应的目标是把能够把所有资源统一管理起来,对计算提供统一的资源池,对资源统一调度,打破集群间的隔离问题,实现对资源的公平共享,充分利用空闲资源,提高资源利用率,同时对业务透明化。
资源自适应主要包括集群间弹性伸缩和集群内资源调度。每个租户对应一个虚拟 K8S 集群,每个租户都有最低的资源保障,租户之间能借用资源,也可以借用集群空闲资源。通过自适应调配资源,打破集群间的隔离,充分利用不同业务的潮汐效应,错峰使用资源,提升整体的资源利用率。
6 数据编排自适应:融合异构存储,自动查询加速
在公有云、私有云、内网不同场景中,大数据底层存储是异构的,主要涉及 COS、HDFS、Ceph、Ozone 等。面向异构化的存储,统一融合计算平台构建了一层统一的数据编排层(DOP),位于计算和存储之间,透明化存储差异。通过适配不同的权限和认证体系的统一的存储 Client,解耦计算和存储,避免不同计算引擎和不同存储间的相互适配工作,让计算和存储更加专注。在大数据场景中,每天产生海量的数据,而数据治理往往赶不上数据积累的速度,海量元数据以及小文件会给存储 Master 节点(例如 HDFS NameNode)极大压力,造成性能抖动。数据编排层会自适应缓存存储元数据,以及自动小文件合并,减轻 Master 节点压力,同时在跨 DC 数据访问时,加速元数据访问,提升数据访问速度。
数据编排层会针对不同的场景通过热数据缓存,加速计算性能。在内网的 ad-hoc 场景中,采用 LRU/LRFU 相结合的数据缓存策略,整体计算性能加速比 2.6 倍,而对于 IO 密集的 SQL,加速达 6.2 倍。
7 场景架构自适应:多云混合,架构统一
SuperSQL 适配多云混合架构,支持跨 DC、跨云的联合数据分析,打破数据孤岛,打通跨 DC、跨云的数据访问链路,最大化数据价值。通过完善的数据下推、自研的跨 DC CBO,构建最优的计算路由,实现高效、安全的数据分析。在腾讯内跨 DC 访问场景,数据下推和跨 DC CBO 可以有效地降低跨 DC 高峰时段网络流量约 30%。
8 总结 & 未来规划
未来 SuperSQL 会持续专注在统一融合计算平台中,打造更快、更稳定、更易用的大数据自适应智能计算架构,具体会在以下方向上持续探索潜力:
9 推荐阅读
官方出品:腾讯大数据构建之道首次对外披露!腾讯大数据平台十年磨一剑,践行“科技向善”落地方案——《腾讯大数据构建之道》。本书由腾讯数据平台部组织,腾讯公司副总裁蒋杰领衔撰写,首次对外详细阐述了腾讯大数据平台系统架构,以及多年来平台建设的思考与沉淀。
点击下方小程序参与活动,共抽取 5 名 InfoQ 的读者朋友分别送出《腾讯大数据构建之道》一本。也可以点击阅读原文购买书籍。
今日好文推荐
资深 Web 开发的经验之谈:为什么你开发的网页不应该大于 14KB?
80 岁 Unix 大神还在修复 AWK 代码;华为全线收缩和关闭边缘业务;小鹏汽车回应苹果汽车前工程师窃密认罪案|Q 资讯