天穹數倉自治能力在大模型時代的新實踐

作者：張功貫 2024-08-20 08:39:41

隨著大數據技術的不斷發展，數據治理和自治能力的提升變得尤為重要。本次分享題目為“天穹數倉自治能力新實踐”。

一、大數據自治的背景

1. 大數據自治涵蓋的范疇

大數據自治是一個廣義的概念，涵蓋從數據采集到數據接入、計算、存儲、應用等一系列問題。它不僅包括數據治理，還涉及數據研發和業務發生問題的解決。大數據自治的目的是管理數據的整個生命周期，從數據產生到數據使用，再到數據銷毀。

2. 業務、技術的快速發展

在過去的三十年中，數倉的發展歷程經歷了從傳統數倉到大數據數倉，再到數字數倉的三個階段。傳統數倉如 Oracle、DB2 等，架構單一，主要處理結構化數據，數據規模較小，實時性較低。

隨著 Google 三篇論文的發表，開始進入大數據時代，Hive、Hadoop/MR、Spark 等大數據數倉先后問世，產生了 Lambda、Kappa 等較為復雜的架構，處理的數據規模呈爆炸性增長，結構化、半結構化和異構化數據并存，實時性要求更高，計算也變得更為復雜。

從 2020 年至今，處于數智數倉時代，實時性和計算復雜性進一步提升，架構也更加復雜，包括流批一體、湖倉一體等，大模型也逐漸應用到數倉之中。

隨著數倉技術的發展，數據處理的流程從傳統的 ETL，變為大數據時代的 ELT，當前又提出了 EtLT 的概念。

3. 數倉模式演進：EtLT 崛起

EtLT 是 ELT 的擴展，其中 Extract、Load、Transform 的含義并沒有改變，在此基礎上提出了小 t 和大 T 的區別。針對當前數智數倉的技術生態，小 t 更緊密地結合湖倉技術，偏數據底層的工程架構，而大 T 階段則更貼合業務，結合大模型的能力，完成偏數據上層應用的工作。

二、天穹大數據自治能力建設和落地：雙引擎策略

天穹大數據自治平臺采用雙引擎策略，結合 SQL 智能體和傳統機器學習，推動平臺自治。通過構建感知力、觀測力、診斷力和優化力，實現對數據相關進程的細粒度感知和智能優化。能力范圍包括從數據采集、數據接入，到數據計算、存儲，再到應用的全流程，從資源、計算、研效等各方面進行了優化。

最終實現了包括算子粒度的回放和診斷能力的產品化：支持 40 多個算子粒度問題的診斷，并優化了 SQL 粒度算子實現了自動 map join 功能，在 Presto 上測試效果顯著，CPU 和內存節省顯著。SQL 引擎自動選擇方面，提升了計算性能，減少了資源浪費。作業任務資源優化方面，大幅降低了天穹上運行作業的內存和 CPU 成本。除此之外還有 SQL 智能體的優化改寫等功能，這些功能在實際應用中取得了顯著效果。

1. 感知力

感知力是數據系統的重要部分，決定著上層觀測力、診斷力、優化力等能力體系建設的深度。天穹平臺通過 JVM 級別的數據感知，已基本覆蓋所有物理機和容器，每天感知的數據量達到了萬億規模。

2. 觀測力

通過對采集數據進行指標的聚合和抽象，建立以健康分為核心的數據體系，實現任務進程粒度的數據上卷和下鉆操作，使大數據生態的“黑盒”更加透明化，發現底層指標或異常問題。

3. 診斷力

（1）全鏈路診斷能力的構建

針對內部經常遇到的作業鏈路較長，問題定位和診斷工作繁瑣低效的問題，天穹平臺基于組件粒度構建了全鏈路診斷能力，使得用戶能夠清晰地了解當前問題發生在哪個組件，并在此基礎上進行深入挖掘和對比。例如，如果問題發生在計算引擎側，能夠清晰地告知用戶作業在計算引擎層是由于資源搶占被 kill，或任務本身數據膨脹、數據傾斜等原因導致的異常，并提供細粒度的判斷。

（2）算子粒度的異常識別

同時，針對 SQL 任務，推出了算子粒度的診斷，可以將實際物理執行過程中發生的異常點與 SQL 邏輯片段對應起來，從而幫助用戶在繁雜的計算過程中快速準確地定位到問題的具體原因。

在實際應用中，我們已經將算子粒度的回放和診斷能力產品化。這使得用戶能夠回放 SQL 計算的過程，診斷每一個算子的數據規模和資源占用情況。目前，我們已經支持了 40 多個算子粒度問題的診斷。

4. 優化力

針對在大數據計算過程中面臨的挑戰，如任務運行緩慢、數據處理速度不理想以及任務資源啟動困難等問題，構建了優化力能力體系。在資源方面，針對 Spark 和 Flink 進行了深入優化。在性能方面，引入了 SQL 引擎選擇、智能 SQL Hint 和智能 RSS 等技術。此外，通過 SQL 智能體的構建，實現了 SQL 優化改寫、語法糾錯和診斷等功能。

（1）數據驅動的資源優化

針對 Spark 的資源優化，主要構建了基于 Spark 歷史運行數據的方法，采用白盒和黑盒兩種方式進行調整。白盒方法通過分析歷史運行過程中資源的實際進程粒度占用情況，擬合出適合作業正確運行的資源參數。我們根據歷史運行曲線自定義計算彈性因子，并每天為作業推薦資源參數。而黑盒方法則無需用戶感知，算法基于時間和性能兩個維度自動調整參數，并每天定時進行迭代。通過前一周期的運行結果，調整下一周期的參數，并提交到集群中運行。

最終針對一些應用組顯著節省了超過 50% 的內存成本和 30% 的 CPU成本，在資源優化方面取得了顯著的成果，降低了資源的使用。

（2）SQL 引擎選擇，讓 SQL 計算更加高效

在 SQL 計算引擎選擇方面，根據 SQL 計算邏輯的復雜度判斷其是 IO 密集型還是 CPU 密集型，并將不同的 SQL 分發到不同的計算引擎上以提高性能。同時從歷史運行的 SQL 中提取特征，利用 XGBoost 模型進行訓練，以優化底層的建模過程。

最終通過特征化和模型訓練，引擎 failover 規避率有了顯著提升，進一步降低了資源浪費。

（3）SQL 算子粒度優化，反哺計算引擎

除了資源優化和 SQL 引擎選擇外，還關注算子粒度的優化。從歷史運行數據中挖掘包含算子粒度信息的數據記錄，經過規劃處理后形成 SQL 算子粒度的數據體系。這有助于支持 SQL 的 CBO 代價模型優化。例如，如果提前知道計算過程的數據量，可以自動添加 map join 等提示以提升效率。此外，對于每天定時調度的數據計算任務，由于 SQL 邏輯和數據量相似，可以通過歷史數據進行預測和優化。