本文主要分享 Datacake 在大數(shù)據(jù)治理中，AI 算法的應用經(jīng)驗。本次分享分為五大部分：第一部分闡明大數(shù)據(jù)與 AI 的關系，大數(shù)據(jù)不僅可以服務于 AI，也可以使用 AI 來優(yōu)化自身服務，兩者是互相支撐、依賴的關系；第二部分介紹利用 AI 模型綜合評估大數(shù)據(jù)任務健康度的應用實踐，為后續(xù)開展數(shù)據(jù)治理提供量化依據(jù)；第三部分介紹利用 AI 模型智能推薦 Spark 任務運行參數(shù)配置的應用實踐，實現(xiàn)了提高云資源利用率的目標；第四部分介紹在 SQL 查詢場景中，由模型智能推薦任務執(zhí)行引擎的實踐；第五部分展望了在大數(shù)據(jù)整個生命周期中，AI 的應用場景。

一、大數(shù)據(jù)與AI

普遍觀念認為，云計算收集存儲海量數(shù)據(jù)，從而形成大數(shù)據(jù)；再經(jīng)過對大數(shù)據(jù)的挖掘?qū)W習，進一步形成 AI 模型。這種觀念默認了大數(shù)據(jù)服務于 AI，但忽視了其實 AI 算法也可以反哺于大數(shù)據(jù)，它們之間是一個雙向、互相支撐、依賴的關系。

大數(shù)據(jù)的全生命周期可以分成六個階段，每個階段都面臨一些問題，恰當?shù)厥褂?AI 算法有助于這些問題的解決。

數(shù)據(jù)采集：這個階段會比較關注數(shù)據(jù)采集的質(zhì)量、頻率、以及安全性，例如采集到的數(shù)據(jù)是否完整，采集數(shù)據(jù)的速度是否過快或者過慢，采集的數(shù)據(jù)是否經(jīng)過脫敏或者加密等。這時候 AI 可以發(fā)揮一些作用，比如基于同類應用來評估日志采集的合理性、使用異常檢測算法來發(fā)現(xiàn)數(shù)據(jù)量暴增或驟減等情況。

數(shù)據(jù)傳輸：這個階段比較關注數(shù)據(jù)的可用性、完整性和安全性，可以使用 AI 算法來做一些故障的診斷和入侵檢測。

數(shù)據(jù)存儲：這個階段比較關注數(shù)據(jù)的存儲結構是否合理、資源占用是否足夠低、是否足夠安全等，同樣可以用 AI 算法來做一些評估以及優(yōu)化。

數(shù)據(jù)處理：這個階段是影響及優(yōu)化收益最明顯的一個階段，其核心問題就是提高數(shù)據(jù)的處理效率且降低資源的消耗，AI 可以從多個著手點進行優(yōu)化。

數(shù)據(jù)交換：企業(yè)之間的合作越來越多，這就會涉及到數(shù)據(jù)的安全性問題。算法在這方面也可以得到應用，比如時下熱門的聯(lián)邦學習就可以幫助更好更安全地進行數(shù)據(jù)的共享。

數(shù)據(jù)銷毀：數(shù)據(jù)不可能只存不刪，這就需要考慮什么時候可以去刪數(shù)據(jù)、是否有風險。在業(yè)務規(guī)則的基礎上，AI 算法可以輔助判斷刪除數(shù)據(jù)的時機及關聯(lián)影響。

整體來看，數(shù)據(jù)生命周期管理有三大目標：高效、低成本，以及安全。以往的做法是依靠專家經(jīng)驗來制定一些規(guī)則策略，其弊端非常明顯，成本高、效率低。恰當?shù)夭捎?AI 算法可以避免這些弊端，反哺于大數(shù)據(jù)基礎服務的建設。

二、大數(shù)據(jù)任務健康度評估

在茄子科技，已經(jīng)落地的幾個應用場景，首先是大數(shù)據(jù)任務健康度的評估。

在大數(shù)據(jù)平臺上，每天運行著成千上萬的任務。但是很多任務僅停留在能正確產(chǎn)數(shù)階段，對于任務的運行耗時、資源消耗等并未給予關注，導致很多任務存在效率低下、資源浪費的情況。

即使有數(shù)據(jù)開發(fā)者開始關注任務健康度，也很難準確的評估任務究竟健康與否。因為任務相關的指標非常多，失敗率、耗時、資源消耗等，況且不同任務的復雜度及處理數(shù)據(jù)的體量存在天然差別，因此簡單選擇某項指標的絕對值作為評估標準顯然是不合理的。

