在建設(shè)機(jī)器學(xué)習(xí)平臺(tái)之前，愛奇藝已經(jīng)擁有比較成熟的深度學(xué)習(xí)平臺(tái)Javis，但是Javis面向的用戶比較高階、專業(yè)的算法工程師，需要通過提交代碼到專用計(jì)算集群上運(yùn)行計(jì)算，使用門檻比較高。

另外，算法除了深度學(xué)習(xí)以外，機(jī)器學(xué)習(xí)，數(shù)據(jù)挖掘、數(shù)據(jù)分析等領(lǐng)域。對(duì)于有很多規(guī)模較小的業(yè)務(wù)，沒有相對(duì)應(yīng)的平臺(tái)支持這些非深度學(xué)習(xí)，需要獨(dú)立開發(fā)算法和工程平臺(tái)來(lái)支撐落地。

這就是常說(shuō)的造煙囪，每個(gè)業(yè)務(wù)要自己搭建算法平臺(tái)，這很容易出現(xiàn)兩個(gè)問題：一個(gè)是在算法方面，很多業(yè)務(wù)不是基于算法為核心打造業(yè)務(wù)，使用機(jī)器學(xué)習(xí)或許僅僅是用于輔助或優(yōu)化業(yè)務(wù)，所以可能并沒有很專業(yè)的算法人員對(duì)模型或者算法有比較深入的理解;另外一個(gè)問題，雖然有算法人員，但是對(duì)算法的落地其實(shí)還是要做一些工程方面的東西，對(duì)于不同業(yè)務(wù)來(lái)說(shuō)屬于重復(fù)造輪子。

此外對(duì)于愛奇藝的數(shù)據(jù)中臺(tái)戰(zhàn)略來(lái)說(shuō)，智能服務(wù)是數(shù)據(jù)中臺(tái)的必要功能。

從以上三點(diǎn)來(lái)看，建設(shè)機(jī)器學(xué)習(xí)平臺(tái)就有了比較清晰的定位。

機(jī)器學(xué)習(xí)平臺(tái)的服務(wù)的人群包括算法工程師、數(shù)據(jù)分析師，也包括業(yè)務(wù)研發(fā)工程師，我們希望通過構(gòu)建高效的離線、實(shí)時(shí)預(yù)測(cè)服務(wù)，降低用戶使用機(jī)器學(xué)習(xí)的成本，提高接入算法的效率，利用數(shù)據(jù)中臺(tái)的優(yōu)勢(shì)促進(jìn)數(shù)據(jù)和模型的規(guī)范和分享。

發(fā)展歷程

簡(jiǎn)單介紹一下愛奇藝機(jī)器學(xué)習(xí)平臺(tái)的發(fā)展歷程。

截止目前主要是經(jīng)歷了三個(gè)大版本，第一版也是基于業(yè)務(wù)造煙囪的階段。這一版由于圍繞具體業(yè)務(wù)搭建服務(wù)，所以整個(gè)架構(gòu)里面算法部分很少，但是在這一版本我們通過Spark ML調(diào)度算法的核心系統(tǒng)，實(shí)現(xiàn)了算法的異步分布式調(diào)度。上線后對(duì)算法接入的效率提升非常明顯。

在第一版積累的技術(shù)經(jīng)驗(yàn)基礎(chǔ)上，我們發(fā)現(xiàn)當(dāng)前通用機(jī)器學(xué)習(xí)平臺(tái)的需求，于是迭代了第二版，實(shí)現(xiàn)面向通用需求的機(jī)器學(xué)習(xí)平臺(tái)。

第二版里最顯著的特征，是在用戶層增加了可視化前端，可以通過拖拉拽的方式讓用戶組建自己的機(jī)器學(xué)習(xí)流程。用戶通過自由拼搭算法組件，解決了通用化后百花齊放的流程需求。

