演講嘉賓｜熊訓(xùn)德

編輯｜Kitty

策劃｜QCon 全球軟件開發(fā)大會

在大數(shù)據(jù)平臺高速發(fā)展的當下，生態(tài)擴張與業(yè)務(wù)量激增，致使大數(shù)據(jù)分布式組件問題愈發(fā)棘手，傳統(tǒng)專家運維模式捉襟見肘。以騰訊大數(shù)據(jù)龐大的規(guī)模為例，面對海量計算單元、繁雜技術(shù)棧以及千萬級任務(wù)管理，借助 AI 驅(qū)動實現(xiàn)大數(shù)據(jù)系統(tǒng)的故障和問題的快速洞察與自治能力，已成為行業(yè)迫切需求。

在 InfoQ 舉辦的 QCon 全球軟件開發(fā)大會（北京站）上，騰訊專家工程師熊訓(xùn)德做了專題演講“AI 驅(qū)動的大數(shù)據(jù)自治：智能應(yīng)對復(fù)雜運維挑戰(zhàn)”，他介紹了如何通過可拔插的決策引擎、以及數(shù)據(jù)專家自治智能體構(gòu)建大數(shù)據(jù)智能管家，讓企業(yè)能夠理解如何高效、智能地處理復(fù)雜的運維場景，從而大幅提升大數(shù)據(jù)場景下運維效率與準確性，引領(lǐng)大數(shù)據(jù)線上系統(tǒng)邁向全面自治的實踐。

以下是演講實錄（經(jīng) InfoQ 進行不改變原意的編輯整理）。

大數(shù)據(jù)系統(tǒng)自治背景與挑戰(zhàn)

首先，我簡要介紹一下整個大數(shù)據(jù)系統(tǒng)，以及其在自治背景下的相關(guān)挑戰(zhàn)。大數(shù)據(jù)系統(tǒng)本身組件眾多，涵蓋了從底層的 IaaS，到存儲、計算框架，以及上層的工具層等多個層面。具體來說，IaaS 層面涉及到機器本身的網(wǎng)絡(luò)和性能，而存儲層則包括分布式文件系統(tǒng)（如 HDFS）和對象存儲等。在調(diào)度方面，我們有 Kubernetes 和 Hadoop- 體系，以及針對 AI 方面的特定調(diào)度機制。再往上一層則是計算框架，例如 Spark 和 Flink 等流計算框架。最上層則是各種工具，這些工具在不同方面的使用都使得整個大數(shù)據(jù)系統(tǒng)的復(fù)雜性顯著增加。

大數(shù)據(jù)系統(tǒng)本質(zhì)上是一個分布式系統(tǒng)。如果單機系統(tǒng)已經(jīng)如此復(fù)雜，那么分布式系統(tǒng)則需要考慮數(shù)據(jù)的溯源以及在不同機器上的分布情況，無論是主從結(jié)構(gòu)（master 和 slave）還是多工作節(jié)點（worker）的協(xié)作模式，都會使得整個系統(tǒng)在處理問題、查找根源以及故障恢復(fù)時變得極為困難。此外，大數(shù)據(jù)系統(tǒng)的數(shù)據(jù)處理鏈路通常非常長。例如，數(shù)據(jù)采集可能來源于多種源頭，如代理（Agent）、MySQL 數(shù)據(jù)庫，或者在物聯(lián)網(wǎng)場景下，可能是汽車或傳感器等設(shè)備。采集到的數(shù)據(jù)需要通過數(shù)據(jù)接入層，目前常見的架構(gòu)包括 Kafka 或其他消息隊。接入后，數(shù)據(jù)會進入計算階段，可能是實時計算（如 Flink）或離線計算（如 Spark）。計算完成后，數(shù)據(jù)需要存儲到 HDFS 系統(tǒng)或?qū)ο蟠鎯χ?。最后，在?shù)據(jù)應(yīng)用層面，我們可能需要進行預(yù)處理以供 AI 使用，進行訓(xùn)練或推理工作，或者生成商業(yè)智能 BI 報表。因此，整個數(shù)據(jù)鏈路非常長，這也使得我們在進行故障根因分析或自治處理時，需要綜合考慮所有相關(guān)場景。

