導讀 本文主要分享 Datacake 在大資料治理中，AI 算法的應用經驗。本次分享分為五大部分，第一部分闡明大資料與 AI 的關系，大資料不僅可以服務于 AI，也可以使用 AI 來優化自身服務，兩者是互相支撐、依賴的關系；第二部分介紹利用 AI 模型綜合評估大資料任務健康度的應用實踐，為後續開展資料治理提供量化依據；第三部分介紹利用 AI 模型智能推薦 Spark 任務運作參數配置的應用實踐，實作了提高雲資源使用率的目标；第四部分介紹在 SQL 查詢場景中，由模型智能推薦任務執行引擎的實踐；第五部分展望了在大資料整個生命周期中，AI 的應用場景。
全文目錄：
1. 大資料與 AI
2. 大資料任務健康度評估
3. Spark 任務智能調參
4. SQL 任務執行引擎智能選擇
5. AI 算法在大資料治理中的應用展望
分享嘉賓｜李衛民 快樂茄 算法工程師
編輯整理｜Charles
出品社群｜DataFun
01
大資料與 AI
普遍觀念認為，雲計算收集存儲海量資料，進而形成大資料；再經過對大資料的挖掘學習，進一步形成 AI 模型。這種觀念預設了大資料服務于 AI，但忽視了其實 AI 算法也可以反哺于大資料，它們之間是一個雙向、互相支撐、依賴的關系。
大資料的全生命周期可以分成六個階段，每個階段都面臨一些問題，恰當地使用 AI 算法有助于這些問題的解決。
資料采集：這個階段會比較關注資料采集的品質、頻率、以及安全性，例如采集到的資料是否完整，采集資料的速度是否過快或者過慢，采集的資料是否經過脫敏或者加密等。這時候 AI 可以發揮一些作用，比如基于同類應用來評估日志采集的合理性、使用異常檢測算法來發現資料量暴增或驟減等情況。
資料傳輸：這個階段比較關注資料的可用性、完整性和安全性，可以使用 AI 算法來做一些故障的診斷和入侵檢測。
資料存儲：這個階段比較關注資料的存儲結構是否合理、資源占用是否足夠低、是否足夠安全等，同樣可以用 AI 算法來做一些評估以及優化。
資料處理：這個階段是影響及優化收益最明顯的一個階段，其核心問題就是提高資料的處理效率且降低資源的消耗，AI 可以從多個着手點進行優化。
資料交換：企業之間的合作越來越多，這就會涉及到資料的安全性問題。算法在這方面也可以得到應用，比如時下熱門的聯邦學習就可以幫助更好更安全地進行資料的共享。
資料銷毀：資料不可能隻存不删，這就需要考慮什麼時候可以去删資料、是否有風險。在業務規則的基礎上，AI 算法可以輔助判斷删除資料的時機及關聯影響。
整體來看，資料生命周期管理有三大目标：高效、低成本，以及安全。以往的做法是依靠專家經驗來制定一些規則政策，其弊端非常明顯，成本高、效率低。恰當地采用 AI 算法可以避免這些弊端，反哺于大資料基礎服務的建設。
--
02
大資料任務健康度評估
在茄子科技，已經落地的幾個應用場景，首先是大資料任務健康度的評估。
在大資料平台上，每天運作着成千上萬的任務。但是很多任務僅停留在能正确産數階段，對于任務的運作耗時、資源消耗等并未給予關注，導緻很多任務存在效率低下、資源浪費的情況。
即使有資料開發者開始關注任務健康度，也很難準确的評估任務究竟健康與否。因為任務相關的名額非常多，失敗率、耗時、資源消耗等，況且不同任務的複雜度及處理資料的體量存在天然差别，是以簡單選擇某項名額的絕對值作為評估标準顯然是不合理的。
沒有量化的任務健康度，就很難确定哪些任務不健康、需要治理，更不知道問題在哪裡、從哪着手治理，即使治理完也不知道效果如何，甚至出現某項名額提升但别的名額惡化的情況。
需求：面對上述難題，我們急需一種量化名額來準确反映任務的綜合健康狀況。人工制定規則的方式效率低且不全面，是以考慮借助機器學習模型的力量。目标是模型能給出任務的量化評分及其在全局分布中的位置，并且給出任務的主要問題及解決方案。
對此需求，我們的功能子產品方案是，在管理界面顯示 owner 名下所有任務的關鍵資訊，如評分、任務成本、CPU 使用率、記憶體使用率等。這樣任務的健康度一目了然，友善後續由任務 owner 去做任務的治理。
其次，評分功能的模型方案，我們是把它作為一個分類問題來處理。直覺來看，任務評分顯然是一個回歸問題，給出的應該是 0 到 100 之間的任意實數。但這樣的話就要求有足夠多的帶評分的樣本，人工标注成本高且不可靠。
是以我們考慮将問題轉化為分類問題，分類模型給出的類别機率可以進一步映射為實數分值。我們将任務分為好任務 1 和壞任務 0 兩類，由大資料工程師标注。所謂好任務，通常是指同等任務量與複雜度的情況下，耗時短、資源消耗少的任務。
模型訓練過程為：
首先是樣本準備，我們的樣本來自于曆史運作的任務資料，樣本特征包括運作時間、使用的資源、是否執行失敗等等，樣本标簽是由大資料工程師根據規則或經驗标注成好、壞兩類。然後就可以訓練模型了，我們先後嘗試過 LR、GBDT、XGboost 等模型，理論及實踐均證明 XGboost 具有更好的分類效果。模型最終會輸出任務為“好任務”的機率，該機率越大，最終映射出的任務評分就越高。
經過訓練之後，從最初将近 50 個原始特征裡面篩選出 19 個特征，這 19 個特征基本上能夠決定一個任務是否是一個好的任務。比如失敗次數多的任務、資源使用率低的任務，大部分得分不會太高，與人工的主觀感受基本一緻。
使用模型對任務打分後可以看到，在 0 到 30 分以下屬于不太健康的、急需要治理的任務；30 到 60 之間的是健康度尚可的任務；60 分以上的是健康度比較好的，需要保持現狀的任務。這樣有了量化名額，就可以引導任務 owner 去積極地做一些任務的治理，進而實作降本增效的目标。
模型應用之後給我們帶來了如下收益：
① 首先，任務 owner 對其名下任務的健康度可以做到心中有數，通過分數、排名就能夠知道任務是否需要治理；
② 量化的名額為後續開展任務治理提供了依據；
③ 任務治理完成之後取得了多大的收益，有多少提升，同樣可以通過分數得到量化的展示。
--
03
Spark 任務智能調參
第二個應用場景是 Spark 任務的智能調參。Gartner 的一項調研揭示，雲使用者消耗的 70% 的雲資源都存在不必要的浪費。在申請雲資源時，很多人為了確定任務的成功執行，可能會去多申請一些資源，這就會造成不必要的浪費。還有很多人在建立任務時采用了預設配置，但其實這并不是最優配置。如果能夠認真配置，可以達到非常好的效果，既能保證運作效率，又能保證運作成功，同時還能夠節省很多的資源。但任務參數配置對使用者有很高的要求，除了了解配置項的含義，還需要考慮配置項之間的關聯影響。即使依賴專家經驗也很難達到最優，而且規則類的政策難以動态調整。
這就提出一個需求，希望由模型智能地推薦出任務運作最優的參數配置，使得在保持任務原有運作時間不變長的前提下，提高任務雲資源的使用率。
對于任務調參功能子產品，我們設計的方案包含兩種情況：第一種是對于已經線上上運作了一段時間的任務，模型要能夠根據任務曆史運作情況推薦出最合适的配置參數；第二種情況是對于使用者還沒上線的任務，模型要能夠通過對任務的分析給出合理的配置。
接下來就是訓練模型了，首先要确定模型的輸出目标。可配置項有三百多條，不可能都由模型給出。經過測試與調研，我們選擇了三項對任務運作性能影響最大的參數，分别是執行器 executor 的 cores 核心數、memory 記憶體總量、instances 執行個體個數。每個配置項都有其預設值及可調範圍，其實就是給定了一個參數空間，模型隻需要在這個空間裡去尋找最優解即可。
訓練階段，有兩種方案來進行。方案一是學習經驗規則：前期采用規則的方式推薦參數，上線之後效果還不錯，是以先讓模型來學習這套規則，進而達到快速上線的目标。模型訓練樣本是之前根據規則計算出來的七萬餘條任務配置，樣本特征是任務的曆史運作資料（比如任務處理的資料量、資源的使用量、任務耗時等），以及一些統計資訊（比如過去七日的平均耗量、最大耗量等）。
基礎模型我們選擇了多因變量的多元回歸模型。常見的回歸模型是單輸出的，有很多自變量但隻有一個因變量。這裡我們希望能輸出三個參數，是以采用的是多因變量的多元回歸模型，它的本質還是一個 LR 模型。
上圖展示的是這個模型的理論基礎。左側是一個多标簽，就是三個配置項，β 是每個特征的系數，Σ 是誤差。訓練方式和一進制回歸一樣，用最小二乘法去做估計使得 Σ 中各元素的平方和達到最小。
方案一的好處，就是能快速學到規則經驗，成本也是比較小的。缺陷是其優化上限最多能達到和規則一樣好的效果，但如果想超過會比較困難。
第二種方案是貝葉斯優化，其思路和強化學習比較類似，通過在參數空間裡做嘗試尋找最優配置。這裡采用了貝葉斯架構，原因是其能夠利用上一次嘗試的基礎，在下次嘗試時就會有一些先驗的經驗，能夠快速找到較優位置。整個訓練過程會在一個參數空間裡面進行，随機采樣一種配置來做驗證，然後去運作；運作之後會關注一些名額，比如使用率、成本等，判斷是不是最優；然後重複以上步驟，直到調優完成。模型訓練好後，在使用過程中也有一個取巧的過程，假如新任務和曆史任務有一定的相似度，就不需要再去計算一遍配置，直接采用以往的最優配置即可。
經過這兩種方案的嘗試和實踐，能夠看到取得了一定的效果。對于已有的任務，按照模型推薦的配置參數來做修改後，80% 以上的任務能夠實作大概 15% 的資源使用率的提升，部分任務資源的使用率甚至是翻倍的。但這兩種方案其實都存在缺陷：學習規則的回歸模型，其優化上限較低；全局尋優的貝葉斯優化模型，缺點是要做各種嘗試，成本太高。
未來的探索方向有以下幾個：
語義分析：Spark 語義是比較豐富的，包含不同的代碼結構和算子函數，其與任務參數配置、資源消耗息息相關。但是目前我們利用的隻是任務的曆史運作情況，忽略了 Spark 語義本身，這就是一種資訊的浪費。接下來要做的是滲透到代碼層面，分析 Spark 任務中包含的算子函數，據此做更細粒度的調優。
分類調優：Spark 的應用場景很多，比如用于純分析、用于開發、用于處理等，不同場景的調優空間與目标也是不同的，是以有必要做分類調優。
工程優化：在實踐過程中遇到的一個困難是樣本較少、測試成本較高，這需要相關方共同配合，在工程或流程上做優化。
--
04
SQL 任務執行引擎智能選擇
第三個應用場景是 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 算法向大資料的反哺。
--
05
AI 算法在大資料治理中的應用展望
最後我們展望一下 AI 算法在大資料治理中的應用場景。
以上介紹的三個應用場景，比較集中在資料處理階段。其實呼應一下第一章講的 AI 和大資料的關系，在整個資料生命周期裡，AI 都能發揮比較好的作用。
比如在資料采集階段，能夠判斷日志是否合理；傳輸時能夠去做入侵檢測；處理時，還可以再進一步的降本增效；交換時去做一些保障資料安全的工作；銷毀時能夠去判斷銷毀的時機與關聯影響等。AI 在大資料平台的應用場景是非常多的，這裡僅是抛磚引玉。相信未來 AI 與大資料的互相支撐關系會更加凸顯，AI 輔助大資料平台更好地去采集處理資料，更好的資料品質後續又能幫助訓練更好的 AI 模型，進而實作良性循環。
--
06
問答環節
Q1：使用的規則引擎是哪種，是開源的嗎？
A1：這裡所謂的調參規則是前期我們大資料同僚根據手動調優經驗制定的，比如任務的執行時間超出多少分鐘、或者處理的資料量超出多大，給任務推薦多少核心數或者記憶體量等。這是一套經過長時間積累形成的規則，而且上線後效果比較好，是以使用這一套規則來訓練我們的參數推薦模型。
Q2：因變量隻有參數的調整嗎？是否有考慮到大資料平台的性能不穩定性，對計算結果帶來的影響？
A2：在做參數推薦的時候，我們并不是隻一味的追求成本要低，否則推薦的資源會偏低導緻任務失敗。因變量确實隻有參數調整，但為了防止不穩定性我們加了額外限制。首先是模型特征，我們選取的是某段時間的平均值而非孤立某天的數值；其次對于模型推薦的參數，我們會比較其與實際配置值之間的差别，如果差别過大則會采用緩升緩降政策，避免一次性調整過大導緻任務失敗。
Q3：回歸模型與貝葉斯模型是否同時使用？
A3：不是的。剛剛講到在做參數推薦這塊，我們是有用過兩種方案：學習規則用的是回歸模型；再往後是用的貝葉斯優化的架構。它們兩個并不是同時使用的，我們是做了兩種嘗試。前一種學習規則，好處就是能夠快速的把曆史以往的經驗給使用起來；第二個模型在前一個的基礎上，能夠去尋找一個更優，甚至是最優的配置。他們兩個是屬于一種先後的，或者是遞進的關系，而不是同時使用。
Q4：引入語義分析是從拓展更多特征來考慮的嗎？
A4：是的。剛剛有講到，在做 Spark 調參的時候我們用到的資訊隻有它的曆史執行情況，但對于 Spark 任務本身目前還沒去關注。Spark 本身其實包含非常多的資訊，有各種各樣的算子、階段等。如果不去分析它的語義，會丢失很多資訊。是以我們下一步的計劃就是去分析 Spark 任務的語義，拓展更多的特征來輔助參數計算。
Q5：參數推薦是否會出現參數推薦不合理，導緻任務異常甚至失敗，然後對于這樣的場景怎麼降低異常任務報錯和任務波動？
A5：如果完全依賴模型，有可能它追求的就是盡可能高的提升資源的使用率，這時候推薦的參數有可能會比較激進，比如記憶體一下子由 30g 縮到 5g。是以除了模型推薦外，我們會增加額外的限制條件，比如調參跨度不能超過多少 g 等，也即緩升緩降政策。
Q6：sigmoid 2022 有一些參數調優相關的文章，有進行參考嗎？
A6：任務智能調參還是比較熱門的研究方向，不同領域的團隊采用了不同的方法模型。我們在着手做之前調研了比較多的業界方法，包括你提到的 sigmoid 2022 論文。經過比較與實踐，最終嘗試了我們分享的這兩種方案。後續我們會繼續關注這個方向的最新進展，嘗試更多方法來提高推薦效果。
今天的分享就到這裡，謝謝大家。
｜分享嘉賓｜
｜DataFun新媒體矩陣｜
｜關于DataFun｜
專注于大資料、人工智能技術應用的分享與交流。發起于2017年，在北京、上海、深圳、杭州等城市舉辦超過100+線下和100+線上沙龍、論壇及峰會，已邀請超過2000位專家和學者參與分享。其公衆号 DataFunTalk 累計生産原創文章900+，百萬+閱讀，16萬+精準粉絲。