腾讯大数据平台大脑AI探索与实践

01

趋势与挑战

大数据技术栈的发展是一个不断演进的过程，从最初的数据仓库、商业智能，到分布式计算和实时计算，再到如今的人工智能，每一阶段的技术栈都有其独特的应用场景。

目前整个大数据平台的搭建思路是趋于稳定的，而其上承载的业务量却在呈指数极增长。一些早期通过领域专家处理的问题，现在已经变得难以为继。以腾讯大数据为例，我们面对的是动辄以万为单位的服务器集群，以及错综复杂的技术栈，各种组件之间的协作是相当复杂的，在其上运行的是百万、千万级的任务管理。在这样的情况下，质量、成本以及效率这三点成为了制约大数据平台上业务平稳发展的一个不可能三角。

如何解决上述问题，在腾讯场景中，探索的方向之一就是精耕基本盘，通过BigData + AI的思路，对大数据平台做全面智能化的升级，从人管向自治的方向去演进，本文就将介绍这一智能化升级的建设方案。

首先分析下目前业界的一些趋势。

自治是腾讯下一代大数据平台的能力演进趋势之一，这也是整个业界的共识。如上图所示，Gartner 2022年提出的战略趋势中就提到了：自治系统，超级自动化，决策智能这几个概念，业界的思路可以说是趋同的。各大互联网公司，以及无论是传统数据库场景还是大数据平台场景，都在尝试用智能化手段来解决泛数据库领域的新挑战，期望达到数据库近似自治、“自动驾驶”的平台级能力

02

自治方案

接下来介绍腾讯大数据平台的自治能力的发展情况。

腾讯大数据的自治方案项目被称为平台大脑，其实现路径，是从数据平台自身的可观测性开始，向上构建决策能力，逐步向半自动化以及自动化演进，最后实现智能化。

1.关键能力

在引入自治或者智能决策算法能力之前，首先要把数据底座准备好，它是推动人工智能决策演变的燃料炉。其次如果在单场景中已经做了一些智能化应用的情况下，如何快速地泛化到更广泛的领域，是决定平台大脑的发展速度和可达范围的一个关键因素。所以建设平台大脑，需要有如下图所示的三个关键性的能力。

（1）可观测数据底座

可观测的数据底座是对整个大数据平台自身的一个全方位的观测和画像，通过对大数据领域一些常见问题的解决思路进行抽象，刻画出大数据领域的特征，包括任务、数据、服务三大主题。这三大主题主要是解决平台运营问题，也就是对资源的使用问题。例如任务主题，任务在集群、队列、应用、物理机、虚拟机、容器、进程和线程等各个层面、各个粒度上面都有资源的使用情况，把这些使用情况进行抽象，就形成了任务维度特征，这个特征包含了对计算资源、存储资源、传输资源的使用。对资源的描绘方面，包括其用量、配置量、状态，比如操作占用情况、可用性等一系列特征，这样一整套的特征体系就构成了大数据平台一个全方位观测和画像的数据底座。

（2）可插拔决策引擎

第二个关键能力是可插拔的决策引擎。可插拔的设计意图在于灵活应对大数据技术栈上任意组件的替换与变更带来的诊断场景的变化，从而能快速适配内网或云计算等复杂的环境中，业务方在大数据技术栈上自由搭积木式的选型差异，方便不同技术组件的研发及SRE人员进行自定义配套能力建设。

决策引擎的实现从系统层面来说，涉及到四个概念对象，第一个是上文讲到的特征，称为感知特征；第二个是洞察单元，洞察单元是从特征库出发，依赖特征去开发一些决策能力，这个决策能力是每个最小问题粒度的决策能力，可以是基于规则的，也可以是基于算法的；第三个是业务模型，是对上面讲到的洞察这个单元的诊断项，或者说是决策能力进行一些组装，可以是基于规则的组装，也可以用到类似于根因分析的算法去进行组装，组装完成后就能够形成一些在一定业务场景下的诊断结果，将这些诊断结果与原因或者是建议库、原因库等专家支持的内容去做匹配，最后形成一个决策建议；第四个是决策服务，会按照不同特定领域的需求去组装，然后调用上面讲到的各种决策业务模型，同时服务层也会对外提供感知、洞察以及服务其它能力的服务化的输出。

（3）可泛化决策智能

第三个关键能力是可泛化的决策智能，上文也提到了决策智能，根据Gartner有关报告描述，AI主要分为决策支持、AI助理、决策自动化、智能产品四大类。其中决策支持指的是通过算法对海量数据做挖掘和细分，然后得出见解和预测的事件，并提出解决建议，进而对企业的决策能力产生一些重要影响，从而实现节约成本、提升客户体验，或者实现新的商业模式和增加运营收入等价值。

Gartner认为决策智能会在未来几年内超越其它类型的AI应用，成为最有商业价值的AI产品，虽然现在 ChatGPT 的出现可能会改变这种预测结论，但是在平台大脑实践中确实能够体现出决策智能是非常有效的，具有相当大的业务附加值和最小使用障碍。