當我們處理大數(shù)據(jù)故障時，業(yè)務(wù)部門或客戶往往會提出一個關(guān)鍵問題：“何時能夠恢復(fù)？能否實現(xiàn)自動恢復(fù)，以盡快減少損失？”然而，我們在進行故障恢復(fù)或診斷時，高度依賴于運維 SRE 的專家經(jīng)驗。通常情況下，如果沒有三年以上的大數(shù)據(jù)運維經(jīng)驗，很難有效且完善地處理復(fù)雜的大數(shù)據(jù)故障。此外，由于整個診斷和故障恢復(fù)的時間鏈路非常長，導(dǎo)致整體效率低下。更糟糕的是，故障可能已經(jīng)結(jié)束，而我們只能進行事后處理，此時大數(shù)據(jù)系統(tǒng)可能已經(jīng)遭受了實際的損失。

大數(shù)據(jù)智能管家技術(shù)框架及
關(guān)鍵實現(xiàn)路徑

騰訊大數(shù)據(jù)智能管家 TCInsight 技術(shù)架構(gòu)

基于這些背景，我們團隊在大約五年前提出了構(gòu)建大數(shù)據(jù)智能管家 TCInsight 的想法，致力于解決大數(shù)據(jù)系統(tǒng)自治相關(guān)的工作。我們的大數(shù)據(jù)智能管家整體技術(shù)架構(gòu)分為三層。

第一層是觀測層。它主要負責監(jiān)控基礎(chǔ)設(shè)施即服務(wù)（IaaS），包括主機網(wǎng)絡(luò)等的監(jiān)控數(shù)據(jù)，同時采集日志和關(guān)鍵事件。我們還將大數(shù)據(jù)組件，如 HDFS、Spark、Hive 和 YARN 等的關(guān)鍵監(jiān)控日志事件進行統(tǒng)一上報。

第二層是服務(wù)分析層，主要負責數(shù)據(jù)實時處理和算法決策洞察。服務(wù)分析層分為三個部分。第一部分是實時分析，主要目的是快速處理數(shù)據(jù)，包括異常收斂。例如，當事件或告警過多時，我們需要迅速整合，否則會給運維 SRE 或研發(fā)人員帶來較大挑戰(zhàn)。我們會對數(shù)據(jù)進行基礎(chǔ)預(yù)處理。第二部分是離線服務(wù)，主要用于根因分析或自治服務(wù)時的離線分析和定時巡檢。在數(shù)據(jù)量較大時，離線分析尤為重要。第三部分是算法決策，主要涉及模型和算法庫的分析，以及知識庫和評測庫的建設(shè)，還包括離線訓(xùn)練等工作。

第三層是應(yīng)用層，主要負責大數(shù)據(jù)運維自治，并對外提供接口。應(yīng)用層分為兩大塊：自治修復(fù)和自治決策。例如，以 Hive 為例，當業(yè)務(wù)側(cè)編寫了一個 SQL 查詢，可能會導(dǎo)致 HDFS 存儲空間被占滿，從而影響其他任務(wù)的提交。此時，我們需要快速對該 SQL 進行限制，或者在業(yè)務(wù)非常關(guān)鍵且不能直接終止的情況下，預(yù)測可能得存儲和計算量，進行自助彈性伸縮。此外，我們還需要進行冷熱數(shù)據(jù)分離，以實現(xiàn)成本分析和自助轉(zhuǎn)冷操作。在自治決策方面，我們需要判斷是否進行參數(shù)調(diào)優(yōu)，因為某些參數(shù)調(diào)整可能需要重啟系統(tǒng)才能生效，這可能會擴大故障范圍。此時，我們需要做出關(guān)鍵決策，例如選擇擴容，或者讓 AI 參與具體工作。我們還可以進行錯峰執(zhí)行，例如在 YARN 的多個隊列中，調(diào)整隊列的執(zhí)行時間，以優(yōu)化資源分配。

應(yīng)用層還包括業(yè)務(wù)洞察部分，主要用于預(yù)測分析、成本分析和根因分析等工作。這些工作相對滯后，我們的目標是先恢復(fù)系統(tǒng)，然后再進行深入分析。此外，我們還會生成巡檢報表，并進行一鍵健康評估。健康評估在我們的系統(tǒng)中非常重要，它綜合評估了 IaaS、存儲、調(diào)度和計算等各個部分的健康狀況，為關(guān)鍵自治決策提供依據(jù)。

在架構(gòu)的中間部分是我們的算法或引擎層。引擎分為兩部分：規(guī)則引擎和我們自主研發(fā)的元啟引擎。元啟引擎結(jié)合了 AI 算法和我們內(nèi)部的混元大模型。規(guī)則引擎主要用于執(zhí)行明確的操作，例如擴容，以緩解問題。對于復(fù)雜或關(guān)聯(lián)性較高的場景，我們會接入算法或大模型，以提升系統(tǒng)的健康狀況。