另外一個(gè)重點(diǎn)是把調(diào)度服務(wù)獨(dú)立出來(lái)。其中，實(shí)驗(yàn)調(diào)度子系統(tǒng)對(duì)任務(wù)狀態(tài)進(jìn)行監(jiān)控，負(fù)責(zé)任務(wù)的調(diào)度，通過對(duì)任務(wù)心跳匯總，隨時(shí)能了解任務(wù)集群全局的狀態(tài)，當(dāng)任務(wù)執(zhí)行節(jié)點(diǎn)出現(xiàn)異常中斷時(shí)，能第一時(shí)間重試或重新分發(fā)到其他節(jié)點(diǎn)，極大保證了服務(wù)的穩(wěn)定性。

任務(wù)執(zhí)行引擎是任務(wù)運(yùn)行的核心。任務(wù)執(zhí)行引擎接收實(shí)驗(yàn)調(diào)度服務(wù)推送來(lái)的任務(wù)，根據(jù)任務(wù)配置的內(nèi)容從模型池獲取模型資源、從數(shù)據(jù)管理子系統(tǒng)讀寫數(shù)據(jù)、執(zhí)行腳本。由于任務(wù)執(zhí)行引擎不綁定任何具體的算法框架，實(shí)現(xiàn)算法執(zhí)行能輕松跨越不同算法框架和平臺(tái)。

通過消息日志監(jiān)控，自動(dòng)收集調(diào)度各個(gè)算法和平臺(tái)產(chǎn)生的日志信息和終端信息，并通過配置關(guān)鍵字的方式提取有用的信息和數(shù)據(jù)，在前端聚合展示，或?qū)崿F(xiàn)某些功能的即時(shí)圖表功能。

算法模型池也作為獨(dú)立服務(wù)進(jìn)行管理，專門負(fù)責(zé)離線和實(shí)時(shí)預(yù)測(cè)獲取模型和同步模型。

系統(tǒng)舍棄了v1中的通過Europa調(diào)度Spark集群任務(wù)，以及自己維護(hù)的定時(shí)任務(wù)，接入愛奇藝的大數(shù)據(jù)平臺(tái)Babel和定時(shí)任務(wù)調(diào)度服務(wù)平臺(tái)Gear。接入這兩個(gè)平臺(tái)以后一來(lái)實(shí)現(xiàn)了和數(shù)據(jù)中臺(tái)的打通，二來(lái)實(shí)現(xiàn)了離線服務(wù)。

在算法的框架上，由于把執(zhí)行引擎分離出來(lái)了，所以可以很輕松的加入更多的框架，在第二版里面除了SparkML里面常見的一些算法以外，還擴(kuò)展了常用的像XGBoost和圖類的算法。

3.0的主要目標(biāo)是完善功能版圖，主要實(shí)現(xiàn)了在線預(yù)測(cè)的服務(wù)。針對(duì)用戶提出的一些提高效率的需求，也提供了自動(dòng)調(diào)參、增加參數(shù)服務(wù)器擴(kuò)展了模型數(shù)據(jù)量的支持。另外由于用戶有需求通過別的平臺(tái)接入機(jī)器學(xué)習(xí)平臺(tái)，所以也提供了API服務(wù)。

到目前為止，已經(jīng)形成了一站式平臺(tái)，基本覆蓋了機(jī)器學(xué)習(xí)全流程。通過平臺(tái)操作，用戶可以從特征工程到模型訓(xùn)練、模型評(píng)估、在線和離線預(yù)測(cè)實(shí)現(xiàn)了整套機(jī)器學(xué)習(xí)的流程。通過把機(jī)器學(xué)習(xí)流程的數(shù)據(jù)源和數(shù)據(jù)目的接入整個(gè)大數(shù)據(jù)開發(fā)平臺(tái)，完成了一整套的閉環(huán)。

系統(tǒng)經(jīng)驗(yàn)

分享在實(shí)際過程中的一些經(jīng)驗(yàn)。

自動(dòng)調(diào)參