沒有量化的任務健康度，就很難確定哪些任務不健康、需要治理，更不知道問題在哪里、從哪著手治理，即使治理完也不知道效果如何，甚至出現(xiàn)某項指標提升但別的指標惡化的情況。

需求：面對上述難題，我們急需一種量化指標來準確反映任務的綜合健康狀況。人工制定規(guī)則的方式效率低且不全面，因此考慮借助機器學習模型的力量。目標是模型能給出任務的量化評分及其在全局分布中的位置，并且給出任務的主要問題及解決方案。

對此需求，我們的功能模塊方案是，在管理界面顯示 owner 名下所有任務的關鍵信息，如評分、任務成本、CPU 利用率、內(nèi)存利用率等。這樣任務的健康度一目了然，方便后續(xù)由任務 owner 去做任務的治理。

其次，評分功能的模型方案，我們是把它作為一個分類問題來處理。直觀來看，任務評分顯然是一個回歸問題，給出的應該是 0 到 100 之間的任意實數(shù)。但這樣的話就要求有足夠多的帶評分的樣本，人工標注成本高且不可靠。

因此我們考慮將問題轉(zhuǎn)化為分類問題，分類模型給出的類別概率可以進一步映射為實數(shù)分值。我們將任務分為好任務 1 和壞任務 0 兩類，由大數(shù)據(jù)工程師標注。所謂好任務，通常是指同等任務量與復雜度的情況下，耗時短、資源消耗少的任務。

模型訓練過程為：

首先是樣本準備，我們的樣本來自于歷史運行的任務數(shù)據(jù)，樣本特征包括運行時間、使用的資源、是否執(zhí)行失敗等等，樣本標簽是由大數(shù)據(jù)工程師根據(jù)規(guī)則或經(jīng)驗標注成好、壞兩類。然后就可以訓練模型了，我們先后嘗試過 LR、GBDT、XGboost 等模型，理論及實踐均證明 XGboost 具有更好的分類效果。模型最終會輸出任務為“好任務”的概率，該概率越大，最終映射出的任務評分就越高。

經(jīng)過訓練之后，從最初將近 50 個原始特征里面篩選出 19 個特征，這 19 個特征基本上能夠決定一個任務是否是一個好的任務。比如失敗次數(shù)多的任務、資源利用率低的任務，大部分得分不會太高，與人工的主觀感受基本一致。

使用模型對任務打分后可以看到，在 0 到 30 分以下屬于不太健康的、急需要治理的任務；30 到 60 之間的是健康度尚可的任務；60 分以上的是健康度比較好的，需要保持現(xiàn)狀的任務。這樣有了量化指標，就可以引導任務 owner 去積極地做一些任務的治理，從而實現(xiàn)降本增效的目標。

模型應用之后給我們帶來了如下收益：

① 首先，任務 owner 對其名下任務的健康度可以做到心中有數(shù)，通過分數(shù)、排名就能夠知道任務是否需要治理；

②量化的指標為后續(xù)開展任務治理提供了依據(jù)；

③任務治理完成之后取得了多大的收益，有多少提升，同樣可以通過分數(shù)得到量化的展示。

三、Spark 任務智能調(diào)參

第二個應用場景是 Spark 任務的智能調(diào)參。Gartner 的一項調(diào)研揭示，云用戶消耗的 70% 的云資源都存在不必要的浪費。在申請云資源時，很多人為了確保任務的成功執(zhí)行，可能會去多申請一些資源，這就會造成不必要的浪費。還有很多人在創(chuàng)建任務時采用了默認配置，但其實這并不是最優(yōu)配置。如果能夠認真配置，可以達到非常好的效果，既能保證運行效率，又能保證運行成功，同時還能夠節(jié)省很多的資源。但任務參數(shù)配置對用戶有很高的要求，除了了解配置項的含義，還需要考慮配置項之間的關聯(lián)影響。即使依賴專家經(jīng)驗也很難達到最優(yōu)，而且規(guī)則類的策略難以動態(tài)調(diào)整。

這就提出一個需求，希望由模型智能地推薦出任務運行最優(yōu)的參數(shù)配置，使得在保持任務原有運行時間不變長的前提下，提高任務云資源的利用率。

對于任務調(diào)參功能模塊，我們設計的方案包含兩種情況：第一種是對于已經(jīng)在線上運行了一段時間的任務，模型要能夠根據(jù)任務歷史運行情況推薦出最合適的配置參數(shù)；第二種情況是對于用戶還沒上線的任務，模型要能夠通過對任務的分析給出合理的配置。