接下來，我會詳細說明我們在大數(shù)據(jù)智能管家過程中的一些關(guān)鍵思考和實現(xiàn)能力。

分層的大數(shù)據(jù)運維框架 - 漸進式自治

由于大數(shù)據(jù)體系的復(fù)雜性，TCInsight 實現(xiàn)自治的是一個漸進式的過程。當我們接手一個系統(tǒng)時，不能期望所有大數(shù)據(jù)運維工作能夠立即實現(xiàn)完全自治。實際上，我們基于一個較為普遍的理念：在沒有一線專家或?qū)I(yè)人才的情況下，一線人員或客戶也能夠?qū)崿F(xiàn)自治處理。

我們根據(jù)問題的復(fù)雜程度進行分類處理：對于簡單重復(fù)且解決方案確定問題，我們直接采用 AI 驅(qū)動的方式進行處理。目前，這類問題大約占我們總問題的 10% 左右。然而，剩下的 90% 問題尚未能完全實現(xiàn)自治。對于這部分問題，我們希望通過售后體系中的專項人員和 SRE 的共同努力，借助我們之前提到的平臺層，利用大模型和 AI 增強能力，持續(xù)為系統(tǒng)提供支持。

在此基礎(chǔ)上，我們期望通過三年以上經(jīng)驗的產(chǎn)研人員或 SRE 專家，進一步強化知識庫和工具建設(shè)。通過這種逐步積累和優(yōu)化我們的產(chǎn)品能力，我們希望能夠逐步提高自治的比例，最終使其達到 90% 以上。

多智能決策引擎思考和設(shè)計一問題域

在業(yè)界，主要有三種常見的方法：顯式編程、基于優(yōu)化方法的處理以及專家系統(tǒng)。第一種顯式編程對于研發(fā)人員來說并不陌生，它本質(zhì)上是通過編寫規(guī)則或工作流來構(gòu)建一個簡單的規(guī)則引擎，從而實現(xiàn)直接的決策。例如，當存儲使用率超過 75% 時，系統(tǒng)自動觸發(fā)擴容操作。這種方法簡單直接，但靈活性有限。

第二種是基于優(yōu)化方法的處理。在大模型尚未普及的時代，我們通過優(yōu)化模型來提升系統(tǒng)性能。例如，原本只能優(yōu)化 40% 的系統(tǒng)，通過采用貪婪算法或聚合模型等技術(shù)，可以將其優(yōu)化效果提升至 80% 以上。這種方法更多地依賴于深度學習和大模型的強大能力，能夠更好地處理復(fù)雜的優(yōu)化問題。

第三種是智能全自治域系統(tǒng)。全自治域系統(tǒng)的核心在于利用專家的經(jīng)驗和知識，盡管專家人數(shù)有限，但他們的經(jīng)驗可以通過系統(tǒng)化的方式賦予平臺更強的能力。專家系統(tǒng)的關(guān)鍵在于如何將專家的經(jīng)驗轉(zhuǎn)化為可操作的決策邏輯。

在明確了這些決策引擎的技術(shù)路徑后，我們進一步思考了在大數(shù)據(jù)領(lǐng)域構(gòu)建智能決策系統(tǒng)的關(guān)鍵問題。首先，數(shù)據(jù)的可用性至關(guān)重要。無論是基于 AI 的訓(xùn)練還是大模型的應(yīng)用，數(shù)據(jù)標注的準確性和完整性是基礎(chǔ)。如果數(shù)據(jù)標注不足，可能會導(dǎo)致模型出現(xiàn)幻讀甚至錯誤的輸出，從而影響決策的準確性。

其次，系統(tǒng)的可解釋性也是一個關(guān)鍵問題。專家和文檔作者需要確保知識庫中的內(nèi)容不僅系統(tǒng)能夠理解，而且一線人員和客戶也能夠輕松掌握。這一點直接關(guān)系到?jīng)Q策的準確性和適用范圍。

最后，實時性要求也不容忽視。我們的目標是先快速恢復(fù)系統(tǒng)，后續(xù)再進行深入分析。這就要求決策過程和最終的行動必須足夠迅速，以滿足實時性的需求。

綜合考慮以上因素，在決策引擎的選擇上，我們決定結(jié)合規(guī)則引擎和專家系統(tǒng)的智能決策引擎共同構(gòu)建了全自治域系統(tǒng) TCInsight。這種方法既能夠利用規(guī)則的明確性和可操作性，又能借助專家系統(tǒng)的靈活性和經(jīng)驗優(yōu)勢，逐步提升系統(tǒng)的自治能力和決策準確性。

