導讀 本文主要分享 Datacake 在大資料治理中，AI 演算法的應用經驗。本次分享分為五大部分：第一部分闡明大資料與 AI 的關係，大資料不僅可以服務於 AI，也可以使用 AI 來最佳化自身服務，兩者是互相支撐、依賴的關係；第二部分介紹利用 AI 模型綜合評估大資料任務健康度的應用實踐，為後續開展資料治理提供量化依據；第三部分介紹利用 AI 模型智慧推薦 Spark 任務執行引數配置的應用實踐，實現了提高雲資源利用率的目標；第四部分介紹在 SQL 查詢場景中，由模型智慧推薦任務執行引擎的實踐；第五部分展望了在大資料整個生命週期中，AI 的應用場景。
全文目錄：
1. 大資料與 AI
2. 大資料任務健康度評估
3. Spark 任務智慧調參
4. SQL 任務執行引擎智慧選擇
5. AI 演算法在大資料治理中的應用展望
分享嘉賓｜李衛民 快樂茄 演算法工程師
編輯整理｜Charles
出品社群｜DataFun
普遍觀念認為，雲端計算收集儲存海量資料，從而形成大資料；再經過對大資料的挖掘學習，進一步形成 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 模型，從而實現良性迴圈。
06
A1：這裡所謂的調參規則是前期我們大資料同事根據手動調優經驗制定的，比如任務的執行時間超出多少分鐘、或者處理的資料量超出多大，給任務推薦多少核心數或者記憶體量等。這是一套經過長時間積累形成的規則，而且上線後效果比較好，所以使用這一套規則來訓練我們的引數推薦模型。Q2：因變數只有引數的調整嗎？是否有考慮到大資料平臺的效能不穩定性，對計算結果帶來的影響？A2：在做引數推薦的時候，我們並不是只一味的追求成本要低，否則推薦的資源會偏低導致任務失敗。因變數確實只有引數調整，但為了防止不穩定性我們加了額外限制。首先是模型特徵，我們選取的是某段時間的平均值而非孤立某天的數值；其次對於模型推薦的引數，我們會比較其與實際配置值之間的差別，如果差別過大則會採用緩升緩降策略，避免一次性調整過大導致任務失敗。A3：不是的。剛剛講到在做引數推薦這塊，我們是有用過兩種方案：學習規則用的是迴歸模型；再往後是用的貝葉斯最佳化的框架。它們兩個並不是同時使用的，我們是做了兩種嘗試。前一種學習規則，好處就是能夠快速的把歷史以往的經驗給使用起來；第二個模型在前一個的基礎上，能夠去尋找一個更優，甚至是最優的配置。他們兩個是屬於一種先後的，或者是遞進的關係，而不是同時使用。A4：是的。剛剛有講到，在做 Spark 調參的時候我們用到的資訊只有它的歷史執行情況，但對於 Spark 任務本身目前還沒去關注。Spark 本身其實包含非常多的資訊，有各種各樣的運算元、階段等。如果不去分析它的語義，會丟失很多資訊。所以我們下一步的計劃就是去分析 Spark 任務的語義，擴充更多的特徵來輔助引數計算。Q5：引數推薦是否會出現引數推薦不合理，導致任務異常甚至失敗，然後對於這樣的場景怎麼降低異常任務報錯和任務波動？A5：如果完全依賴模型，有可能它追求的就是儘可能高的提升資源的利用率，這時候推薦的引數有可能會比較激進，比如記憶體一下子由 30g 縮到 5g。因此除了模型推薦外，我們會增加額外的限制條件，比如調參跨度不能超過多少 g 等，也即緩升緩降策略。Q6：sigmoid 2022 有一些引數調優相關的文章，有進行參考嗎？
A6：任務智慧調參還是比較熱門的研究方向，不同領域的團隊採用了不同的方法模型。我們在著手做之前調研了比較多的業界方法，包括你提到的 sigmoid 2022 論文。經過比較與實踐，最終嘗試了我們分享的這兩種方案。後續我們會繼續關注這個方向的最新進展，嘗試更多方法來提高推薦效果。
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/70024922/viewspace-2938826/，如需轉載，請註明出處，否則將追究法律責任。