當(dāng)用戶在具體做一個(gè)模型調(diào)優(yōu)的時(shí)候，如果模型的參數(shù)設(shè)置不對(duì)的話，很影響模型的準(zhǔn)確率。模型的參數(shù)也并不相同，像LR、線性回歸4個(gè)參數(shù)，多的像XGBoost暴露出17個(gè)參數(shù)，雖然不是每個(gè)參數(shù)都參與調(diào)參，但是總是會(huì)遇到一些排列組合。如果人工調(diào)參，參數(shù)組少則幾十，多則上百種組合。比如XGBoost，使用人力來(lái)調(diào)參基本不可想象。

目前的機(jī)器學(xué)習(xí)框架，普遍自帶調(diào)參功能，比如Spark ML，但是調(diào)參能力相當(dāng)有限，因?yàn)橹荒茏鲭S機(jī)和全組合(窮舉搜索)。使用Spark自帶的調(diào)參方法，如果用戶沒有一點(diǎn)直覺經(jīng)驗(yàn)排除調(diào)參區(qū)間，那就需要拼計(jì)算資源或者人品。

算法框架自帶的調(diào)參系統(tǒng)還有另一個(gè)局限性，就是無(wú)法跨平臺(tái)復(fù)用調(diào)參算法。因此我們?cè)O(shè)計(jì)一個(gè)系統(tǒng)層面的調(diào)參框架，可以調(diào)用Spark、python等不同算法框架，也可以不局限在算法框架語(yǔ)言限制內(nèi)開發(fā)自己的調(diào)參算法。

我們的自動(dòng)調(diào)參的系統(tǒng)從流程上來(lái)看比較簡(jiǎn)單。系統(tǒng)把調(diào)參分為多輪次迭代進(jìn)行。傳統(tǒng)調(diào)參算法比如隨機(jī)調(diào)參、網(wǎng)格搜索調(diào)參只有一輪，高級(jí)的算法會(huì)有多輪調(diào)參，通過前一輪調(diào)參的評(píng)估結(jié)果適當(dāng)縮小調(diào)參區(qū)間，最終把參數(shù)收斂到一個(gè)最優(yōu)值。

系統(tǒng)讀取用戶設(shè)置的參數(shù)區(qū)間后，根據(jù)用戶的需求把區(qū)間劃分為多個(gè)子區(qū)間，并在每個(gè)子區(qū)間隨機(jī)采樣參數(shù)作為首次調(diào)參的組合，并通過任務(wù)分發(fā)服務(wù)下發(fā)給執(zhí)行引擎，調(diào)度對(duì)應(yīng)的算法框架訓(xùn)練和評(píng)估。訓(xùn)練任務(wù)結(jié)束后，執(zhí)行引擎把評(píng)估結(jié)果返回給調(diào)參服務(wù)。

收集到當(dāng)前輪次所有評(píng)估結(jié)果后，調(diào)參服務(wù)調(diào)起算法計(jì)算下一輪的調(diào)參空間，并調(diào)整下一輪的取樣個(gè)數(shù)，再次下發(fā)給執(zhí)行引擎測(cè)試，循環(huán)往復(fù)，直到達(dá)到最大輪次限制或收斂程度。

我們可以把整個(gè)調(diào)參流程看做是一個(gè)大型的模型訓(xùn)練過程，通過結(jié)果反饋不斷找到極值的過程。從這種思路出發(fā)，可以加入很多適用的算法作為調(diào)參算法。

目前機(jī)器學(xué)習(xí)平臺(tái)除了支持隨機(jī)算法和網(wǎng)格搜索的算法，也實(shí)現(xiàn)了貝葉斯優(yōu)化以及自研的遺傳算法。測(cè)試發(fā)現(xiàn)自研的算法調(diào)參效率遠(yuǎn)優(yōu)于傳統(tǒng)默認(rèn)的算法。

數(shù)據(jù)規(guī)模的支持