Al 驅(qū)動的規(guī)則引擎自治系統(tǒng)

在構(gòu)建基于規(guī)則引擎的知識系統(tǒng)時，我們首先對系統(tǒng)中的各類數(shù)據(jù)進行了統(tǒng)一管理。這些數(shù)據(jù)包括指標（metrics）、日志（log）以及事件（event），我們會將它們統(tǒng)一上報至我們內(nèi)部構(gòu)建的數(shù)據(jù)庫適配系統(tǒng)。該系統(tǒng)是基于 Inpara 和 Flink 構(gòu)建的，數(shù)據(jù)最終會被存儲到時序數(shù)據(jù)庫中。隨后，我們利用 Flink 對數(shù)據(jù)進行預(yù)處理，并結(jié)合訓(xùn)練好的模型以及特征庫，對數(shù)據(jù)進行特征分析?；谶@些分析，我們會進行基礎(chǔ)的異常檢測、關(guān)聯(lián)分析以及趨勢預(yù)測等工作，從而形成初步的告警摘要和預(yù)測摘要。

例如，我們可能會收到告警信息，提示 HDFS 存儲空間即將用盡，或者 YARN 隊列的等待時間過長，又或者 StarRocks 或 Trino 的 CPU 占用率過高，某個 SQL 查詢掃描的數(shù)據(jù)量過大，超出了設(shè)定的閾值。基于這些信息，我們會生成整體的告警或預(yù)測摘要。如果預(yù)測顯示 HDFS 的增長趨勢過快，可能會在 5 分鐘內(nèi)被填滿，我們就會對 IaaS、存儲、引擎和調(diào)度等各個層面進行評估，計算它們的健康分數(shù)。如果健康分數(shù)低于某個閾值，或者即將達到該閾值，我們就會啟動規(guī)則引擎進行處理。例如，我們可能會嘗試簡單的擴容操作來緩解問題，或者在業(yè)務(wù)允許的情況下，直接終止一些不關(guān)鍵的 SQL 查詢或任務(wù)，以減少資源占用。

在執(zhí)行這些操作后，我們會制定一個詳細的執(zhí)行計劃。以擴容為例，在執(zhí)行擴容操作之前，我們需要先檢查 HDFS 的整體狀態(tài)是否正常，數(shù)據(jù)是否均衡分布，以及 NameNode 和 DataNode 之間的流量是否穩(wěn)定。因為如果流量過大，可能會導(dǎo)致 DataNode 負載過高，甚至引發(fā)更嚴重的問題。只有在確認一切正常后，我們才會通過 IaaS 層擴容機器，并在擴容完成后進行數(shù)據(jù)均衡操作，以確保系統(tǒng)恢復(fù)正常。

完成這些操作后，我們會記錄整個過程的狀態(tài)，并進行反饋。如果擴容后監(jiān)控數(shù)據(jù)顯示系統(tǒng)恢復(fù)正常，那么我們認為這次自治決策是成功的，并將結(jié)果記錄下來作為后續(xù)處理的參考。然而，如果擴容后情況反而惡化，例如數(shù)據(jù)傾斜導(dǎo)致 SQL 查詢速度變慢，引擎?zhèn)鹊慕】捣謹?shù)急劇下降，那么我們會緊急通知專家介入，重新審查整個分析過程。

這種基于規(guī)則引擎的處理方式具有高效和準確的特點。目前，在我們系統(tǒng)中，基礎(chǔ)指標的覆蓋率達到 90%，存儲場景的覆蓋率為 50%，任務(wù)場景的覆蓋率為 30%。在周期性任務(wù)的處理上，我們已經(jīng)能夠覆蓋 90% 的場景。在異常診斷方面，我們能夠處理 70% 的異常場景，整體數(shù)據(jù)表現(xiàn)良好。

這并不意味著我們的工作已經(jīng)完成。實際上，大數(shù)據(jù)系統(tǒng)的復(fù)雜性遠超我們的預(yù)期。例如，我們在兩年前曾遇到一個問題：在對 HDFS 進行擴容后，發(fā)現(xiàn)數(shù)據(jù)分布不均衡，導(dǎo)致 Spark 任務(wù)的執(zhí)行速度反而變慢。從常理來看，擴容后資源增加，任務(wù)執(zhí)行速度應(yīng)該加快，但實際上并非如此。原因在于擴容后數(shù)據(jù)的均衡性并沒有達到預(yù)期，同時業(yè)務(wù)側(cè)提交了大量任務(wù)，導(dǎo)致系統(tǒng)整體性能下降。這說明我們目前只能處理已知的情況，而對于一些未考慮到的復(fù)雜場景，我們還需要進一步優(yōu)化和改進。

