偷偷摘套内射激情视频,久久精品99国产国产精,中文字幕无线乱码人妻,中文在线中文a,性爽19p

AI 算法在大數(shù)據(jù)治理中的應(yīng)用

人工智能 大數(shù)據(jù)
普遍觀(guān)念認(rèn)為,云計(jì)算收集存儲(chǔ)海量數(shù)據(jù),從而形成大數(shù)據(jù);再經(jīng)過(guò)對(duì)大數(shù)據(jù)的挖掘?qū)W習(xí),進(jìn)一步形成 AI 模型。這種觀(guān)念默認(rèn)了大數(shù)據(jù)服務(wù)于 AI,但忽視了其實(shí) AI 算法也可以反哺于大數(shù)據(jù),它們之間是一個(gè)雙向、互相支撐、依賴(lài)的關(guān)系。

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

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

圖片

普遍觀(guān)念認(rèn)為,云計(jì)算收集存儲(chǔ)海量數(shù)據(jù),從而形成大數(shù)據(jù);再經(jīng)過(guò)對(duì)大數(shù)據(jù)的挖掘?qū)W習(xí),進(jìn)一步形成 AI 模型。這種觀(guān)念默認(rèn)了大數(shù)據(jù)服務(wù)于 AI,但忽視了其實(shí) AI 算法也可以反哺于大數(shù)據(jù),它們之間是一個(gè)雙向、互相支撐、依賴(lài)的關(guān)系。

圖片

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

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

數(shù)據(jù)傳輸:這個(gè)階段比較關(guān)注數(shù)據(jù)的可用性、完整性和安全性,可以使用 AI 算法來(lái)做一些故障的診斷和入侵檢測(cè)。

數(shù)據(jù)存儲(chǔ):這個(gè)階段比較關(guān)注數(shù)據(jù)的存儲(chǔ)結(jié)構(gòu)是否合理、資源占用是否足夠低、是否足夠安全等,同樣可以用 AI 算法來(lái)做一些評(píng)估以及優(yōu)化。

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

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

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

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

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

在茄子科技,已經(jīng)落地的幾個(gè)應(yīng)用場(chǎng)景,首先是大數(shù)據(jù)任務(wù)健康度的評(píng)估。

圖片

在大數(shù)據(jù)平臺(tái)上,每天運(yùn)行著成千上萬(wàn)的任務(wù)。但是很多任務(wù)僅停留在能正確產(chǎn)數(shù)階段,對(duì)于任務(wù)的運(yùn)行耗時(shí)、資源消耗等并未給予關(guān)注,導(dǎo)致很多任務(wù)存在效率低下、資源浪費(fèi)的情況。

即使有數(shù)據(jù)開(kāi)發(fā)者開(kāi)始關(guān)注任務(wù)健康度,也很難準(zhǔn)確的評(píng)估任務(wù)究竟健康與否。因?yàn)槿蝿?wù)相關(guān)的指標(biāo)非常多,失敗率、耗時(shí)、資源消耗等,況且不同任務(wù)的復(fù)雜度及處理數(shù)據(jù)的體量存在天然差別,因此簡(jiǎn)單選擇某項(xiàng)指標(biāo)的絕對(duì)值作為評(píng)估標(biāo)準(zhǔn)顯然是不合理的。

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

需求:面對(duì)上述難題,我們急需一種量化指標(biāo)來(lái)準(zhǔn)確反映任務(wù)的綜合健康狀況。人工制定規(guī)則的方式效率低且不全面,因此考慮借助機(jī)器學(xué)習(xí)模型的力量。目標(biāo)是模型能給出任務(wù)的量化評(píng)分及其在全局分布中的位置,并且給出任務(wù)的主要問(wèn)題及解決方案。

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

圖片

其次,評(píng)分功能的模型方案,我們是把它作為一個(gè)分類(lèi)問(wèn)題來(lái)處理。直觀(guān)來(lái)看,任務(wù)評(píng)分顯然是一個(gè)回歸問(wèn)題,給出的應(yīng)該是 0 到 100 之間的任意實(shí)數(shù)。但這樣的話(huà)就要求有足夠多的帶評(píng)分的樣本,人工標(biāo)注成本高且不可靠。

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

圖片

模型訓(xùn)練過(guò)程為:

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

圖片

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

圖片

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

模型應(yīng)用之后給我們帶來(lái)了如下收益:

① 首先,任務(wù) owner 對(duì)其名下任務(wù)的健康度可以做到心中有數(shù),通過(guò)分?jǐn)?shù)、排名就能夠知道任務(wù)是否需要治理;

② 量化的指標(biāo)為后續(xù)開(kāi)展任務(wù)治理提供了依據(jù);

③ 任務(wù)治理完成之后取得了多大的收益,有多少提升,同樣可以通過(guò)分?jǐn)?shù)得到量化的展示。

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

圖片

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

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

圖片

對(duì)于任務(wù)調(diào)參功能模塊,我們?cè)O(shè)計(jì)的方案包含兩種情況:第一種是對(duì)于已經(jīng)在線(xiàn)上運(yùn)行了一段時(shí)間的任務(wù),模型要能夠根據(jù)任務(wù)歷史運(yùn)行情況推薦出最合適的配置參數(shù);第二種情況是對(duì)于用戶(hù)還沒(méi)上線(xiàn)的任務(wù),模型要能夠通過(guò)對(duì)任務(wù)的分析給出合理的配置。

圖片

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

圖片

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

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

圖片

?上圖展示的是這個(gè)模型的理論基礎(chǔ)。左側(cè)是一個(gè)多標(biāo)簽,就是三個(gè)配置項(xiàng),β 是每個(gè)特征的系數(shù),Σ 是誤差。訓(xùn)練方式和一元回歸一樣,用最小二乘法去做估計(jì)使得 Σ 中各元素的平方和達(dá)到最小。

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