接下來就是訓練模型了，首先要確定模型的輸出目標?？膳渲庙椨腥俣鄺l，不可能都由模型給出。經(jīng)過測試與調(diào)研，我們選擇了三項對任務運行性能影響最大的參數(shù)，分別是執(zhí)行器 executor 的 cores 核心數(shù)、memory 內(nèi)存總量、instances 實例個數(shù)。每個配置項都有其默認值及可調(diào)范圍，其實就是給定了一個參數(shù)空間，模型只需要在這個空間里去尋找最優(yōu)解即可。

訓練階段，有兩種方案來進行?。方案一是學習經(jīng)驗規(guī)則：前期采用規(guī)則的方式推薦參數(shù)，上線之后效果還不錯，因此先讓模型來學習這套規(guī)則，從而達到快速上線的目標。模型訓練樣本是之前根據(jù)規(guī)則計算出來的七萬余條任務配置，樣本特征是任務的歷史運行數(shù)據(jù)（比如任務處理的數(shù)據(jù)量、資源的使用量、任務耗時等），以及一些統(tǒng)計信息（比如過去七日的平均耗量、最大耗量等）。

基礎模型我們選擇了多因變量的多元回歸模型。常見的回歸模型是單輸出的，有很多自變量但只有一個因變量。這里我們希望能輸出三個參數(shù)，所以采用的是多因變量的多元回歸模型，它的本質(zhì)還是一個 LR 模型。?

?上圖展示的是這個模型的理論基礎。左側是一個多標簽，就是三個配置項，β 是每個特征的系數(shù)，Σ 是誤差。訓練方式和一元回歸一樣，用最小二乘法去做估計使得 Σ 中各元素的平方和達到最小。

方案一的好處，就是能快速學到規(guī)則經(jīng)驗，成本也是比較小的。缺陷是其優(yōu)化上限最多能達到和規(guī)則一樣好的效果，但如果想超過會比較困難。?

第二種方案是貝葉斯優(yōu)化，其思路和強化學習比較類似，通過在參數(shù)空間里做嘗試尋找最優(yōu)配置。這里采用了貝葉斯框架，原因是其能夠利用上一次嘗試的基礎，在下次嘗試時就會有一些先驗的經(jīng)驗，能夠快速找到較優(yōu)位置。整個訓練過程會在一個參數(shù)空間里面進行，隨機采樣一種配置來做驗證，然后去運行；運行之后會關注一些指標，比如使用率、成本等，判斷是不是最優(yōu)；然后重復以上步驟，直到調(diào)優(yōu)完成。模型訓練好后，在使用過程中也有一個取巧的過程，假如新任務和歷史任務有一定的相似度，就不需要再去計算一遍配置，直接采用以往的最優(yōu)配置即可。

經(jīng)過這兩種方案的嘗試和實踐，能夠看到取得了一定的效果。對于已有的任務，按照模型推薦的配置參數(shù)來做修改后，80% 以上的任務能夠?qū)崿F(xiàn)大概 15% 的資源利用率的提升，部分任務資源的使用率甚至是翻倍的。但這兩種方案其實都存在缺陷：學習規(guī)則的回歸模型，其優(yōu)化上限較低；全局尋優(yōu)的貝葉斯優(yōu)化模型，缺點是要做各種嘗試，成本太高。

未來的探索方向有以下幾個：

語義分析：Spark 語義是比較豐富的，包含不同的代碼結構和算子函數(shù)，其與任務參數(shù)配置、資源消耗息息相關。但是目前我們利用的只是任務的歷史運行情況，忽略了 Spark 語義本身，這就是一種信息的浪費。接下來要做的是滲透到代碼層面，分析 Spark 任務中包含的算子函數(shù)，據(jù)此做更細粒度的調(diào)優(yōu)。

分類調(diào)優(yōu)：Spark 的應用場景很多，比如用于純分析、用于開發(fā)、用于處理等，不同場景的調(diào)優(yōu)空間與目標也是不同的，所以有必要做分類調(diào)優(yōu)。

工程優(yōu)化：在實踐過程中遇到的一個困難是樣本較少、測試成本較高，這需要相關方共同配合，在工程或流程上做優(yōu)化。

四、SQL 任務執(zhí)行引擎智能選擇

第三個應用場景是 SQL 查詢?nèi)蝿請?zhí)行引擎的智能選擇。

背景：