Al 驅(qū)動的全自治域系統(tǒng)

基于上述思考，我們提出了一個全新的全自治系統(tǒng)概念。與之前的方法不同，我們在決策過程中引入了大模型的相關(guān)分析。無論是當前備受關(guān)注的 DeepSeek，還是此前我們接觸過的其他類似模型，其核心優(yōu)勢在于執(zhí)行步驟和推理能力。因此，我們開始嘗試將大模型的相關(guān)功能融入整個自治決策系統(tǒng)中。

在預(yù)測和分析階段，系統(tǒng)仍然會進行數(shù)據(jù)預(yù)處理和特征分析，并開展異常檢測、關(guān)聯(lián)分析以及趨勢預(yù)測等工作。這些信息匯總后，會生成初步的概述信息。然而，與以往不同的是，由于引入了大模型，我們需要構(gòu)建一個“優(yōu)先級與目標系統(tǒng)”（以下簡稱“目標系統(tǒng)”）。我們會在這個目標系統(tǒng)中預(yù)先定義優(yōu)先級和目標。例如，對于存儲系統(tǒng)，我們設(shè)定存儲使用率不得超過 80%，并且數(shù)據(jù)不能快速轉(zhuǎn)冷；對于引擎，我們希望優(yōu)化其執(zhí)行時間；對于上層應(yīng)用，我們要求其不能出現(xiàn)錯誤。這些優(yōu)先級和目標會被配置到目標系統(tǒng)中，生成診斷建議。

隨后，我們會將這些數(shù)據(jù)輸入到混元模型中，并結(jié)合我們之前的決策分析結(jié)果，生成具體的執(zhí)行步驟。這些執(zhí)行步驟融合了傳統(tǒng)執(zhí)行引擎、規(guī)則引擎以及傳統(tǒng)深度學習算法或基礎(chǔ)算法的執(zhí)行計劃。執(zhí)行計劃生成后，我們會重新預(yù)檢測系統(tǒng)狀態(tài)，重新評估預(yù)測分析結(jié)果以及執(zhí)行計劃可能帶來的狀態(tài)變化。

如果發(fā)現(xiàn)執(zhí)行該計劃后系統(tǒng)健康分數(shù)可能更低，即情況可能惡化，那么我們的專家團隊會介入。我們會創(chuàng)建一個專家工單，讓專家對執(zhí)行計劃進行評估，并決定是否停止執(zhí)行。相反，如果預(yù)測和狀態(tài)評估顯示執(zhí)行計劃后系統(tǒng)健康分數(shù)將高于目標值，那么我們會執(zhí)行該計劃，并將執(zhí)行計劃標記后存入知識庫。

執(zhí)行完成后，我們會繼續(xù)進行預(yù)測分析、異常檢測以及整體狀態(tài)評估。如果系統(tǒng)健康度如我們預(yù)測的那樣有所提升，我們會重新進行標記和分析，以便系統(tǒng)能夠繼續(xù)執(zhí)行后續(xù)操作。

數(shù)據(jù)質(zhì)量對預(yù)測影響 & 優(yōu)化

在構(gòu)建整個系統(tǒng)的過程中，我們花費了大量時間進行調(diào)試，尤其是在系統(tǒng)上線試運行階段?，F(xiàn)在，我想重點介紹一下我們在調(diào)試過程中采取的關(guān)鍵措施，這些措施讓系統(tǒng)更加穩(wěn)定，并顯著提高了預(yù)測的準確率。

對于從事時序預(yù)測研究的人員來說，一個常見的問題是如何處理上報數(shù)據(jù)中的斷點。這種情況可能由多種原因引起。例如，當系統(tǒng)發(fā)生故障時，機器的 CPU 或內(nèi)存可能已經(jīng)滿負荷運行，導(dǎo)致在關(guān)鍵時刻數(shù)據(jù)丟失。在分布式系統(tǒng)中，這種數(shù)據(jù)丟失可能會引發(fā)上層系統(tǒng)的亂序操作。假設(shè)我們上報的時間是 12 點整，但由于長時間的內(nèi)存不足（OOM）或 CPU 負載過高，數(shù)據(jù)可能直到 12 點零 5 秒甚至 12 點零 1 分才上報。然而，故障的實際發(fā)生時間并非 12 點零 1 分，但上報時間卻顯示為 12 點零 1 分，這就導(dǎo)致了數(shù)據(jù)的亂序問題。此外，還可能出現(xiàn)重復(fù)上報的情況，即同一條日志或指標連續(xù)上報多次，這使得我們難以確定真正的時間點或事件。