圖片

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

圖片

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

圖片

未來(lái)的探索方向有以下幾個(gè):

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

分類(lèi)調(diào)優(yōu):Spark 的應(yīng)用場(chǎng)景很多,比如用于純分析、用于開(kāi)發(fā)、用于處理等,不同場(chǎng)景的調(diào)優(yōu)空間與目標(biāo)也是不同的,所以有必要做分類(lèi)調(diào)優(yōu)。

工程優(yōu)化:在實(shí)踐過(guò)程中遇到的一個(gè)困難是樣本較少、測(cè)試成本較高,這需要相關(guān)方共同配合,在工程或流程上做優(yōu)化。

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

第三個(gè)應(yīng)用場(chǎng)景是 SQL 查詢(xún)?nèi)蝿?wù)執(zhí)行引擎的智能選擇。

圖片

背景:

(1)SQL 查詢(xún)平臺(tái)是大多數(shù)用戶(hù)接觸最多的、體驗(yàn)最明顯的一個(gè)大數(shù)據(jù)產(chǎn)品,不管是數(shù)據(jù)分析師、研發(fā),還是產(chǎn)品經(jīng)理,每天都會(huì)寫(xiě)大量 SQL 來(lái)獲取自己想要的數(shù)據(jù);

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

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

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

圖片

在功能模塊上的設(shè)計(jì),當(dāng)用戶(hù)編寫(xiě)完 SQL 語(yǔ)句提交執(zhí)行后,由模型自動(dòng)判斷使用哪種引擎并彈窗提示,由用戶(hù)最終決定是否采用推薦的引擎執(zhí)行。

圖片

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

圖片

經(jīng)過(guò)訓(xùn)練之后,能夠看到模型預(yù)測(cè)的準(zhǔn)確度還是比較高的,大概 90% 以上。

圖片

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

圖片

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

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

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

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

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

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

圖片

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

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

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

Q1:使用的規(guī)則引擎是哪種,是開(kāi)源的嗎?

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

Q2:因變量只有參數(shù)的調(diào)整嗎?是否有考慮到大數(shù)據(jù)平臺(tái)的性能不穩(wěn)定性,對(duì)計(jì)算結(jié)果帶來(lái)的影響?

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

Q3:回歸模型與貝葉斯模型是否同時(shí)使用?

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

Q4:引入語(yǔ)義分析是從拓展更多特征來(lái)考慮的嗎?

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

Q5:參數(shù)推薦是否會(huì)出現(xiàn)參數(shù)推薦不合理,導(dǎo)致任務(wù)異常甚至失敗,然后對(duì)于這樣的場(chǎng)景怎么降低異常任務(wù)報(bào)錯(cuò)和任務(wù)波動(dòng)?

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

Q6:sigmoid 2022 有一些參數(shù)調(diào)優(yōu)相關(guān)的文章,有進(jìn)行參考嗎?

A6:任務(wù)智能調(diào)參還是比較熱門(mén)的研究方向,不同領(lǐng)域的團(tuán)隊(duì)采用了不同的方法模型。我們?cè)谥肿鲋罢{(diào)研了比較多的業(yè)界方法,包括你提到的 sigmoid 2022 論文。經(jīng)過(guò)比較與實(shí)踐,最終嘗試了我們分享的這兩種方案。后續(xù)我們會(huì)繼續(xù)關(guān)注這個(gè)方向的最新進(jìn)展,嘗試更多方法來(lái)提高推薦效果。

今天的分享就到這里,謝謝大家。

責(zé)任編輯:姜華 來(lái)源: DataFunTalk
相關(guān)推薦

2024-07-08 09:11:53

MongoDBAI大數(shù)據(jù)

2021-09-06 15:39:00

大數(shù)據(jù)技術(shù)醫(yī)療

2019-02-20 17:49:32

大數(shù)據(jù)應(yīng)急管理數(shù)據(jù)分析

2022-04-07 12:02:22

區(qū)塊鏈大數(shù)據(jù)數(shù)據(jù)中心

2017-12-26 16:42:41

AI大數(shù)據(jù)征信行業(yè)

2019-06-03 14:06:13

大數(shù)據(jù)智慧交通交通治理

2021-06-10 19:10:32

大數(shù)據(jù)大數(shù)據(jù)應(yīng)用大數(shù)據(jù)技術(shù)

2019-01-16 15:14:14

大數(shù)據(jù)無(wú)錫廣電智慧無(wú)錫

2017-04-12 09:49:54

大數(shù)據(jù)應(yīng)用預(yù)測(cè)性維修

2021-12-02 15:17:42

大數(shù)據(jù)銀行應(yīng)用

2018-10-24 14:36:59

2013-11-19 10:42:45

大數(shù)據(jù)Chef

2017-04-28 11:45:16

大數(shù)據(jù)Kafka大數(shù)據(jù)應(yīng)用

2018-12-11 12:39:17

大數(shù)據(jù)中關(guān)村大數(shù)據(jù)日

2021-09-30 16:28:34

大數(shù)據(jù)數(shù)據(jù)管理企業(yè)

2014-09-22 15:07:03

普元

2019-02-28 22:21:49

大數(shù)據(jù)醫(yī)療業(yè)安全

2021-11-10 19:11:18

大數(shù)據(jù)大數(shù)據(jù)應(yīng)用;農(nóng)村發(fā)展

2018-01-02 12:20:23

農(nóng)業(yè)大數(shù)據(jù)農(nóng)產(chǎn)品

2021-07-21 11:25:17

機(jī)器學(xué)習(xí)?AI人工智能
點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號(hào)