（1）SQL 查詢平臺是大多數(shù)用戶接觸最多的、體驗最明顯的一個大數(shù)據(jù)產(chǎn)品，不管是數(shù)據(jù)分析師、研發(fā)，還是產(chǎn)品經(jīng)理，每天都會寫大量 SQL 來獲取自己想要的數(shù)據(jù)；

（2）很多人在運行 SQL 任務的時候，并不會去關注底層的執(zhí)行引擎，比如 Presto 是基于純內(nèi)存的計算，在一些簡單查詢的場景下，其優(yōu)勢就是執(zhí)行速度會比較快，但缺點就是假如存儲量不夠用的話會直接掛掉；與它形成對比的是 Spark，其比較適合執(zhí)行大數(shù)據(jù)量的復雜場景，即使出現(xiàn)了 oom 也會使用磁盤的存儲，從而避免任務的失敗。所以，不同的引擎是適合不同的任務場景的。

（3）SQL 查詢效果要綜合考慮任務的執(zhí)行時間以及資源的消耗，既不能過分追求查詢速度而不考慮資源消耗，也不能為了節(jié)省資源而影響查詢效率。

（4）業(yè)界傳統(tǒng)的引擎選擇方式主要有三種，RBO、CBO 和 HBO。RBO是基于規(guī)則的優(yōu)化器，規(guī)則制定困難且更新頻率低；CBO是基于成本的優(yōu)化，太過于追求成本的優(yōu)化，可能會導致任務執(zhí)行失敗；HBO是基于歷史任務運行情況的一種優(yōu)化器，比較局限于歷史數(shù)據(jù)。

在功能模塊上的設計，當用戶編寫完 SQL 語句提交執(zhí)行后，由模型自動判斷使用哪種引擎并彈窗提示，由用戶最終決定是否采用推薦的引擎執(zhí)行。

模型的整體方案是基于 SQL 語句本身來推薦執(zhí)行引擎。因為從 SQL 本身就能夠看到用了什么表、用到哪些函數(shù)等，這些信息直接決定了 SQL 的復雜度，從而影響執(zhí)行引擎的選擇。模型訓練樣本來自于歷史運行的 SQL 語句，模型標簽是根據(jù)歷史執(zhí)行情況進行標注，比如任務執(zhí)行超長、涉及數(shù)據(jù)量超大的任務會標為適合在 Spark 上運行，剩下的就是適合在 Presto 上去運行的 SQL。樣本特征提取用到 NLP 技術，N-gram 加 TF-IDF 方法，大致原理是提取詞組去看它在語句中出現(xiàn)的頻率，這樣能夠提取出關鍵詞組。經(jīng)此操作后生成的向量特征非常大，我們先利用線性模型篩選出 3000 個特征，然后訓練生成 XGBoost 模型作為最終的預測模型。

經(jīng)過訓練之后，能夠看到模型預測的準確度還是比較高的，大概 90% 以上。

最終模型在線上的應用流程是：用戶提交 SQL 后由模型推薦執(zhí)行引擎，假如與用戶最初選擇的引擎不一樣，則會調(diào)用語言轉(zhuǎn)換模塊完成 SQL 語句的轉(zhuǎn)換。假如切換引擎之后執(zhí)行失敗，我們會有 failover 機制切回到用戶原有引擎去執(zhí)行，保證任務執(zhí)行成功。

該實踐的收益是模型可以自動選擇出最適合的執(zhí)行引擎，并且完成后續(xù)的語句轉(zhuǎn)換，不需要用戶再去做額外的學習。

另外，模型推薦的引擎基本上能夠保持原有的執(zhí)行效率不變，同時又能夠降低失敗率，所以整體上用戶體驗會上升。

最后就是由于減少了不必要的高成本引擎的使用，以及任務執(zhí)行失敗率的下降，使得整體資源成本消耗下降。

第二部分到第四部分，我們分享了 AI 算法在大數(shù)據(jù)平臺上的三個應用。能夠看到它的一個特點，就是使用的算法并不是特別復雜，但是效果會非常明顯。這就啟發(fā)我們要主動去了解大數(shù)據(jù)平臺在運行過程中有哪些痛點或者優(yōu)化空間，確定好應用場景后就可以嘗試使用不同的機器學習方法去解決這些問題，從而實現(xiàn) AI 算法向大數(shù)據(jù)的反哺。

五、AI 算法在大數(shù)據(jù)治理中的應用展望

最后我們展望一下 AI 算法在大數(shù)據(jù)治理中的應用場景。