這些問題引發(fā)了幾個關(guān)鍵的挑戰(zhàn)。首先，當數(shù)據(jù)出現(xiàn)斷點時，我們需要決定是否進行插值。目前業(yè)界常用的算法包括直接丟棄數(shù)據(jù)或采用簡單的插值方法。對于故障場景來說，直接丟棄數(shù)據(jù)可能并不是一個好方法，因為這些數(shù)據(jù)代表了當時關(guān)鍵的監(jiān)控指標。即使進行插值，如果處理不當，也可能導(dǎo)致數(shù)據(jù)不準確。此外，如果數(shù)據(jù)質(zhì)量不佳，將嚴重影響我們的預(yù)測能力和關(guān)鍵異常處理能力。

我們重點對數(shù)據(jù)質(zhì)量進行了優(yōu)化，主要從三個方面入手。首先，我們對時序指標或日志的有效性進行評估。以往最簡單的評估方式是檢查數(shù)據(jù)是否超過完整性閾值。另一種常見的做法是檢查數(shù)據(jù)是否滿足差分閾值，或者在 IoT、時序場景中直接進行簡單的拼湊。我們提出了一種基于完整性的實際評估方法。具體來說，我們將每個數(shù)據(jù)進行分段處理，然后基于自回歸模型對每個分段進行評估檢測。如果數(shù)據(jù)通過了自回歸分析的評估，我們認為這些數(shù)據(jù)是可用的。

在確認數(shù)據(jù)可用之后，我們面臨的另一個問題是數(shù)據(jù)的補齊和連接。目前常用的方法包括直接進行差分或簡單的拼接。我們的思路是采用自回歸預(yù)測和自回歸拼接的方法。這種方法的優(yōu)勢在于處理速度快，能夠快速對分段數(shù)據(jù)進行處理。此外，這種方法既能進行預(yù)測，又能完成數(shù)據(jù)合并操作。通過這種方法，我們顯著提升了數(shù)據(jù)的有效性，整體提升了 10%。在周期性任務(wù)和異常診斷方面，準確性提高了 30% 以上。同時，時序預(yù)測的時間也縮短了 28%。

我們在構(gòu)建大數(shù)據(jù)專家?guī)熘悄荏w的過程中，嘗試了一種與業(yè)界常見的做法略有不同的方案。我們不僅實現(xiàn)了向量檢索，還引入了文本檢索。這種設(shè)計的選擇源于我們在構(gòu)建知識庫時對傳統(tǒng)向量檢索方法的深入思考。

傳統(tǒng)向量檢索在相關(guān)性分析方面表現(xiàn)出色，例如在使用 FastText 等工具時，能夠快速識別出與查詢相關(guān)的數(shù)據(jù)。然而，這種方法存在一個明顯的局限性：它無法直接反映召回數(shù)據(jù)的質(zhì)量，也就是說，在檢索過程中，我們難以預(yù)估數(shù)據(jù)的相關(guān)性是否真正符合需求。為了解決這一問題，我們引入了文本檢索機制。通過文本檢索，我們能夠更清晰地理解數(shù)據(jù)之間的關(guān)聯(lián)性，尤其是在知識庫的構(gòu)建過程中。

當我們構(gòu)建知識庫時，一個常見的思路是將操作步驟進行分層。以擴容操作為例，它可能與存儲層有很強的相關(guān)性，但這種相關(guān)性背后的原因并不明確。通過文本檢索，我們可以補充這些缺失的上下文信息，從而更全面地理解數(shù)據(jù)之間的關(guān)系。

大數(shù)據(jù)系統(tǒng)通常分為多層，包括大數(shù)據(jù)存儲層、調(diào)度、和引擎等等。這些層之間的相關(guān)性可能很強，但它們之間的索引空間檢索范圍并不像我們想象的那么大?；谶@些考慮，我們采用了騰訊的 ES 的架構(gòu)，結(jié)合文本分析和向量檢索的優(yōu)勢。這種架構(gòu)不僅支持大規(guī)模的讀寫操作，還具備高效的檢索能力。