系統(tǒng)初期只支持SparkML框架，正常訓(xùn)練萬(wàn)級(jí)別的數(shù)據(jù)集幾分鐘能訓(xùn)練完成，但是當(dāng)用戶數(shù)據(jù)集只有幾十到幾百數(shù)量級(jí)時(shí)，任務(wù)也需要跑幾分鐘，相對(duì)于單機(jī)的python秒級(jí)訓(xùn)練完成的時(shí)間來(lái)說(shuō)相當(dāng)慢。其中一個(gè)原因是任務(wù)提交到Spark集群上需要等待資源分配。真正訓(xùn)練時(shí)間短，但其他的準(zhǔn)備時(shí)間也讓用戶覺得很慢。所以我們?cè)诤罄m(xù)版本把python的單機(jī)的引擎也引用進(jìn)來(lái)。當(dāng)數(shù)據(jù)量小的時(shí)候用戶可以直接在單機(jī)上做這種操作。

另一方面，在訓(xùn)練億級(jí)以上的數(shù)據(jù)量時(shí)傳統(tǒng)的SparkML訓(xùn)練相當(dāng)慢甚至崩潰失敗。這是因?yàn)镾park對(duì)超大規(guī)模的模型的訓(xùn)練并不擅長(zhǎng)，Spark訓(xùn)練模型分多輪迭代，每一輪需要所有的執(zhí)行器的任務(wù)做完后才匯總參數(shù)，根據(jù)木桶原理，整個(gè)Spark任務(wù)會(huì)受到最慢的worker運(yùn)行時(shí)間影響。

另外，所有的執(zhí)行器會(huì)通過廣播的方式對(duì)參數(shù)進(jìn)行共享，對(duì)于大規(guī)模參數(shù)量的模型來(lái)說(shuō)相當(dāng)占網(wǎng)絡(luò)帶寬，也會(huì)導(dǎo)致系統(tǒng)使用率效果非常低。

解決方案是通過參數(shù)服務(wù)器的方式解決，參數(shù)服務(wù)器本身原理上對(duì)分布式的訓(xùn)練進(jìn)行了一些改良，并不是等所有的執(zhí)行器跑完，等一部分跑完超過一個(gè)預(yù)值強(qiáng)行終止了。為了提高整個(gè)集群的效率犧牲了一些部分的收斂的速度，另外取消了廣播機(jī)制來(lái)傳遞參數(shù)，把參數(shù)放在獨(dú)立的叫做參數(shù)服務(wù)器里面，通過讀取，這樣子也節(jié)省了網(wǎng)絡(luò)的消耗。

愛奇藝的機(jī)器學(xué)習(xí)平臺(tái)在設(shè)計(jì)之初就支持跨算法框架調(diào)度。我們調(diào)研了多種開源的參數(shù)服務(wù)器，最終集成了騰訊的Angel參數(shù)服務(wù)器，并對(duì)一些典型模型做了測(cè)試。測(cè)試證明，在訓(xùn)練億級(jí)以上規(guī)模的模型時(shí)，參數(shù)服務(wù)器的訓(xùn)練效率相對(duì)Spark有明顯提升50%以上的速度。

模型的管理平臺(tái)和算法調(diào)度

不論是Sklearn，還是Spark ML的模型預(yù)測(cè)，從代碼角度來(lái)看，預(yù)測(cè)功能是不同模型內(nèi)部的方法。不存在通用的預(yù)測(cè)方法兼容所有的模型。對(duì)于開發(fā)人員自己寫代碼的時(shí)候沒問題，但如果做一個(gè)通用化的平臺(tái)，需要考慮統(tǒng)一的預(yù)測(cè)組件來(lái)處理所有的模型預(yù)測(cè)，并有一定的擴(kuò)展性，通過一個(gè)預(yù)測(cè)組件兼容不同算法框架的模型。

和預(yù)測(cè)組件類似的另一個(gè)問題是，不同算法模型，甚至跨框架的模型，如何都能統(tǒng)一部署到在線預(yù)測(cè)的服務(wù)中去?

以上2個(gè)問題可以通過自定義模型文件解決。模型訓(xùn)練完后，在默認(rèn)模型文件輸出的同時(shí)，也輸出自定義文件和PMML文件。PMML是一套有標(biāo)準(zhǔn)的模型定義語(yǔ)言，可用于跨平臺(tái)的讀取模型，適合用于離線訓(xùn)練+在線預(yù)測(cè)的場(chǎng)景。另外，在自定義文件里可以輸出更多平臺(tái)有用的信息，比如模型評(píng)估分?jǐn)?shù)、模型類型、模型訓(xùn)練的相關(guān)表和字段名、模型參數(shù)、訓(xùn)練上下文等等。