决策智能的实现方案多种多样，实践中会尽量探索一些可重用的方法，这样就能扩展到大数据场景各种新领域。

2.应用架构

整体建设方案分为三大模块，从下往上分为：感知层、分析层和决策层。

首先最下层跟数据底座相对应的是感知层，会形成大数据平台自身的可观测体系。其核心意义是要做标准化，针对不同组件的数据源有统一的采集、传输、ETL等等，这一套标准化的操作会形成统一的指标库，用于解决大数据体系之间以及各个组件之间的信息孤岛问题。

中间是分析层，利用感知层形成的统一指标和特征体系去演化出各种分析能力，建立出各类规则策略的知识库，进而集成机器学习的能力和各种优化算法，从而为持续的业务模型的组装奠定一个有力的中间层基础。

最上面是决策层，提供各种增强决策的组合能力，以及我们的产品，例如全链路诊断、健康分、集群巡检以及自动的调优调参等等。

03

自治实践

在实践中发现，智能化的过程并不是一步到位的，先前的数据收集，以及自动化、半自动化的演进过程都是必不可少的。甚至直到今天，这些基础设施的工作仍在不断完善中。接下来将分享一些自治实践。

1.决策智能的一些应用场景

在麻省理工出版的一本关于决策算法的书中讲到，决策智能算法会有类似于显示编程即规则编程、监督学习、优化方法、规划方法、强化学习这些应用方案。在实践过程中亦是如此，接下来以慢任务诊断为例来说明上述各类决策智能的方案方法。

慢任务诊断是如何实现的？横向来看，一个大数据慢任务的治理，事前需要有SQL专项诊断，提供类似辅助编程、自动物化视图，或者对生成的执行计划做优化。事中通过全链路诊断能力去承载大数据慢任务的分析。事后整个周期性的运行任务里还会有一个健康分评价。同时在整个能力体系中会通过自动调优来形成一个大数据慢任务的自愈能力，形成任务处理的闭环。

纵向来看，慢任务是从全局角度出发，如果要防治慢任务，首先需要整个集群健康的检巡预测，可能会发现集群上影响慢任务的慢节点，包括容量规划问题等等。再进一步来看，通过一些异常的实时发现，以及对组件的引擎调度等策略，对集群层面的具体的运行状况进行管理。再往下继续探查，就到了根因分析的层面，它遵循的是trouble shooting常用的自顶向下的排查思路。

在整个慢任务的诊断调优过程中，无论是横向还是纵向思路，起关键作用的其实是大量的规则编程，它会将专家经验沉淀为规则和知识库，然后形成错误码的匹配能力和规则的判定能力。现在大规模应用的Spark调优，其中的规则参数调优实际上也是属于这个范畴。从集群的角度，会去做集群引擎的调度优化。SQL引擎选择是降低failover之后重新调度的场景，其中用到了决策智能的第二大类方法即监督学习。Spark参数调优，JVM的GC参数调优，这些都属于优化方法的大类，优化方法会致力于在一定的参数空间里面找到一组给定目标参数的最优参数配置值。最后，尚在开发中的一个应用，就是对SQL做语法检测的一个语法助手，可以提供一些问题诊断建议，通过大模型的应用，具备自动识别的能力。SQL治理自动化视图，会使用到基于规划或者强化学习的自动决策的方法。

以上都是慢任务场景会用到的一些决策智能的方法。接下来，具体展开介绍一些现在已经落地的场景。

（1）Spark参数调优

Spark参数调优，目前同时实现了规则调优和机器学习的黑盒优化，这两者的实现路径上是可以做到互补的。其优劣对比如下：

• 基于规则的方法，其优势在于专家经验和先验知识，前期的收敛会更快，而且具有安全性，不会出现一些太过于离谱的调优结果。其劣势是不一定能够找到最优解，因为基于规则，如果调优不成功就会进入bad case中，同时也需要大量的人力来开发验证规则，每一个新的场景其可泛化性相对而言比较弱，例如开发资源优化项的规则，并不能平滑的迁移到性能优化项的规则。
• 黑盒优化的优势是人力投入少，可泛化性强，并且经过多轮的黑盒优化之后，中后期一般总能收敛到一个比较不错的解，这个是有理论依据保证的。同时其自动迁移性、通用性和适用性也比较好。其劣势首先是冷启动问题，初始时候不一定能拿到比较好的解，前几次的迭代效果都会比较差，对于现网环境的一些生产任务来说，一些敏感任务容忍度就会比较低，同时安全和有效性方面也不一定能够强满足，其次黑盒优化的计算代价即消耗的计算资源是高于规则优化的，所以需要权衡投入产出比。有一些黑盒优化调优结果明显优于规则优化，比如磁盘溢出问题上，规则调优的效果就不如黑盒优化的效果明显。

在生产实践中两种方法是结合使用的，根据不同的业务场景去选择不同的调优方法，目前在腾讯的很多业务应用里面已经真正大规模落地实践了。从调优表现上来看，在降本场景中，任务调优平均能够达到30%到70%的内存、CPU消耗降低；而在性能调优场景中，任务取得到20%到45%不等的提速。

