在大数据平台高速发展的当下，生态扩张与业务量激增，致使大数据分布式组件问题愈发棘手，传统专家运维模式捉襟见肘。以腾讯大数据庞大的规模为例，面对海量计算单元、繁杂技术栈以及千万级任务管理，借助 AI 驱动实现大数据系统的故障和问题的快速洞察与自治能力，已成为行业迫切需求。
在 InfoQ 举办的 QCon 全球软件开发大会（北京站）上，腾讯专家工程师熊训德做了专题演讲“AI 驱动的大数据自治：智能应对复杂运维挑战”，他介绍了如何通过可拔插的决策引擎、以及数据专家自治智能体构建大数据智能管家，让企业能够理解如何高效、智能地处理复杂的运维场景，从而大幅提升大数据场景下运维效率与准确性，引领大数据线上系统迈向全面自治的实践。
以下是演讲实录（经 InfoQ 进行不改变原意的编辑整理）。
大数据系统自治背景与挑战
首先，我简要介绍一下整个大数据系统，以及其在自治背景下的相关挑战。大数据系统本身组件众多，涵盖了从底层的 IaaS，到存储、计算框架，以及上层的工具层等多个层面。具体来说，IaaS 层面涉及到机器本身的网络和性能，而存储层则包括分布式文件系统（如 HDFS）和对象存储等。在调度方面，我们有 Kubernetes 和 Hadoop- 体系，以及针对 AI 方面的特定调度机制。再往上一层则是计算框架，例如 Spark 和 Flink 等流计算框架。最上层则是各种工具，这些工具在不同方面的使用都使得整个大数据系统的复杂性显著增加。
大数据系统本质上是一个分布式系统。如果单机系统已经如此复杂，那么分布式系统则需要考虑数据的溯源以及在不同机器上的分布情况，无论是主从结构（master 和 slave）还是多工作节点（worker）的协作模式，都会使得整个系统在处理问题、查找根源以及故障恢复时变得极为困难。此外，大数据系统的数据处理链路通常非常长。例如，数据采集可能来源于多种源头，如代理（Agent）、MySQL 数据库，或者在物联网场景下，可能是汽车或传感器等设备。采集到的数据需要通过数据接入层，目前常见的架构包括 Kafka 或其他消息队。接入后，数据会进入计算阶段，可能是实时计算（如 Flink）或离线计算（如 Spark）。计算完成后，数据需要存储到 HDFS 系统或对象存储中。最后，在数据应用层面，我们可能需要进行预处理以供 AI 使用，进行训练或推理工作，或者生成商业智能 BI 报表。因此，整个数据链路非常长，这也使得我们在进行故障根因分析或自治处理时，需要综合考虑所有相关场景。
当我们处理大数据故障时，业务部门或客户往往会提出一个关键问题：“何时能够恢复？能否实现自动恢复，以尽快减少损失？”然而，我们在进行故障恢复或诊断时，高度依赖于运维 SRE 的专家经验。通常情况下，如果没有三年以上的大数据运维经验，很难有效且完善地处理复杂的大数据故障。此外，由于整个诊断和故障恢复的时间链路非常长，导致整体效率低下。更糟糕的是，故障可能已经结束，而我们只能进行事后处理，此时大数据系统可能已经遭受了实际的损失。
大数据智能管家技术框架及关键实现路径
腾讯大数据智能管家 TCInsight 技术架构
基于这些背景，我们团队在大约五年前提出了构建大数据智能管家 TCInsight 的想法，致力于解决大数据系统自治相关的工作。我们的大数据智能管家整体技术架构分为三层。
第一层是观测层。它主要负责监控基础设施即服务（IaaS），包括主机网络等的监控数据，同时采集日志和关键事件。我们还将大数据组件，如 HDFS、Spark、Hive 和 YARN 等的关键监控日志事件进行统一上报。
第二层是服务分析层，主要负责数据实时处理和算法决策洞察。服务分析层分为三个部分。第一部分是实时分析，主要目的是快速处理数据，包括异常收敛。例如，当事件或告警过多时，我们需要迅速整合，否则会给运维 SRE 或研发人员带来较大挑战。我们会对数据进行基础预处理。第二部分是离线服务，主要用于根因分析或自治服务时的离线分析和定时巡检。在数据量较大时，离线分析尤为重要。第三部分是算法决策，主要涉及模型和算法库的分析，以及知识库和评测库的建设，还包括离线训练等工作。
第三层是应用层，主要负责大数据运维自治，并对外提供接口。应用层分为两大块：自治修复和自治决策。例如，以 Hive 为例，当业务侧编写了一个 SQL 查询，可能会导致 HDFS 存储空间被占满，从而影响其他任务的提交。此时，我们需要快速对该 SQL 进行限制，或者在业务非常关键且不能直接终止的情况下，预测可能得存储和计算量，进行自助弹性伸缩。此外，我们还需要进行冷热数据分离，以实现成本分析和自助转冷操作。在自治决策方面，我们需要判断是否进行参数调优，因为某些参数调整可能需要重启系统才能生效，这可能会扩大故障范围。此时，我们需要做出关键决策，例如选择扩容，或者让 AI 参与具体工作。我们还可以进行错峰执行，例如在 YARN 的多个队列中，调整队列的执行时间，以优化资源分配。
应用层还包括业务洞察部分，主要用于预测分析、成本分析和根因分析等工作。这些工作相对滞后，我们的目标是先恢复系统，然后再进行深入分析。此外，我们还会生成巡检报表，并进行一键健康评估。健康评估在我们的系统中非常重要，它综合评估了 IaaS、存储、调度和计算等各个部分的健康状况，为关键自治决策提供依据。
在架构的中间部分是我们的算法或引擎层。引擎分为两部分：规则引擎和我们自主研发的元启引擎。元启引擎结合了 AI 算法和我们内部的混元大模型。规则引擎主要用于执行明确的操作，例如扩容，以缓解问题。对于复杂或关联性较高的场景，我们会接入算法或大模型，以提升系统的健康状况。
接下来，我会详细说明我们在大数据智能管家过程中的一些关键思考和实现能力。
分层的大数据运维框架 - 渐进式自治
由于大数据体系的复杂性，TCInsight 实现自治的是一个渐进式的过程。当我们接手一个系统时，不能期望所有大数据运维工作能够立即实现完全自治。实际上，我们基于一个较为普遍的理念：在没有一线专家或专业人才的情况下，一线人员或客户也能够实现自治处理。
我们根据问题的复杂程度进行分类处理：对于简单重复且解决方案确定问题，我们直接采用 AI 驱动的方式进行处理。目前，这类问题大约占我们总问题的 10% 左右。然而，剩下的 90% 问题尚未能完全实现自治。对于这部分问题，我们希望通过售后体系中的专项人员和 SRE 的共同努力，借助我们之前提到的平台层，利用大模型和 AI 增强能力，持续为系统提供支持。
在此基础上，我们期望通过三年以上经验的产研人员或 SRE 专家，进一步强化知识库和工具建设。通过这种逐步积累和优化我们的产品能力，我们希望能够逐步提高自治的比例，最终使其达到 90% 以上。
多智能决策引擎思考和设计一问题域
在业界，主要有三种常见的方法：显式编程、基于优化方法的处理以及专家系统。第一种显式编程对于研发人员来说并不陌生，它本质上是通过编写规则或工作流来构建一个简单的规则引擎，从而实现直接的决策。例如，当存储使用率超过 75% 时，系统自动触发扩容操作。这种方法简单直接，但灵活性有限。
第二种是基于优化方法的处理。在大模型尚未普及的时代，我们通过优化模型来提升系统性能。例如，原本只能优化 40% 的系统，通过采用贪婪算法或聚合模型等技术，可以将其优化效果提升至 80% 以上。这种方法更多地依赖于深度学习和大模型的强大能力，能够更好地处理复杂的优化问题。
第三种是智能全自治域系统。全自治域系统的核心在于利用专家的经验和知识，尽管专家人数有限，但他们的经验可以通过系统化的方式赋予平台更强的能力。专家系统的关键在于如何将专家的经验转化为可操作的决策逻辑。
在明确了这些决策引擎的技术路径后，我们进一步思考了在大数据领域构建智能决策系统的关键问题。首先，数据的可用性至关重要。无论是基于 AI 的训练还是大模型的应用，数据标注的准确性和完整性是基础。如果数据标注不足，可能会导致模型出现幻读甚至错误的输出，从而影响决策的准确性。
其次，系统的可解释性也是一个关键问题。专家和文档作者需要确保知识库中的内容不仅系统能够理解，而且一线人员和客户也能够轻松掌握。这一点直接关系到决策的准确性和适用范围。
最后，实时性要求也不容忽视。我们的目标是先快速恢复系统，后续再进行深入分析。这就要求决策过程和最终的行动必须足够迅速，以满足实时性的需求。
综合考虑以上因素，在决策引擎的选择上，我们决定结合规则引擎和专家系统的智能决策引擎共同构建了全自治域系统 TCInsight。这种方法既能够利用规则的明确性和可操作性，又能借助专家系统的灵活性和经验优势，逐步提升系统的自治能力和决策准确性。
Al 驱动的规则引擎自治系统
在构建基于规则引擎的知识系统时，我们首先对系统中的各类数据进行了统一管理。这些数据包括指标（metrics）、日志（log）以及事件（event），我们会将它们统一上报至我们内部构建的数据库适配系统。该系统是基于 Inpara 和 Flink 构建的，数据最终会被存储到时序数据库中。随后，我们利用 Flink 对数据进行预处理，并结合训练好的模型以及特征库，对数据进行特征分析。基于这些分析，我们会进行基础的异常检测、关联分析以及趋势预测等工作，从而形成初步的告警摘要和预测摘要。
例如，我们可能会收到告警信息，提示 HDFS 存储空间即将用尽，或者 YARN 队列的等待时间过长，又或者 StarRocks 或 Trino 的 CPU 占用率过高，某个 SQL 查询扫描的数据量过大，超出了设定的阈值。基于这些信息，我们会生成整体的告警或预测摘要。如果预测显示 HDFS 的增长趋势过快，可能会在 5 分钟内被填满，我们就会对 IaaS、存储、引擎和调度等各个层面进行评估，计算它们的健康分数。如果健康分数低于某个阈值，或者即将达到该阈值，我们就会启动规则引擎进行处理。例如，我们可能会尝试简单的扩容操作来缓解问题，或者在业务允许的情况下，直接终止一些不关键的 SQL 查询或任务，以减少资源占用。
在执行这些操作后，我们会制定一个详细的执行计划。以扩容为例，在执行扩容操作之前，我们需要先检查 HDFS 的整体状态是否正常，数据是否均衡分布，以及 NameNode 和 DataNode 之间的流量是否稳定。因为如果流量过大，可能会导致 DataNode 负载过高，甚至引发更严重的问题。只有在确认一切正常后，我们才会通过 IaaS 层扩容机器，并在扩容完成后进行数据均衡操作，以确保系统恢复正常。
完成这些操作后，我们会记录整个过程的状态，并进行反馈。如果扩容后监控数据显示系统恢复正常，那么我们认为这次自治决策是成功的，并将结果记录下来作为后续处理的参考。然而，如果扩容后情况反而恶化，例如数据倾斜导致 SQL 查询速度变慢，引擎侧的健康分数急剧下降，那么我们会紧急通知专家介入，重新审查整个分析过程。
这种基于规则引擎的处理方式具有高效和准确的特点。目前，在我们系统中，基础指标的覆盖率达到 90%，存储场景的覆盖率为 50%，任务场景的覆盖率为 30%。在周期性任务的处理上，我们已经能够覆盖 90% 的场景。在异常诊断方面，我们能够处理 70% 的异常场景，整体数据表现良好。
这并不意味着我们的工作已经完成。实际上，大数据系统的复杂性远超我们的预期。例如，我们在两年前曾遇到一个问题：在对 HDFS 进行扩容后，发现数据分布不均衡，导致 Spark 任务的执行速度反而变慢。从常理来看，扩容后资源增加，任务执行速度应该加快，但实际上并非如此。原因在于扩容后数据的均衡性并没有达到预期，同时业务侧提交了大量任务，导致系统整体性能下降。这说明我们目前只能处理已知的情况，而对于一些未考虑到的复杂场景，我们还需要进一步优化和改进。
Al 驱动的全自治域系统
基于上述思考，我们提出了一个全新的全自治系统概念。与之前的方法不同，我们在决策过程中引入了大模型的相关分析。无论是当前备受关注的 DeepSeek，还是此前我们接触过的其他类似模型，其核心优势在于执行步骤和推理能力。因此，我们开始尝试将大模型的相关功能融入整个自治决策系统中。
在预测和分析阶段，系统仍然会进行数据预处理和特征分析，并开展异常检测、关联分析以及趋势预测等工作。这些信息汇总后，会生成初步的概述信息。然而，与以往不同的是，由于引入了大模型，我们需要构建一个“优先级与目标系统”（以下简称“目标系统”）。我们会在这个目标系统中预先定义优先级和目标。例如，对于存储系统，我们设定存储使用率不得超过 80%，并且数据不能快速转冷；对于引擎，我们希望优化其执行时间；对于上层应用，我们要求其不能出现错误。这些优先级和目标会被配置到目标系统中，生成诊断建议。
随后，我们会将这些数据输入到混元模型中，并结合我们之前的决策分析结果，生成具体的执行步骤。这些执行步骤融合了传统执行引擎、规则引擎以及传统深度学习算法或基础算法的执行计划。执行计划生成后，我们会重新预检测系统状态，重新评估预测分析结果以及执行计划可能带来的状态变化。
如果发现执行该计划后系统健康分数可能更低，即情况可能恶化，那么我们的专家团队会介入。我们会创建一个专家工单，让专家对执行计划进行评估，并决定是否停止执行。相反，如果预测和状态评估显示执行计划后系统健康分数将高于目标值，那么我们会执行该计划，并将执行计划标记后存入知识库。
执行完成后，我们会继续进行预测分析、异常检测以及整体状态评估。如果系统健康度如我们预测的那样有所提升，我们会重新进行标记和分析，以便系统能够继续执行后续操作。
数据质量对预测影响 & 优化
在构建整个系统的过程中，我们花费了大量时间进行调试，尤其是在系统上线试运行阶段。现在，我想重点介绍一下我们在调试过程中采取的关键措施，这些措施让系统更加稳定，并显著提高了预测的准确率。
对于从事时序预测研究的人员来说，一个常见的问题是如何处理上报数据中的断点。这种情况可能由多种原因引起。例如，当系统发生故障时，机器的 CPU 或内存可能已经满负荷运行，导致在关键时刻数据丢失。在分布式系统中，这种数据丢失可能会引发上层系统的乱序操作。假设我们上报的时间是 12 点整，但由于长时间的内存不足（OOM）或 CPU 负载过高，数据可能直到 12 点零 5 秒甚至 12 点零 1 分才上报。然而，故障的实际发生时间并非 12 点零 1 分，但上报时间却显示为 12 点零 1 分，这就导致了数据的乱序问题。此外，还可能出现重复上报的情况，即同一条日志或指标连续上报多次，这使得我们难以确定真正的时间点或事件。
这些问题引发了几个关键的挑战。首先，当数据出现断点时，我们需要决定是否进行插值。目前业界常用的算法包括直接丢弃数据或采用简单的插值方法。对于故障场景来说，直接丢弃数据可能并不是一个好方法，因为这些数据代表了当时关键的监控指标。即使进行插值，如果处理不当，也可能导致数据不准确。此外，如果数据质量不佳，将严重影响我们的预测能力和关键异常处理能力。
我们重点对数据质量进行了优化，主要从三个方面入手。首先，我们对时序指标或日志的有效性进行评估。以往最简单的评估方式是检查数据是否超过完整性阈值。另一种常见的做法是检查数据是否满足差分阈值，或者在 IoT、时序场景中直接进行简单的拼凑。我们提出了一种基于完整性的实际评估方法。具体来说，我们将每个数据进行分段处理，然后基于自回归模型对每个分段进行评估检测。如果数据通过了自回归分析的评估，我们认为这些数据是可用的。
在确认数据可用之后，我们面临的另一个问题是数据的补齐和连接。目前常用的方法包括直接进行差分或简单的拼接。我们的思路是采用自回归预测和自回归拼接的方法。这种方法的优势在于处理速度快，能够快速对分段数据进行处理。此外，这种方法既能进行预测，又能完成数据合并操作。通过这种方法，我们显著提升了数据的有效性，整体提升了 10%。在周期性任务和异常诊断方面，准确性提高了 30% 以上。同时，时序预测的时间也缩短了 28%。
我们在构建大数据专家库智能体的过程中，尝试了一种与业界常见的做法略有不同的方案。我们不仅实现了向量检索，还引入了文本检索。这种设计的选择源于我们在构建知识库时对传统向量检索方法的深入思考。
传统向量检索在相关性分析方面表现出色，例如在使用 FastText 等工具时，能够快速识别出与查询相关的数据。然而，这种方法存在一个明显的局限性：它无法直接反映召回数据的质量，也就是说，在检索过程中，我们难以预估数据的相关性是否真正符合需求。为了解决这一问题，我们引入了文本检索机制。通过文本检索，我们能够更清晰地理解数据之间的关联性，尤其是在知识库的构建过程中。
当我们构建知识库时，一个常见的思路是将操作步骤进行分层。以扩容操作为例，它可能与存储层有很强的相关性，但这种相关性背后的原因并不明确。通过文本检索，我们可以补充这些缺失的上下文信息，从而更全面地理解数据之间的关系。
大数据系统通常分为多层，包括大数据存储层、调度、和引擎等等。这些层之间的相关性可能很强，但它们之间的索引空间检索范围并不像我们想象的那么大。基于这些考虑，我们采用了腾讯的 ES 的架构，结合文本分析和向量检索的优势。这种架构不仅支持大规模的读写操作，还具备高效的检索能力。
通过这种方式，我们能够更好地处理组件之间或分层之间的关联关系，使得各部分之间的距离更近，从而提高系统的整体效率。在故障恢复之后，除了通过冷启动将知识库连接起来，我们还利用工单系统、客户反馈和专家系统，结合混元大模型，实现自动化的分类和归纳，持续完善知识库的建设。
实践效果与案例分享
AI 驱动的 HDFS 存储规则引擎自治
我们来看基于 HDFS 存储规则引擎的自治。这里的关键在于如何快速抽取和分析 HDFS 的 FSImage，以及如何准确把握特征点。我们知道，HDFS 的源数据是以树形结构存储的，而现有的工具无法对这种树形结构进行并行化处理。为了解决这个问题，我们将工作拆分为两部分：第一部分是直接分析源数据的表结构，这样就不需要处理整个树形结构；第二部分是将树形结构手动拆分为多个并行部分，从而实现并行化处理。
通过这种方式，我们能够对表分区和关联分区进行拆分，并进行关联分析。同时，我们还能观察到数据的整体冷热分布，以及后续一段时间内的增长趋势。基于这些信息，我们利用规则引擎做出决策，确定关键目标。例如，如果当前存储的健康状况良好，但成本健康分较低，我们可能会自动执行降冷操作。如果发现整个系统的扩容必要性较高，我们可能会进行柔性扩容或自动剔除操作。
AI 驱动的 SparkSql 调优全自治域
接下来分享一个关于 Spark 自动调优的案例。这个想法最初是在项目立项时提出的，当时的想法非常直接：将 Spark 的所有相关信息，包括 SparkSQL、配置信息、上下文信息，以及存储和引擎等，全部整合到一个系统中。我们甚至将所有的 Executor、逻辑计划和物理计划等也纳入其中。初步测试结果显示，这种方法的准确率大约为 30%。然而，我们发现其中约 30% 的结果与实际需求并无相关性，还有 20% 到 40% 的结果存在明显问题。究其原因，通用的大模型缺乏专家级的领域知识，这导致了准确性的不足，同时还出现了幻觉问题。所以我们引入了贝叶斯和 RL 专家系统建议的优化提升 sparksql 的调优效果。在 POC 和线上，目前实现无人工值守自治调优性能效果比工作五年经验还好 10%。
在降本效果相当不错，之前主要关注的 SparkSQL 本身，没有考虑存储和 IaaS 层面的相关影响。在最近我们又升级了这个系统，会将 YARN 调度、HDFS 存储以及相关的管控日志等信息统一汇总，形成一个详细的概述。我们的目标是通过调优实现时间消耗的最优化。为此，我们将这些上下文信息输入模型，并进行在线分析。分析结果不仅包括计算相关的最优参数，还涵盖了调度配置、内核参数的配置下发等。然而，这些配置下发后并不能立即生效，可能需要执行 SQL 控制操作，或者在某些情况下，进行刷新操作。基于这些分析结果，我们会生成一个调参执行计划，然后重新提交任务，并对时间消耗的最优化和系统的整体健康度进行评估。
后续发展和思考
目前我们在自治虽然有些突破，但还远远不够。正如之前提到的，我们已经解决了关键的 10% 的知识问题，这确实帮助我们解决了许多难题。然而，我们还有许多需要思考和改进的地方。
首先，我们需要持续优化路径。以 SparkSQL 为例，虽然我们已经对 SQL 进行了优化，但关键信息之间的互联性仍然不足。例如，当我们直接将 HDFS 的最大存储容量纳入考量时，其时间和空间的关联性处理得并不理想。目前，我们主要依赖简单的专家系统来判断优化效果，而这种判断往往缺乏系统化的分析。因此，我们计划在未来持续加强这方面的建设。
其次，我们在决策时的目标相对单一。目前，我们的决策主要基于时间预测和健康分的调度，但对于复杂的大数据系统来说，多链路决策的完善性仍有待提高。例如，在关键决策时刻，我们会引入多智能体。目前，我们对决策准确性的把握还不够高，准确率可能只有 70% 到 80%。因此，我们需要持续优化决策过程，以提高准确率。
最后，关于专家系统，虽然我们在最后一步会强制让 SRE 专家介入，但在实际操作中，我们发现专家介入的时机和方式需要进一步优化。例如，在配置下发后，我们可能需要再次介入，因为有些系统配置是立即生效的，而有些则需要存储后才能生效。因此，我们需要在关键节点上进行更精准的知识干预。
除了上述问题，我个人以及我们团队还需要持续思考和探索后续的应用方向。首先是 agent-Drive 的根因定位（RCA）。我们在故障恢复和根因定位方面还有很大的提升空间。一方面，我们需要更快地响应问题，避免客户受到影响；另一方面，我们需要提高根因分析的效率。
其次，我们希望实现逐步缓解的操作。目前，我们的操作通常是直接针对目标进行的，但我们认为应该分阶段、分层次地观察和评估每个环节的动作是否对整体健康服务和知识系统有效。虽然我们已经有了一个反应式（Reactive）模型，但它主要集中在直接缓解问题上。我们希望通过逐步缓解的方式，更全面地评估和优化系统。
最后，安全性是我们需要持续关注的一个重要方向。在大模型 RL 或智能体的开发过程中，我们可能会面临各种安全风险。一方面，我们需要确保优化操作不会引入更大的问题；另一方面，由于多个团队之间可能共享知识库，我们需要防止信息泄露或因幻觉问题导致其他团队误读知识库信息。这将是我们在未来持续探索的方向。
嘉宾介绍
熊训德，腾讯专家工程师，腾讯云 EMR 技术负责人，有丰富的大数据领域系统架构、开发、专家系统调优经验。
会议推荐
复杂任务，不再主要依赖冗长提示词硬扛了。Agent Skills 将专家流程与工具能力封装为可复用数字技能，由大模型按需调用，推动 AI 从通用助手迈向稳定的专业执行体。围绕 Skills 平台化、模型推理增强与垂直场景落地，Agent 时代正在加速到来。
为了深入探讨 Agent Skills 在实际应用中的潜力与挑战，在 4 月 16 日 -18 日举办的 QCon 北京大会上，我们特别邀请了 Ubiquiti Quality Assurance 蔡明哲带来专题演讲《从单点辅助到 Agent 闭环：基于 Agent Skills、MCP 与 Playwright 的全链路智能化测试实践》。他将聚焦智能化测试在质量保证中的落地实践，详细拆解 Agent Skills、Playwright Agent 与 MCP 的职责分工与组合范式，并介绍如何从案例生成到自动修复实现全流程工程实践落地。