在模型接入預(yù)測(cè)組件時(shí)，預(yù)測(cè)組件讀取自定義文件，獲取到模型的所在框架和模型類型，并通過對(duì)應(yīng)的模型框架加載模型文件即可。

在在線預(yù)測(cè)中，通過讀取到訓(xùn)練的上下文，可以把模型訓(xùn)練上游所需的預(yù)處理過程一并加載到在線預(yù)測(cè)過程中，減輕用戶單獨(dú)預(yù)處理過程的負(fù)擔(dān)。

在線預(yù)測(cè)系統(tǒng)搭建

在線預(yù)測(cè)系統(tǒng)對(duì)不同用戶的需求場(chǎng)景提供不同的調(diào)用方式。

本地模式是在線預(yù)測(cè)平臺(tái)把模型信息整體自動(dòng)封裝在服務(wù)jar包中，提供給用戶輕量級(jí)調(diào)用;云模式是在線預(yù)測(cè)服務(wù)平臺(tái)結(jié)合Docker服務(wù)，生成一組計(jì)算集群。云模式支持HTTP服務(wù)與RPC服務(wù)。在HTTP服務(wù)中，系統(tǒng)通過Consul服務(wù)申請(qǐng)動(dòng)態(tài)域名，并通過自動(dòng)發(fā)現(xiàn)服務(wù)關(guān)聯(lián)Docker服務(wù)。用戶僅需通過服務(wù)提供的域名訪問，無(wú)需了解后端部署流程。

RPC服務(wù)是基于Dubbo實(shí)現(xiàn)。模型預(yù)測(cè)服務(wù)被Dubbo封裝后通過Docker連接ZooKeeper實(shí)現(xiàn)服務(wù)發(fā)現(xiàn)。用戶端僅需通過客戶端連接指定的連接字即可訪問服務(wù)。

離線預(yù)測(cè)平臺(tái)是基于流程的發(fā)布，在線預(yù)測(cè)則是基于模型和模型上下文信息進(jìn)行發(fā)布。模型管理平臺(tái)中使用推模式和拉模式兩種方式部署在線服務(wù)。拉模式為用戶主動(dòng)更新服務(wù)的模式;而推模式為模型在模型管理平臺(tái)中更新后被動(dòng)更新的方式。通過兩種方式的結(jié)合，在線服務(wù)覆蓋所有模型更新場(chǎng)景。

案例介紹

反作弊業(yè)務(wù)是一個(gè)獨(dú)立的業(yè)務(wù)系統(tǒng)，管理反作弊相關(guān)業(yè)務(wù)邏輯和業(yè)務(wù)數(shù)據(jù)。反作弊平臺(tái)定義和構(gòu)建了不同反作弊識(shí)別過濾場(chǎng)景，并自動(dòng)拆解成工作流在數(shù)據(jù)中臺(tái)中具體運(yùn)維。涉及到算法相關(guān)的流程，通過數(shù)據(jù)中臺(tái)轉(zhuǎn)到機(jī)器學(xué)習(xí)平臺(tái)處理，處理后的結(jié)果也會(huì)回到數(shù)據(jù)中臺(tái)。

下圖中包括了流量反作弊所有的場(chǎng)景和相關(guān)算法，包括常見的監(jiān)督算法，監(jiān)督算法，黑白樣本，然后聚類算法，異常檢測(cè)算法，此外，還有基于團(tuán)伙的同類的算法，和一些深度學(xué)習(xí)的算法。

每天大概能過濾大概千萬(wàn)級(jí)以上的日志，在線預(yù)測(cè)峰值的時(shí)候是要超過能達(dá)到萬(wàn)級(jí)的KPS，所有擁有這么一個(gè)平臺(tái)，效率提升大致在80%以上。