通過這種方式，我們能夠更好地處理組件之間或分層之間的關(guān)聯(lián)關(guān)系，使得各部分之間的距離更近，從而提高系統(tǒng)的整體效率。在故障恢復(fù)之后，除了通過冷啟動將知識庫連接起來，我們還利用工單系統(tǒng)、客戶反饋和專家系統(tǒng)，結(jié)合混元大模型，實現(xiàn)自動化的分類和歸納，持續(xù)完善知識庫的建設(shè)。

實踐效果與案例分享

A 驅(qū)動的 HDFS 存儲規(guī)則引擎自治

我們來看基于 HDFS 存儲規(guī)則引擎的自治。這里的關(guān)鍵在于如何快速抽取和分析 HDFS 的 FSImage，以及如何準確把握特征點。我們知道，HDFS 的源數(shù)據(jù)是以樹形結(jié)構(gòu)存儲的，而現(xiàn)有的工具無法對這種樹形結(jié)構(gòu)進行并行化處理。為了解決這個問題，我們將工作拆分為兩部分：第一部分是直接分析源數(shù)據(jù)的表結(jié)構(gòu)，這樣就不需要處理整個樹形結(jié)構(gòu)；第二部分是將樹形結(jié)構(gòu)手動拆分為多個并行部分，從而實現(xiàn)并行化處理。

通過這種方式，我們能夠?qū)Ρ矸謪^(qū)和關(guān)聯(lián)分區(qū)進行拆分，并進行關(guān)聯(lián)分析。同時，我們還能觀察到數(shù)據(jù)的整體冷熱分布，以及后續(xù)一段時間內(nèi)的增長趨勢?；谶@些信息，我們利用規(guī)則引擎做出決策，確定關(guān)鍵目標。例如，如果當前存儲的健康狀況良好，但成本健康分較低，我們可能會自動執(zhí)行降冷操作。如果發(fā)現(xiàn)整個系統(tǒng)的擴容必要性較高，我們可能會進行柔性擴容或自動剔除操作。

A 驅(qū)動的 SparkSql 調(diào)優(yōu)全自治域

接下來分享一個關(guān)于 Spark 自動調(diào)優(yōu)的案例。這個想法最初是在項目立項時提出的，當時的想法非常直接：將 Spark 的所有相關(guān)信息，包括 SparkSQL、配置信息、上下文信息，以及存儲和引擎等，全部整合到一個系統(tǒng)中。我們甚至將所有的 Executor、邏輯計劃和物理計劃等也納入其中。初步測試結(jié)果顯示，這種方法的準確率大約為 30%。然而，我們發(fā)現(xiàn)其中約 30% 的結(jié)果與實際需求并無相關(guān)性，還有 20% 到 40% 的結(jié)果存在明顯問題。究其原因，通用的大模型缺乏專家級的領(lǐng)域知識，這導(dǎo)致了準確性的不足，同時還出現(xiàn)了幻覺問題。所以我們引入了貝葉斯和 RL 專家系統(tǒng)建議的優(yōu)化提升 sparksql 的調(diào)優(yōu)效果。在 POC 和線上，目前實現(xiàn)無人工值守自治調(diào)優(yōu)性能效果比工作五年經(jīng)驗還好 10%。

在降本效果相當不錯，之前主要關(guān)注的 SparkSQL 本身，沒有考慮存儲和 IaaS 層面的相關(guān)影響。在最近我們又升級了這個系統(tǒng)，會將 YARN 調(diào)度、HDFS 存儲以及相關(guān)的管控日志等信息統(tǒng)一匯總，形成一個詳細的概述。我們的目標是通過調(diào)優(yōu)實現(xiàn)時間消耗的最優(yōu)化。為此，我們將這些上下文信息輸入模型，并進行在線分析。分析結(jié)果不僅包括計算相關(guān)的最優(yōu)參數(shù)，還涵蓋了調(diào)度配置、內(nèi)核參數(shù)的配置下發(fā)等。然而，這些配置下發(fā)后并不能立即生效，可能需要執(zhí)行 SQL 控制操作，或者在某些情況下，進行刷新操作?；谶@些分析結(jié)果，我們會生成一個調(diào)參執(zhí)行計劃，然后重新提交任務(wù)，并對時間消耗的最優(yōu)化和系統(tǒng)的整體健康度進行評估。

后續(xù)發(fā)展和思考

目前我們在自治雖然有些突破，但還遠遠不夠。正如之前提到的，我們已經(jīng)解決了關(guān)鍵的 10% 的知識問題，這確實幫助我們解決了許多難題。然而，我們還有許多需要思考和改進的地方。

