本文主要分享 Datacake 在大數據治理中，AI 演算法的應用經驗。本次分享分為五大部分：第一部分闡明大數據與AI 的關係，大數據不僅可以服務於AI，也可以使用AI 來優化自身服務，兩者是互相支撐、依賴的關係；第二部分介紹利用AI 模型綜合評估大數據任務健康度的應用實踐，為後續開展資料治理提供量化依據；第三部分介紹利用AI 模型智慧推薦Spark 任務運行參數配置的應用實踐，實現了提高雲端資源利用率的目標；第四部分介紹在SQL 查詢場景中，由模型智慧推薦任務執行引擎的實踐；第五部分展望了在大數據整個生命週期中，AI 的應用場景。
普遍觀念認為，雲端運算收集儲存海量數據，從而形成大數據；再經過對大數據的挖掘學習，進一步形成AI 模型。這種觀念默認了大數據服務於 AI，但忽略了其實 AI 演算法也可以反哺於大數據，它們之間是一個雙向、互相支撐、依賴的關係。
#大數據的全生命週期可以分成六個階段，每個階段都面臨一些問題，恰當地使用AI 演算法有助於這些問題的解決。
資料收集：這個階段會比較關注資料收集的品質、頻率、以及安全性，例如採集到的資料是否完整，採集資料的速度是否過快或過慢，採集的資料是否經過減敏或加密等。這時候 AI 可以發揮一些作用，例如基於同類應用來評估日誌採集的合理性、使用異常檢測演算法來發現資料量暴增或驟減等情況。
資料傳輸：這個階段比較關注資料的可用性、完整性和安全性，可以使用AI演算法來做一些故障的診斷和入侵偵測。
資料儲存：這個階段比較關注資料的儲存結構是否合理、資源佔用是否夠低、是否足夠安全等，同樣可以用AI 演算法來做一些評估以及優化。
資料處理：這個階段是影響及最佳化收益最明顯的一個階段，其核心問題就是提高資料的處理效率且降低資源的消耗，AI 可以從多個著手點進行最佳化。
資料交換：#企業之間的合作越來越多，這就會涉及到資料的安全性問題。演算法在這方面也可以應用，例如時下熱門的聯邦學習可以幫助更好更安全地進行資料的共享。
資料銷毀：#資料不可能只存不刪，這就需要考慮什麼時候可以去刪數據、是否有風險。在業務規則的基礎上，AI 演算法可以輔助判斷刪除資料的時機及關聯影響。
整體來看，資料生命週期管理有三大目標：高效率、低成本，以及安全性。過去的做法是依靠專家經驗來制定一些規則策略，其弊端非常明顯，成本高、效率低。恰當地採用 AI 演算法可以避免這些弊端，反哺於大數據基礎服務的建置。
在茄子科技，已經落地的幾個應用場景，首先是大數據任務健康度的評估。
#在大數據平台上，每天運行成千上萬的任務。但許多任務只停留在能正確產數階段，對於任務的運作耗時、資源消耗等並未給予關注，導致許多任務存在效率低、資源浪費的情況。
即使有資料開發者開始關注任務健康度，也很難準確的評估任務究竟健康與否。因為任務相關的指標非常多，失敗率、耗時、資源消耗等，況且不同任務的複雜度及處理數據的體量存在天然差別，因此簡單選擇某項指標的絕對值作為評估標準顯然是不合理的。
沒有量化的任務健康度，就很難確定哪些任務不健康、需要治理，更不知道問題在哪裡、從哪著手治理，即使治理完也不知道效果如何，甚至出現某項指標提升但別的指標惡化的情況。
需求：#面對上述難題，我們急需一種量化指標來準確反映任務的綜合健康狀況。人工製定規則的方式效率低且不全面，因此考慮借助機器學習模型的力量。目標是模型能給出任務的量化評分及其在全局分佈中的位置，並且給出任務的主要問題及解決方案。
對此需求，我們的功能模組方案是，在管理介面顯示owner 名下所有任務的關鍵訊息，如評分、任務成本、CPU 利用率、記憶體利用率等。這樣任務的健康度一目了然，方便後續由任務 owner 去做任務的治理。
其次，評分功能的模型方案，我們是把它當作一個分類問題來處理。直觀來看，任務評分顯然是一個回歸問題，給出的應該是 0 到 100 之間的任意實數。但這樣的話就要求有足夠多的有評分的樣本，人工標註成本高且不可靠。
因此我們考慮將問題轉換為分類問題，分類模型給出的類別機率可以進一步映射為實數分值。我們將任務分為好任務 1 和壞任務 0 兩類，由大數據工程師標註。所謂好任務，通常是指同等任務量與複雜度的情況下，耗時短、資源消耗少的任務。
首先是樣本準備，我們的樣本來自於歷史運行的任務數據，樣本特徵包括運行時間、使用的資源、是否執行失敗等等，樣本標籤是由大數據工程師根據規則或經驗標註成好、壞兩類。然後就可以訓練模型了，我們先後嘗試過 LR、GBDT、XGboost 等模型，理論及實踐都證明 XGboost 有更好的分類效果。模型最終會輸出任務為「好任務」的機率，該機率越大，最終映射出的任務評分就越高。
經過訓練後，從最初將近 50 個原始特徵裡面篩選出 19 個特徵，這 19 個特徵基本上能夠決定一個任務是否是一個好的任務。例如失敗次數多的任務、資源利用率低的任務，大部分得分不會太高，與人工的主觀感受基本一致。
使用模型對任務評分後可以看到，在0 到30 分以下屬於不太健康的、急需要治理的任務；30 到60 之間的是健康度尚可的任務；60 分以上的是健康度比較好的，需要維持現狀的任務。這樣有了量化指標，就可以引導任務 owner 去積極地做一些任務的治理，從而實現降本增效的目標。
模型應用之後為我們帶來瞭如下收益：
#① 首先，任務owner 對其名下任務的健康度可以做到心中有數，透過分數、排名就能夠知道任務是否需要治理；
#② 量化的指標為後續開展任務治理提供了依據；
③ 任務治理完成之後取得了多大的收益，有多少提升，同樣可以透過分數來量化的展示。
第二個應用場景是Spark 任務的智慧調參。 Gartner 的一項研究揭示，雲端用戶消耗的 70% 的雲端資源都存在不必要的浪費。在申請雲端資源時，很多人為了確保任務的成功執行，可能會去多申請一些資源，這就會造成不必要的浪費。還有很多人在創建任務時採用了預設配置，但其實這並不是最優配置。如果能夠認真配置，可以達到非常好的效果，既能保證運作效率，又能保證運作成功，同時也能節省很多的資源。但任務參數配置對使用者有很高的要求，除了了解配置項的意義，還需要考慮配置項之間的關聯影響。即使依賴專家經驗也很難達到最優，而且規則類的策略難以動態調整。
這就提出一個需求，希望由模型智慧地推薦出任務運行最優的參數配置，使得在保持任務原有運行時間不變長的前提下，提高任務雲資源的使用率。
對於任務調參功能模組，我們設計的方案包含兩種情況：第一種是對於已經在線上運行了一段時間的任務，模型要能夠根據任務歷史運行情況推薦最合適的配置參數；第二種情況是對於用戶還沒上線的任務，模型要能夠透過對任務的分析給出合理的配置。
接下來就是訓練模型了，首先要確定模型的輸出目標。可配置項有三百多條，不可能都由模型給出。經過測試與研究，我們選擇了三項對任務運行效能影響最大的參數，分別是執行器 executor 的 cores 核心數、memory 記憶體總量、instances 實例個數。每個配置項都有其預設值及可調範圍，其實就是給定了一個參數空間，模型只需要在這個空間裡去尋找最優解即可。
訓練階段，有兩種方案可以進行。方案一是學習經驗規則：前期採用規則的方式推薦參數，上線之後效果還不錯，因此先讓模型來學習這套規則，從而達到快速上線的目標。模型訓練樣本是先前根據規則計算出來的七萬餘條任務配置，樣本特徵是任務的歷史運行資料（例如任務處理的資料量、資源的使用量、任務耗時等），以及一些統計資料（例如過去七日的平均耗量、最大耗量等）。
基礎模型我們選擇了多因變數的多元迴歸模型。常見的迴歸模型是單輸出的，有很多自變數但只有一個因變數。這裡我們希望能輸出三個參數，所以採用的是多因變數的多元迴歸模型，它的本質還是一個 LR 模型。
上圖展示的是這個模型的理論基礎。左側是一個多標籤，就是三個配置項，β 是每個特徵的係數，Σ 是誤差。訓練方式和一元迴歸一樣，用最小平方法去做估計使得 Σ 中各元素的平方和達到最小。
方案一的好處，就是能快速學到規則經驗，成本也是比較小的。缺陷是其最佳化上限最多能達到和規則一樣好的效果，但如果想超過會比較困難。
第二種方案是貝葉斯最佳化，其想法和強化學習比較類似，透過在參數空間裡做嘗試尋找最優配置。這裡採用了貝葉斯框架，原因是其能夠利用上一次嘗試的基礎，在下次嘗試時就會有一些先驗的經驗，能夠快速找到較優位置。整個訓練過程會在一個參數空間裡面進行，隨機採樣一種配置來做驗證，然後去運行；運行之後會關註一些指標，比如使用率、成本等，判斷是不是最優；然後重複以上步驟，直到調優完成。模型訓練好後，在使用過程中也有一個取巧的過程，假如新任務和歷史任務有一定的相似度，就不需要再去計算一遍配置，直接採用以往的最優配置即可。
#經過這兩個方案的嘗試和實踐，能夠看到取得了一定的效果。對於現有的任務，依照模型建議的配置參數來做修改後，80% 以上的任務能夠達到大概 15% 的資源利用率的提升，部分任務資源的使用率甚至是翻倍的。但這兩種方案其實都存在著缺陷：學習規則的迴歸模型，其最佳化上限較低；全域尋優的貝葉斯最佳化模型，缺點是要做各種嘗試，成本太高。
#未來的探索方向有以下幾個：
#語意分析：Spark 語意是比較豐富的，包含不同的程式碼結構和運算子函數，其與任務參數配置、資源消耗息息相關。但目前我們利用的只是任務的歷史運行情況，忽略了 Spark 語意本身，這就是一種資訊的浪費。接下來要做的是滲透到程式碼層面，分析 Spark 任務中包含的算子函數，據此做更細粒度的調優。
分類調優：#Spark 的應用場景很多，例如用於純分析、用於開發、用於處理等，不同場景的調優空間與目標也是不同的，所以有必要做分類調優。
#工程最佳化：在實務過程中遇到的一個困難是樣本較少、測試成本較高，這需要相關方共同配合，在工程或流程上做優化。
#第三個應用程式場景是SQL 查詢任務執行引擎的智能選擇。
背景：
（1） SQL 查詢平台是大多數使用者接觸最多的、體驗最明顯的一個大數據產品，不管是資料分析師、研發，還是產品經理，每天都會寫大量SQL 來取得自己想要的資料；
（2）很多人在執行SQL 任務的時候，不會去關注底層的執行引擎，例如Presto 是基於純記憶體的運算，在一些簡單查詢的場景下，其優勢就是執行速度會比較快，但缺點就是假如存儲量不夠用的話會直接掛掉；與它形成對比的是Spark，其比較適合執行大數據量的複雜場景，即使出現了oom 也會使用磁碟的存儲，從而避免任務的失敗。所以，不同的引擎是適合不同的任務場景的。
（3）SQL 查詢效果要綜合考慮任務的執行時間以及資源的消耗，既不能過分追求查詢速度而不考慮資源消耗，也不能為了節省資源而影響查詢效率。
（4）業界傳統的引擎選擇方式主要有三種，RBO、CBO 和 HBO。 RBO 是基於規則的最佳化器，規則制定困難且更新頻率低；CBO 是基於成本的最佳化，太過於追求成本的最佳化，可能會導致任務執行失敗；HBO 是基於歷史任務運作情況的一種最佳化器，比較局限於歷史資料。
在功能模組上的設計，當使用者寫完SQL 語句提交執行後，由模型自動判斷使用哪種引擎並彈出視窗提示，由使用者最終決定是否採用建議的引擎執行。
模型的整體方案是基於 SQL 語句本身來推薦執行引擎。因為從 SQL 本身就能夠看到用了什麼表、用到哪些函數等，這些資訊直接決定了 SQL 的複雜度，進而影響執行引擎的選擇。模型訓練樣本來自於歷史運行的SQL 語句，模型標籤是根據歷史執行情況進行標註，例如任務執行超長、涉及資料量超大的任務會標為適合在Spark 上運行，剩下的就是適合在Presto 上去運行的SQL。樣本特徵提取用到 NLP 技術，N-gram 加 TF-IDF 方法，大致原理是提取詞組去看它在語句中出現的頻率，這樣能夠提取關鍵詞組。經此操作後產生的向量特徵非常大，我們先利用線性模型篩選出 3000 個特徵，然後訓練產生 XGBoost 模型作為最終的預測模型。
#已訓練後，能夠看到模型預測的準確度還是比較高的，大概90% 以上。
最終模型在線上的應用流程是：使用者提交 SQL 後由模型推薦執行引擎，假如與使用者原先選擇的引擎不一樣，則會呼叫語言轉換模組完成 SQL 語句的轉換。假如切換引擎之後執行失敗，我們會有 failover 機制切回使用者原有引擎去執行，確保任務執行成功。
#該實踐的收益是模型可以自動選擇最適合的執行引擎，並且完成後續的語句轉換，不需要使用者再去做額外的學習。
另外，模型推薦的引擎基本上能夠保持原有的執行效率不變，同時又能夠降低失敗率，所以整體上使用者體驗會上升。
最後是因為減少了不必要的高成本引擎的使用，以及任務執行失敗率的下降，使得整體資源成本消耗下降。
第二部分到第四部分，我們分享了 AI 演算法在大數據平台上的三個應用。能夠看到它的一個特點，就是使用的演算法並不是特別複雜，但是效果會非常明顯。 這就啟發我們要主動去了解大數據平台在運行過程中有哪些痛點或者優化空間，確定好應用場景後就可以嘗試使用不同的機器學習方法去解決這些問題，從而實現AI 算法向大數據的反哺。
最後我們展望一下AI 演算法在大資料治理中的應用場景。
以上介紹的三個應用場景，比較集中在資料處理階段。其實呼應第一章所講的 AI 和大數據的關係，在整個資料生命週期裡，AI 都能發揮比較好的作用。
例如在資料收集階段，能夠判斷日誌是否合理；傳輸時能夠去做入侵偵測；處理時，還可以再進一步的降本增效；交換時去做一些保障資料安全的工作；銷毀時能夠去判斷銷毀的時機與關聯影響等。 AI 在大數據平台的應用場景是非常多的，這裡僅是拋磚引玉。相信未來 AI 與大數據的互相支撐關係會更加凸顯，AI 輔助大數據平台更好地去採集處理數據，更好的數據品質後續又能幫助訓練更好的 AI 模型，從而實現良性循環。
A1：這裡所謂的調參規則是前期我們大數據同事根據手動調優經驗制定的，例如任務的執行時間超出多少分鐘、或者處理的數據量超出多大，給任務推薦多少核心數或內存量等。這是一套經過長時間累積形成的規則，而且上線後效果比較好，所以使用這套規則來訓練我們的參數推薦模型。
#A2：在做參數推薦的時候，我們並不是只一味的追求成本要低，否則推薦的資源會偏低導致任務失敗。因變數確實只有參數調整，但為了防止不穩定性我們加了額外限制。首先是模型特徵，我們選取的是某段時間的平均值而非孤立某天的數值；其次對於模型建議的參數，我們會比較其與實際配置值之間的差別，如果差別過大則會採用緩升緩降策略，避免一次性調整過大導致任務失敗。
A3：不是的。剛剛講到在做參數推薦這塊，我們是有用過兩種方案：學習規則用的是回歸模型；再往後是用的貝葉斯優化的框架。它們兩個並不是同時使用的，我們做了兩種嘗試。前一種學習規則，好處就是能夠快速的把歷史以往的經驗給使用起來；第二個模型在前一個的基礎上，能夠去尋找一個更優，甚至是最優的配置。他們兩個是屬於一種先後的，或是遞進的關係，而不是同時使用。
A4：是的。剛剛有講到，在做 Spark 調參的時候我們用到的信息只有它的歷史執行情況，但對於 Spark 任務本身目前還沒去關注。 Spark 本身其實包含非常多的訊息，有各種不同的算子、階段等。如果不去分析它的語義，會失去很多資訊。所以我們下一步的計畫就是去分析 Spark 任務的語意，拓展更多的特徵來輔助參數計算。
A5：如果完全依賴模型，有可能它追求的就是盡可能高的提升資源的利用率，這時候推薦的參數有可能會比較激進，例如內存一下子由30g 縮到5g。因此除了模型推薦外，我們會增加額外的限制條件，例如調參跨距不能超過多少 g 等，也即緩升緩降策略。
A6：任務智能調參還是比較熱門的研究方向，不同領域的團隊採用了不同的方法模型。我們在著手做之前研究了比較多的業界方法，包括你提到的 sigmoid 2022 論文。經過比較與實踐，最終嘗試了我們分享的這兩個方案。後續我們會繼續關注這個方向的最新進展，嘗試更多方法來提高推薦效果。
今天的分享就到這裡，謝謝大家。
以上是AI 演算法在大數據治理上的應用的詳細內容。更多資訊請關注PHP中文網其他相關文章！