以上介紹的三個應用場景，比較集中在數(shù)據(jù)處理階段。其實呼應一下第一章講的 AI 和大數(shù)據(jù)的關系，在整個數(shù)據(jù)生命周期里，AI 都能發(fā)揮比較好的作用。

比如在數(shù)據(jù)采集階段，能夠判斷日志是否合理；傳輸時能夠去做入侵檢測；處理時，還可以再進一步的降本增效；交換時去做一些保障數(shù)據(jù)安全的工作；銷毀時能夠去判斷銷毀的時機與關聯(lián)影響等。AI 在大數(shù)據(jù)平臺的應用場景是非常多的，這里僅是拋磚引玉。相信未來 AI 與大數(shù)據(jù)的互相支撐關系會更加凸顯，AI 輔助大數(shù)據(jù)平臺更好地去采集處理數(shù)據(jù)，更好的數(shù)據(jù)質(zhì)量后續(xù)又能幫助訓練更好的 AI 模型，從而實現(xiàn)良性循環(huán)。

六、問答環(huán)節(jié)

Q1：使用的規(guī)則引擎是哪種，是開源的嗎？

A1：這里所謂的調(diào)參規(guī)則是前期我們大數(shù)據(jù)同事根據(jù)手動調(diào)優(yōu)經(jīng)驗制定的，比如任務的執(zhí)行時間超出多少分鐘、或者處理的數(shù)據(jù)量超出多大，給任務推薦多少核心數(shù)或者內(nèi)存量等。這是一套經(jīng)過長時間積累形成的規(guī)則，而且上線后效果比較好，所以使用這一套規(guī)則來訓練我們的參數(shù)推薦模型。

Q2：因變量只有參數(shù)的調(diào)整嗎？是否有考慮到大數(shù)據(jù)平臺的性能不穩(wěn)定性，對計算結果帶來的影響？

A2：在做參數(shù)推薦的時候，我們并不是只一味的追求成本要低，否則推薦的資源會偏低導致任務失敗。因變量確實只有參數(shù)調(diào)整，但為了防止不穩(wěn)定性我們加了額外限制。首先是模型特征，我們選取的是某段時間的平均值而非孤立某天的數(shù)值；其次對于模型推薦的參數(shù)，我們會比較其與實際配置值之間的差別，如果差別過大則會采用緩升緩降策略，避免一次性調(diào)整過大導致任務失敗。

Q3：回歸模型與貝葉斯模型是否同時使用？

A3：不是的。剛剛講到在做參數(shù)推薦這塊，我們是有用過兩種方案：學習規(guī)則用的是回歸模型；再往后是用的貝葉斯優(yōu)化的框架。它們兩個并不是同時使用的，我們是做了兩種嘗試。前一種學習規(guī)則，好處就是能夠快速的把歷史以往的經(jīng)驗給使用起來；第二個模型在前一個的基礎上，能夠去尋找一個更優(yōu)，甚至是最優(yōu)的配置。他們兩個是屬于一種先后的，或者是遞進的關系，而不是同時使用。

Q4：引入語義分析是從拓展更多特征來考慮的嗎？

A4：是的。剛剛有講到，在做 Spark 調(diào)參的時候我們用到的信息只有它的歷史執(zhí)行情況，但對于 Spark 任務本身目前還沒去關注。Spark 本身其實包含非常多的信息，有各種各樣的算子、階段等。如果不去分析它的語義，會丟失很多信息。所以我們下一步的計劃就是去分析 Spark 任務的語義，拓展更多的特征來輔助參數(shù)計算。

Q5：參數(shù)推薦是否會出現(xiàn)參數(shù)推薦不合理，導致任務異常甚至失敗，然后對于這樣的場景怎么降低異常任務報錯和任務波動？

A5：如果完全依賴模型，有可能它追求的就是盡可能高的提升資源的利用率，這時候推薦的參數(shù)有可能會比較激進，比如內(nèi)存一下子由 30g 縮到 5g。因此除了模型推薦外，我們會增加額外的限制條件，比如調(diào)參跨度不能超過多少 g 等，也即緩升緩降策略。

Q6：sigmoid 2022 有一些參數(shù)調(diào)優(yōu)相關的文章，有進行參考嗎？

A6：任務智能調(diào)參還是比較熱門的研究方向，不同領域的團隊采用了不同的方法模型。我們在著手做之前調(diào)研了比較多的業(yè)界方法，包括你提到的 sigmoid 2022 論文。經(jīng)過比較與實踐，最終嘗試了我們分享的這兩種方案。后續(xù)我們會繼續(xù)關注這個方向的最新進展，嘗試更多方法來提高推薦效果。