首先，我們需要持續(xù)優(yōu)化路徑。以 SparkSQL 為例，雖然我們已經(jīng)對 SQL 進行了優(yōu)化，但關(guān)鍵信息之間的互聯(lián)性仍然不足。例如，當我們直接將 HDFS 的最大存儲容量納入考量時，其時間和空間的關(guān)聯(lián)性處理得并不理想。目前，我們主要依賴簡單的專家系統(tǒng)來判斷優(yōu)化效果，而這種判斷往往缺乏系統(tǒng)化的分析。因此，我們計劃在未來持續(xù)加強這方面的建設(shè)。

其次，我們在決策時的目標相對單一。目前，我們的決策主要基于時間預(yù)測和健康分的調(diào)度，但對于復(fù)雜的大數(shù)據(jù)系統(tǒng)來說，多鏈路決策的完善性仍有待提高。例如，在關(guān)鍵決策時刻，我們會引入多智能體。目前，我們對決策準確性的把握還不夠高，準確率可能只有 70% 到 80%。因此，我們需要持續(xù)優(yōu)化決策過程，以提高準確率。

最后，關(guān)于專家系統(tǒng)，雖然我們在最后一步會強制讓 SRE 專家介入，但在實際操作中，我們發(fā)現(xiàn)專家介入的時機和方式需要進一步優(yōu)化。例如，在配置下發(fā)后，我們可能需要再次介入，因為有些系統(tǒng)配置是立即生效的，而有些則需要存儲后才能生效。因此，我們需要在關(guān)鍵節(jié)點上進行更精準的知識干預(yù)。

除了上述問題，我個人以及我們團隊還需要持續(xù)思考和探索后續(xù)的應(yīng)用方向。首先是 agent-Drive 的根因定位（RCA）。我們在故障恢復(fù)和根因定位方面還有很大的提升空間。一方面，我們需要更快地響應(yīng)問題，避免客戶受到影響；另一方面，我們需要提高根因分析的效率。

其次，我們希望實現(xiàn)逐步緩解的操作。目前，我們的操作通常是直接針對目標進行的，但我們認為應(yīng)該分階段、分層次地觀察和評估每個環(huán)節(jié)的動作是否對整體健康服務(wù)和知識系統(tǒng)有效。雖然我們已經(jīng)有了一個反應(yīng)式（Reactive）模型，但它主要集中在直接緩解問題上。我們希望通過逐步緩解的方式，更全面地評估和優(yōu)化系統(tǒng)。

最后，安全性是我們需要持續(xù)關(guān)注的一個重要方向。在大模型 RL 或智能體的開發(fā)過程中，我們可能會面臨各種安全風險。一方面，我們需要確保優(yōu)化操作不會引入更大的問題；另一方面，由于多個團隊之間可能共享知識庫，我們需要防止信息泄露或因幻覺問題導(dǎo)致其他團隊誤讀知識庫信息。這將是我們在未來持續(xù)探索的方向。

嘉賓介紹

熊訓(xùn)德，騰訊專家工程師，騰訊云 EMR 技術(shù)負責人，有豐富的大數(shù)據(jù)領(lǐng)域系統(tǒng)架構(gòu)、開發(fā)、專家系統(tǒng)調(diào)優(yōu)經(jīng)驗。

會議推薦

復(fù)雜任務(wù)，不再主要依賴冗長提示詞硬扛了。Agent Skills 將專家流程與工具能力封裝為可復(fù)用數(shù)字技能，由大模型按需調(diào)用，推動 AI 從通用助手邁向穩(wěn)定的專業(yè)執(zhí)行體。圍繞 Skills 平臺化、模型推理增強與垂直場景落地，Agent 時代正在加速到來。

為了深入探討 Agent Skills 在實際應(yīng)用中的潛力與挑戰(zhàn)，在 4 月 16 日 -18 日舉辦的 QCon 北京大會上，我們特別邀請了 Ubiquiti Quality Assurance 蔡明哲帶來專題演講《從單點輔助到 Agent 閉環(huán)：基于 Agent Skills、MCP 與 Playwright 的全鏈路智能化測試實踐》。他將聚焦智能化測試在質(zhì)量保證中的落地實踐，詳細拆解 Agent Skills、Playwright Agent 與 MCP 的職責分工與組合范式，并介紹如何從案例生成到自動修復(fù)實現(xiàn)全流程工程實踐落地。