（2）JVM参数调优

线上任务大部分都是Java栈的，调整的不只是Spark资源相关的一些参数，还有JVM参数，即Java虚拟机的参数。一般Java虚拟机制主要关注GC即垃圾回收的相关参数，相比资源参数，GC参数更为复杂，而且需要非常强的JVM领域的专家经验。使用自动调优，则不需要太多的先验知识，只需要专家少量参与去定出优化范围，然后在原有Spark的基础上去做参数空间的扩展，同时做有限的限制，并且固定Spark资源参数，然后先对GC参数进行单向的调优，对比调优前后的增益，因为资源参数是相对固定的，所以能够更多地关注到GC参数对于执行时间的影响。

从调优结果来看，如果本身存在GC问题的任务，其执行时间基本上都可以得到缩减。如果初始没有什么GC问题，或者实际表现中GC的时间占比较低的任务，使用了自动调优，基于黑盒的调优也不会让任务的运行时情况变得更糟。所以在真正应用JVM参数调优的时候，实际上也要加上基于规则的预判定，即针对哪些类型的任务才会去做JVM参数调优，这其实也构成了规则和配合优化结合的另外一个场景。

（3）SQL引擎选择

在数据分析任务中，通过一个统一的SQL引擎选择对用户透明底层的各种OLAP，或者SQL计算引擎，在提交SQL任务时，平台需要去决策到底是使用Presto，还是Spark引擎做执行。如果使用Presto，查询速度会更快，但是部分任务并不适用，例如语法等问题，如果执行失败，会浪费资源，影响任务执行时间和效率。因此在引擎侧要做一个自动化的引擎选择。

起初SQL组的同学基于规则，基于历史的情况做出优化选择，经过不断地规则优化，选择成功率达到了瓶颈。通过增强决策方案能够有效地提升成功率，这里借助机器学习，学习到SQL查询语句跟执行引擎之间的关系，然后进一步去指导选择。

从实际线上效果来看，能够在原来的基于规则CBO或者HBO的基础上，失败率能够再降低60%到80%左右，最终线上能够达到稳定的成功率在90%以上。

2.场景落地的一些关键卡点

基于这些场景的应用效果，腾讯平台大脑已经沉淀形成了一些比较完备的产品能力。接下来介绍产品在落地中间的一些经验总结或者反思。

AI算法的三要素：数据、算法、算力，缺一不可。决策智能落地的一些关键卡点，也是这三要素在不够完备情况下的具象化体现。接下来会分析一些具体的场景案例。

（1）全链路诊断场景

该场景在落地过程中面临的卡点，首先是数据覆盖度不足导致的诊断未命中问题，是数据方面的问题。其次，时效性不足导致诊断时间过长，体验下降，是算力方面的问题。最后诊断准确性和能力覆盖度不足影响诊断结果准确性，是算法方面的问题。

（2）健康分诊断场景

健康分场景跟全链路诊断场景比较类似，因为其内核是相通的，健康分场景也存在上述覆盖度和准确性的问题，同时健康分场景由于同时维护了离线和实时两套逻辑，这样就影响了易维护性。这种妥协是由于算力制约，在Lambda 架构上的妥协，当前正在通过切换到Kappa架构来解决这个问题。

（3）大规模在线自动调优场景

大规模在线自动调优场景，就是前文讲到的将各种自动调优做一个大规模的落地，目前已经将其服务化，并与各种离线任务调度平台做了对接，全局优化效果目前达到30%。

在推广过程中遇到的卡点，首先是更好的优化结果与模型消耗计算资源之间的权衡，其实也就是用规则还是用黑盒之间的权衡。其次是降级的容错性来保障业务稳定，和本身的迭代收敛过程之间的权衡，这其实是算法的问题。最后是数据本身的及时性对于决策能力的影响，这是数据方面的问题。

04

总结展望

大数据平台的在线自治能力，是致力于以数据为驱动，结合专家经验和AI算法，全面提升大数据平台在问题发现、根因诊断、故障修复、效率提升、资源优化等方面的智能处置能力。通过这些能力去赋能数据科学家，更加高效、安全、稳定地去完成其数据任务，从而进一步释放数据生产力。

在实践中已经验证有效的决策智能方案是从经典规则、再到优化规划以及探索中的强化学习等等的综合选型。在泛化能力方面，是通过可插拔结构的架构方案来支持，或者通过统一的协议接口在新的场景做快速的接入适应。各类机器学习的模型能力，在泛化方面有着天然自适应的优势。

在决策智能的应用实践过程中，仍然需要解决AI的三要素，即数据、算法、算力方面的卡点，这个方法论与主流的智能化建设并无二致。

我们认为基于决策智能的产品智能，会逐步成为新一代数据产品的标配，并且会催生出全新的运营和研发模式。未来，大数据自治演进出来的大数据平台，会成为一个专家、助手和管家三位一体的角色，去智能化地服务于用户的提效、组件的赋能、以及平台的运营等各个方面。