機(jī)器學(xué)習(xí)算法和架構(gòu)在 MLOps 框架下的工程實(shí)踐

本文主要介紹機(jī)器學(xué)習(xí)（以下簡寫為ML）算法和架構(gòu)在MLOps框架下的工程實(shí)踐。

當(dāng)從業(yè)者具備了足夠豐富的知識(shí)儲(chǔ)備時(shí)，就可以開始嘗試ML了。

通常情況下，ML實(shí)踐會(huì)涉及研究和生產(chǎn)兩個(gè)主要環(huán)境。

• 研究環(huán)境可以在本地計(jì)算機(jī)或工作站上，這通常是為了進(jìn)行小規(guī)模的模型分析和探索。

• 生產(chǎn)環(huán)境是模型投產(chǎn)的環(huán)境，ML在生產(chǎn)環(huán)境中通常需要相對長期的持續(xù)運(yùn)行，生產(chǎn)環(huán)境中的任務(wù)一般需要自動(dòng)化和持續(xù)迭代。

下面舉個(gè)僅需要在研究環(huán)境中進(jìn)行數(shù)據(jù)分析或建模即可滿足需求的例子，即在文章標(biāo)題中找到與較高點(diǎn)擊率相關(guān)的關(guān)鍵詞。數(shù)據(jù)分析師的交付方式可能是將探索出的規(guī)律和結(jié)論報(bào)告給一個(gè)運(yùn)營團(tuán)隊(duì)，這樣運(yùn)營人員就可以在新的標(biāo)題中嘗試使用探索出的規(guī)律和結(jié)論來提高點(diǎn)擊率。

再舉一個(gè)數(shù)據(jù)分析和建模需要在研究環(huán)境中完成而建模結(jié)果需要在生產(chǎn)環(huán)境中發(fā)布的例子，該情況下的模型需要不斷迭代，比如在電商網(wǎng)站上運(yùn)行的推薦模型。在生產(chǎn)環(huán)境中運(yùn)行的模型會(huì)涉及后續(xù)的管理和運(yùn)維，當(dāng)運(yùn)行中出現(xiàn)異?；蚰Ｐ退ネ藭r(shí)，需要通過監(jiān)控機(jī)制發(fā)出預(yù)警信號。

這兩類環(huán)境對從業(yè)者的要求很不相同。大多數(shù)初級ML圖書講述的是研究環(huán)境中的ML，很少會(huì)涉及生產(chǎn)環(huán)境中的ML。

一般來說，一個(gè)完備的ML項(xiàng)目的工作流程是，先在研究環(huán)境中探索和開發(fā)ML模型，制作一個(gè)ML應(yīng)用程序的原型，然后符合預(yù)期的模型會(huì)被推送到生產(chǎn)環(huán)境，進(jìn)行自動(dòng)化部署和監(jiān)控。開發(fā)一個(gè)用于生產(chǎn)環(huán)境的ML應(yīng)用程序的工作比分析、探索的工作要復(fù)雜得多，需要把在研究環(huán)境中運(yùn)行的ML作業(yè)轉(zhuǎn)換成能在生產(chǎn)環(huán)境中自動(dòng)運(yùn)行的作業(yè)，我們通常把這一過程稱為ML的生產(chǎn)化或工程化。

回顧前面ML的定義，從廣義上講，ML是一門通過算法和統(tǒng)計(jì)模型從數(shù)據(jù)中學(xué)習(xí)知識(shí)的學(xué)科，ML工程顧名思義就是構(gòu)建基于ML的應(yīng)用程序的計(jì)算實(shí)踐。

ML工程是建立在ML的工作基礎(chǔ)上并將研究環(huán)境中開發(fā)的ML模型應(yīng)用于生產(chǎn)環(huán)境的技術(shù)。ML工程與ML的區(qū)別在于側(cè)重點(diǎn)不同，ML更關(guān)心算法的優(yōu)化和模型的訓(xùn)練，ML工程則更關(guān)心從不同業(yè)務(wù)系統(tǒng)采集數(shù)據(jù)，并訓(xùn)練一個(gè)兼顧模型性能和計(jì)算性能的模型，使其能在生產(chǎn)環(huán)境中穩(wěn)定運(yùn)行，保證模型的可監(jiān)控、可維護(hù)、可更新、可被業(yè)務(wù)系統(tǒng)使用，為模型生產(chǎn)化提供工程保障。

ML工程包括從數(shù)據(jù)收集、特征工程、模型訓(xùn)練到模型投入應(yīng)用、管理和運(yùn)維的所有階段。這個(gè)過程與高中時(shí)期考試的不同階段類似，ML開發(fā)過程相當(dāng)于平時(shí)的?？?，關(guān)心的是對知識(shí)點(diǎn)的消化和總結(jié)，ML工程相當(dāng)于高考，在兼顧平時(shí)?？剂?xí)得的知識(shí)點(diǎn)的同時(shí)，還需要綜合考察實(shí)考環(huán)境下的心理壓力、時(shí)間分配、考題內(nèi)容等因素。

事實(shí)上，數(shù)據(jù)科學(xué)團(tuán)隊(duì)通常專注于研究新穎的算法或訓(xùn)練高精準(zhǔn)的模型，但與實(shí)際ML項(xiàng)目中需要的全流程（如特征工程、部署、監(jiān)控等）相比，ML算法只是ML項(xiàng)目非常小的一部分，一個(gè)真正要投產(chǎn)的ML項(xiàng)目通常需要大量的工程工作和基礎(chǔ)設(shè)施的配合，以實(shí)現(xiàn)ML模型在生產(chǎn)環(huán)境中順利運(yùn)行。

2015年，谷歌發(fā)布的論文指出，為了避免無休止的“技術(shù)債”纏身，應(yīng)該強(qiáng)調(diào)將ML生產(chǎn)化視為一門學(xué)科的重要性（在當(dāng)前的ML技術(shù)主流中確實(shí)如此），通過加強(qiáng)工程技術(shù)的投入來順利實(shí)現(xiàn)ML的生產(chǎn)化。如圖1所示，ML模型的生產(chǎn)化是由多個(gè)模塊組成的，在實(shí)際場景中需要在這些模塊間建立溝通機(jī)制來配合完成ML模型的生產(chǎn)化。

圖1  ML生產(chǎn)化模塊

機(jī)器學(xué)習(xí)工程模塊的設(shè)計(jì)原則

關(guān)注點(diǎn)分離（SoC）是一個(gè)可行的設(shè)計(jì)原則，指的是計(jì)算機(jī)科學(xué)中對應(yīng)用程序、代碼塊和其他對象系統(tǒng)進(jìn)行劃分的方式，關(guān)注點(diǎn)被“分離”的程度因系統(tǒng)而異。比如，一個(gè)存在相互依存關(guān)系的系統(tǒng)一般是關(guān)注點(diǎn)的弱分離，簡稱弱分離；而一個(gè)可以完全獨(dú)立負(fù)責(zé)自己工作的系統(tǒng)或模塊，一般認(rèn)為是關(guān)注點(diǎn)的強(qiáng)分離，簡稱強(qiáng)分離。

ML 工程模塊的設(shè)計(jì)既可以使用弱分離的設(shè)計(jì)原則，也可以使用強(qiáng)分離的設(shè)計(jì)原則。在弱分離的設(shè)計(jì)原則下，訓(xùn)練和預(yù)測必須在同一臺(tái)服務(wù)器上運(yùn)行，訓(xùn)練步驟和預(yù)測步驟被捆綁在同一個(gè)模塊中。比如，在輸入數(shù)據(jù)上調(diào)用一個(gè)名為train的函數(shù)，該函數(shù)返回一個(gè)模型，該模型會(huì)作為predict函數(shù)的輸入，在運(yùn)行時(shí)會(huì)按順序依次執(zhí)行train和predict函數(shù)。而在強(qiáng)分離的設(shè)計(jì)原則下，訓(xùn)練和預(yù)測可以在兩個(gè)不同的服務(wù)器或進(jìn)程中運(yùn)行。在這種情況下，訓(xùn)練和預(yù)測是相互獨(dú)立發(fā)生的，訓(xùn)練步驟和預(yù)測步驟分別歸屬不同的模塊。

一般來說，面向服務(wù)的架構(gòu)（SOA）是符合強(qiáng)分離設(shè)計(jì)原則的，我們認(rèn)為在生產(chǎn)場景下使用SOA來設(shè)計(jì)和開發(fā)ML系統(tǒng)是可行的。

此外，無論是設(shè)計(jì)MLOps平臺(tái)還是傳統(tǒng)的ML系統(tǒng)，建議在設(shè)計(jì)時(shí)考慮以下幾項(xiàng)關(guān)鍵原則。

• 從一開始就為可重復(fù)性而構(gòu)建：保留所有模型的輸入和輸出，以及所有相關(guān)元數(shù)據(jù)，如配置信息、依賴項(xiàng)、操作時(shí)間戳等。注意版本控制，包括所用的訓(xùn)練數(shù)據(jù)。

• 將ML過程中的不同管道視為系統(tǒng)的一部分：如特征工程、自動(dòng)化訓(xùn)練、模型部署和發(fā)布等。

• 提前考慮可擴(kuò)展性：如果系統(tǒng)需要定期更新模型，則需要在設(shè)計(jì)系統(tǒng)的時(shí)候就仔細(xì)考慮如何做到這一點(diǎn)。

• 模塊化：盡可能地對ML生命周期的各個(gè)環(huán)節(jié)進(jìn)行模塊化，這會(huì)極大地提高系統(tǒng)的復(fù)用性。

• 測試：需要預(yù)留一定的時(shí)間來測試ML的應(yīng)用程序，包括模型、數(shù)據(jù)及代碼等不同類型實(shí)例的測試。

進(jìn)行機(jī)器學(xué)習(xí)工程的模塊設(shè)計(jì)時(shí)需要注意的細(xì)節(jié)

設(shè)計(jì)架構(gòu)和模塊的出發(fā)點(diǎn)應(yīng)該是滿足業(yè)務(wù)需求和公司更長遠(yuǎn)的目標(biāo)。在開始設(shè)計(jì)和使用最新技術(shù)之前，需要了解現(xiàn)有條件的限制、預(yù)期會(huì)創(chuàng)造的價(jià)值及在為誰創(chuàng)造價(jià)值等，需要考慮當(dāng)前公司的業(yè)務(wù)場景及未來可能會(huì)新增的場景。比如，在現(xiàn)有的業(yè)務(wù)場景下是否需要提供實(shí)時(shí)預(yù)測？如果需要實(shí)時(shí)預(yù)測，那么業(yè)務(wù)側(cè)允許的延遲是毫秒級的還是秒級的，又或者只需在接收輸入數(shù)據(jù)后的30分鐘或一天內(nèi)交付預(yù)測結(jié)果就能滿足需求。

具體地，以下幾個(gè)細(xì)節(jié)值得考慮。

• 針對公司業(yè)務(wù)，希望多久更新一次模型？

• 預(yù)測的需求（流量）是什么？

• 需要處理多大量級的數(shù)據(jù)？

• 希望使用哪些算法？比如，是否會(huì)使用深度網(wǎng)絡(luò)類的算法（需要評估是否真的需要）？

• 是否處在一個(gè)對系統(tǒng)審計(jì)要求非常高的監(jiān)管環(huán)境中？

• 當(dāng)前要設(shè)計(jì)的ML系統(tǒng)是在之前的基礎(chǔ)上升級的還是重構(gòu)的？

• 當(dāng)前的工程團(tuán)隊(duì)有多大？是否包含了數(shù)據(jù)科學(xué)家、ML工程師及DevOps工程師等？當(dāng)前團(tuán)隊(duì)是否有開發(fā)ML系統(tǒng)的經(jīng)驗(yàn)？

一旦團(tuán)隊(duì)對這些基礎(chǔ)問題進(jìn)行了評估，便可以在此基礎(chǔ)上考慮ML系統(tǒng)的一些高級體系結(jié)構(gòu)選項(xiàng)，比如，打造獨(dú)立的模型訓(xùn)練系統(tǒng)、模型服務(wù)系統(tǒng)，抑或全流程的MLOps平臺(tái)。

需要注意的是，為了避免從業(yè)者在使用上混淆“系統(tǒng)”和“平臺(tái)”，這里對二者的定義進(jìn)行說明。

系統(tǒng)通常指的是一個(gè)具體的軟件，而平臺(tái)則是指進(jìn)行某項(xiàng)工作所需的信息化環(huán)境或條件，是一個(gè)相對抽象的生態(tài)環(huán)境。系統(tǒng)強(qiáng)調(diào)的是功能，平臺(tái)側(cè)重的是場景。系統(tǒng)有明確的輸入、處理過程和輸出，而平臺(tái)則是基于同一套規(guī)則和體系，由多個(gè)主體共同參與的生態(tài)圈，這套規(guī)則和體系往往是由系統(tǒng)組成的。

編碼環(huán)境與模型探索

如果數(shù)據(jù)科學(xué)家在研究環(huán)境中使用的編程語言與生產(chǎn)環(huán)境中的一致，那么整個(gè)工作流程的處理會(huì)輕松一些，這里涉及的編程語言通常是Python語言，因?yàn)樗鼡碛胸S富的關(guān)于數(shù)據(jù)科學(xué)和數(shù)據(jù)處理的開源代碼和包。然而，如果運(yùn)行速度是一個(gè)要考慮的選項(xiàng)，那么Python語言可能是不可行的（盡管有很多種方法可以幫助其進(jìn)一步優(yōu)化運(yùn)行速度）。

出于性能的考慮，何時(shí)進(jìn)行語言的轉(zhuǎn)換變得格外重要，因?yàn)檠芯繄F(tuán)隊(duì)和生產(chǎn)團(tuán)隊(duì)之間的額外溝通成本將會(huì)成為一個(gè)很大的負(fù)擔(dān)。當(dāng)然，如果你周圍所有的數(shù)據(jù)科學(xué)家都精通Scala、Java或C++語言，那么這個(gè)問題就變得簡單多了。

當(dāng)然，不同的角色可能會(huì)使用不同的工具或編程語言，沒有一個(gè)工具可以涵蓋所有任務(wù)，更重要的是，單個(gè)任務(wù)通常需要多個(gè)角色和多個(gè)工具來協(xié)作實(shí)現(xiàn)。以分析工程師、數(shù)據(jù)科學(xué)家和數(shù)據(jù)工程師為例，如圖2所示，數(shù)據(jù)工程師可能會(huì)使用IntelliJ中的Scala創(chuàng)建包含數(shù)億個(gè)事件的數(shù)據(jù)集的聚合，分析工程師可能會(huì)在相關(guān)業(yè)務(wù)的分析報(bào)告中使用SQL和Tableau對該聚合進(jìn)行分析和可視化，而數(shù)據(jù)科學(xué)家可能會(huì)使用Python處理該聚合并參考分析工程師的分析結(jié)果進(jìn)行線上營銷模型的構(gòu)建。

圖2  工具和編程語言偏好因角色而異的示例

從表面上看，這三種角色的工作流程看似不同，但其實(shí)他們的工作內(nèi)容通常是互補(bǔ)的，不同角色所負(fù)責(zé)的工作流程中的任務(wù)也會(huì)有重疊，為了進(jìn)一步促進(jìn)團(tuán)隊(duì)間合作，我們希望盡可能減少平臺(tái)需要支持的工具的數(shù)量，在這些工具和語言的上層添加一層抽象，以提供跨工具和編程語言的通用模式，這也是MLOps的理念。

幸運(yùn)的是，有一個(gè)開源項(xiàng)目Jupyter（該項(xiàng)目也是當(dāng)前數(shù)據(jù)科學(xué)家最常用的開源項(xiàng)目之一）的設(shè)計(jì)做到了這一點(diǎn)。當(dāng)前市面上很多專攻MLOps領(lǐng)域的公司都是使用Jupyter來提供建?；蚍治霏h(huán)境的，如cnvrg.io、Domino Data Lab、InfuseAI等。其中InfuseAI公司旗下的PrimeHub平臺(tái)最初就是從提供在線Jupyter建模環(huán)境開始的，后來才慢慢增加了模型部署和管理等功能，并逐步擴(kuò)展成為MLOps平臺(tái)。

Jupyter提供了一個(gè)標(biāo)準(zhǔn)的消息傳遞API協(xié)議與充當(dāng)計(jì)算引擎的內(nèi)核進(jìn)行通信，該協(xié)議啟用了一個(gè)可組合的架構(gòu)，將編寫代碼內(nèi)容的位置（UI）和執(zhí)行代碼的位置（內(nèi)核）分開。通過將運(yùn)行時(shí)與UI界面隔離（實(shí)際上MLOps的設(shè)計(jì)也借鑒了類似的思路），Jupyter可以跨越多種編程語言，同時(shí)保持執(zhí)行環(huán)境配置方式的靈活性。

具體地，隨著新的ML開發(fā)框架不斷興起并取代傳統(tǒng)工具，不建議對MLOps平臺(tái)支持的語言或框架制定限制性的標(biāo)準(zhǔn)。MLOps平臺(tái)的設(shè)計(jì)應(yīng)該足夠靈活并模塊化，以支持添加新框架，比如，需要能夠隨意加載TensorFlow、PyTorch和Scikit-Learn這些數(shù)據(jù)科學(xué)家必備的工具或框架。不過在MLOps框架內(nèi)搭建Jupyter環(huán)境時(shí)要注意一點(diǎn)，需要按用戶或項(xiàng)目生成隔離空間，比如，將新增的Jupyter服務(wù)創(chuàng)建在Python的虛擬環(huán)境中，或者使用容器進(jìn)行創(chuàng)建，因?yàn)椴煌捻?xiàng)目或不同的用戶可能會(huì)使用不同版本的ML工具或框架。

當(dāng)我們準(zhǔn)備開發(fā)一個(gè)可能在生產(chǎn)中運(yùn)行的ML原型時(shí)，我們喜歡使用一些可視化的開發(fā)工具，如Jupyter。從業(yè)者可以在Jupyter中編寫代碼的同時(shí)撰寫模型說明和數(shù)據(jù)探索的結(jié)論。

與使用開發(fā)工具或老式的文本編輯器和Shell終端相比，Jupyter的關(guān)鍵優(yōu)勢在于，它提供了數(shù)據(jù)可視化的功能，可以在線顯示分析圖，為待打印的數(shù)據(jù)框架提供良好的顯示格式，如圖3所示。這使得開發(fā)者在寫腳本的時(shí)候可以很容易地檢查中間結(jié)果，這種方式比把輸出內(nèi)容打印到終端或在斷點(diǎn)處檢查變量更直觀、高效。

圖3  Jupyter Notebook中數(shù)據(jù)幀的基礎(chǔ)可視化

數(shù)據(jù)探索是任何ML項(xiàng)目的第一個(gè)具體的、手動(dòng)的步驟，通常也是從業(yè)者最熟悉的步驟。但當(dāng)將一個(gè)ML項(xiàng)目推進(jìn)到產(chǎn)品化階段時(shí)，往往會(huì)產(chǎn)生認(rèn)知偏差，因?yàn)檫@兩個(gè)階段需要不同的工具和思維方式。

沒有數(shù)據(jù)就沒有模型，所以數(shù)據(jù)探索很自然地應(yīng)先于模型探索。數(shù)據(jù)探索的目的是理解數(shù)據(jù)。準(zhǔn)備數(shù)據(jù)的時(shí)候使用的原始數(shù)據(jù)通常是以表格的形式保存的，這時(shí)無法直接對數(shù)據(jù)進(jìn)行探索，因?yàn)橐粋€(gè)可能有百萬行數(shù)據(jù)的表格并不是人類可以理解數(shù)據(jù)的最佳界面。我們擅長的是用形狀、尺寸和顏色等來理解事物。為了理解單個(gè)變量的屬性及多個(gè)變量間的關(guān)系，人們需要借助工具。理解數(shù)據(jù)時(shí)可以使用特征工程技術(shù)將數(shù)據(jù)轉(zhuǎn)換和處理為更高層次的特征，這些特征在模型探索步驟中將會(huì)起到關(guān)鍵作用。

模型探索可以與數(shù)據(jù)探索重疊，但也可以認(rèn)為它是一個(gè)獨(dú)立的步驟。在模型探索步驟中，數(shù)據(jù)科學(xué)家會(huì)分析和評估不同模型的可行性，如評估使用回歸、決策樹或隨機(jī)森林等算法在現(xiàn)有數(shù)據(jù)上的表現(xiàn)。

在技術(shù)層面，模型探索比數(shù)據(jù)探索有更高的要求。模型探索時(shí)經(jīng)常使用Jupyter，數(shù)據(jù)探索通常可以在本地Jupyter環(huán)境中完成，而模型探索步驟一般有更高的計(jì)算要求。用一組參數(shù)和數(shù)據(jù)測試一個(gè)模型的表現(xiàn)，有時(shí)需要幾個(gè)小時(shí)，甚至幾天，一個(gè)可自動(dòng)擴(kuò)展的云環(huán)境可能會(huì)成為合理的選擇。模型探索既要花費(fèi)時(shí)間又要花費(fèi)金錢，所以版本控制和可重復(fù)性對于所有的探索實(shí)驗(yàn)來說都是必要的。

此外，隨著ML項(xiàng)目的不斷增加，撰寫模型文檔也成為數(shù)據(jù)科學(xué)家開發(fā)模型不可或缺的環(huán)節(jié)，在MLOps平臺(tái)內(nèi)嵌Jupyter后，數(shù)據(jù)科學(xué)家不但可以使用相關(guān)功能進(jìn)行模型的訓(xùn)練和部署，而不必關(guān)心底層資源的管理，還可以在Jupyter內(nèi)輕松撰寫數(shù)據(jù)探索和模型建模過程，形成知識(shí)庫，以在整個(gè)團(tuán)隊(duì)內(nèi)共享。

在完成了數(shù)據(jù)探索和模型探索后，如果需要將模型或分析結(jié)果生產(chǎn)化，那么還有很多工作要梳理和實(shí)現(xiàn)。比如，生產(chǎn)中的數(shù)據(jù)在哪里？如何在現(xiàn)實(shí)場景中使用模型的結(jié)果？是否需要將模型部署到分布式的機(jī)器上來擴(kuò)大規(guī)模？模型服務(wù)的預(yù)測延遲是否足夠低？如何更新模型？如何知道模型是否有問題？如何處理邊緣案例，如數(shù)據(jù)缺失和異常值的情況？

特征存儲(chǔ)

在ML項(xiàng)目中，通常需要與許多類型的數(shù)據(jù)源打交道，這是因?yàn)闆]有一個(gè)數(shù)據(jù)源適合所有的應(yīng)用。數(shù)據(jù)庫對于存儲(chǔ)大量的數(shù)據(jù)是極方便的，但在返回結(jié)果時(shí)相對比較慢，因?yàn)樗鼈兪菑拇疟P中讀取數(shù)據(jù)的，而讀取時(shí)間或磁盤的I/O通常會(huì)限制網(wǎng)絡(luò)應(yīng)用的性能。一些對延遲時(shí)間有要求的應(yīng)用可能需要尋求方案來解決這個(gè)瓶頸問題，一種常用的方法是使用緩存，即將常用的數(shù)據(jù)存儲(chǔ)起來，使其保存于內(nèi)存中并隨時(shí)可用，而不是從磁盤中“分頁”提取。

具體來說，數(shù)據(jù)存儲(chǔ)的方式有多種，如數(shù)據(jù)湖、數(shù)據(jù)倉庫、數(shù)據(jù)集市及最近幾年在ML領(lǐng)域比較火的特征存儲(chǔ)等。它們代表了不同級別的數(shù)據(jù)管理方式。

• 數(shù)據(jù)湖：非結(jié)構(gòu)化原始數(shù)據(jù)的通用存儲(chǔ)裝置，如日志、圖像、電子郵件及結(jié)構(gòu)化的數(shù)據(jù)字典等數(shù)據(jù)適合使用數(shù)據(jù)湖。原始數(shù)據(jù)到數(shù)據(jù)湖的輸入過程不需要過濾任何東西，因此數(shù)據(jù)湖的大小會(huì)不斷增長。

• 數(shù)據(jù)倉庫：處理過的數(shù)據(jù)、建模和結(jié)構(gòu)化數(shù)據(jù)的存儲(chǔ)裝置，企業(yè)通常使用數(shù)據(jù)倉庫來存儲(chǔ)和檢索運(yùn)營指標(biāo)、業(yè)務(wù)指標(biāo)等。數(shù)據(jù)倉庫通常是企業(yè)級的，能為整個(gè)企業(yè)各個(gè)部門的運(yùn)作提供數(shù)據(jù)決策支持。

• 數(shù)據(jù)集市：一個(gè)簡單的數(shù)據(jù)倉庫，數(shù)據(jù)集市通常是部門級的，用來滿足特定部門和用戶的需求，按照多維的方式進(jìn)行數(shù)據(jù)存儲(chǔ)，包括定義維度、需要計(jì)算的指標(biāo)及維度的層次等，從而生成面向決策分析需求的數(shù)據(jù)立方體。

• 特征存儲(chǔ)：數(shù)據(jù)倉庫的一種特殊形式，幫助數(shù)據(jù)科學(xué)家訪問數(shù)據(jù)和管理ML的特征。它包含的特征是經(jīng)過處理的數(shù)據(jù)，可以被ML模型直接消費(fèi)。與數(shù)據(jù)倉庫不同的是，特征存儲(chǔ)提供了檢索穩(wěn)健性更高和延遲更低的訪問渠道，以實(shí)現(xiàn)快速推理（預(yù)測），以及為頻繁的模型持續(xù)訓(xùn)練過程提供訓(xùn)練數(shù)據(jù)。

特征存儲(chǔ)好比數(shù)據(jù)科學(xué)的數(shù)據(jù)倉庫，它的主要目標(biāo)是使數(shù)據(jù)科學(xué)家能夠縮短從數(shù)據(jù)攝取到ML模型訓(xùn)練和推理的時(shí)間，填補(bǔ)了MLOps生命周期中的一個(gè)重要空白。

在特征存儲(chǔ)模式下，收集數(shù)據(jù)并將其轉(zhuǎn)化為特征的過程是一次性完成的，并可以被重復(fù)使用。特征存儲(chǔ)是將特征工程的過程與特征的消費(fèi)（例如，在模型的開發(fā)或在線推理時(shí)使用）過程解耦，在特征存儲(chǔ)中，特征在模型訓(xùn)練和在線推理服務(wù)之間的消費(fèi)也使用了不同的技術(shù)進(jìn)行分離，并通過一個(gè)通用的SDK來保持這兩種消費(fèi)模式的一致性。這種共享方式加快了ML的工作進(jìn)程，因?yàn)閿?shù)據(jù)工程師不必像傳統(tǒng)方式那樣每次建模的時(shí)候都重新收集數(shù)據(jù)和進(jìn)行相應(yīng)的轉(zhuǎn)換，而重復(fù)性的工作會(huì)造成浪費(fèi)，也不利于特征的充分利用和管理。此外，通過特征存儲(chǔ)還可以選擇歷史沉淀下來的特征來快速生成訓(xùn)練數(shù)據(jù)以訓(xùn)練不同的模型。

特征存儲(chǔ)的作用是雙重的，它是對特征工程產(chǎn)生的特征進(jìn)行存儲(chǔ)的設(shè)施，也是開發(fā)者可以復(fù)用特征的存儲(chǔ)設(shè)施。本質(zhì)上，特征存儲(chǔ)是人們共享、注釋、發(fā)現(xiàn)和使用處理過的數(shù)據(jù)的地方。具體地，特征存儲(chǔ)涉及兩個(gè)不同的存儲(chǔ)方式，一個(gè)是低延遲的在線存儲(chǔ)，通常以Redis緩存的形式為模型服務(wù)提供最新、實(shí)時(shí)的特征，另一個(gè)是成本優(yōu)化的離線存儲(chǔ)，用于存儲(chǔ)支持模型訓(xùn)練的歷史數(shù)據(jù)。

當(dāng)前市場上流行的特征存儲(chǔ)有Michelangelo Pallete（Uber）、Feast（Gojek和Google）、Zipline（Airbnb）和Hopsworks（LogicalClocks）。

實(shí)驗(yàn)管理和模型管理

實(shí)驗(yàn)管理和模型管理都與ML模型的迭代、版本化及評估等關(guān)鍵事件息息相關(guān)，應(yīng)確?？芍貜?fù)性，并提供模型和結(jié)果的可視化管理界面。

對模型訓(xùn)練期間產(chǎn)生的特定信息，如變量、特征、屬性、評分、性能指標(biāo)、歷史版本及位置信息的管理屬于實(shí)驗(yàn)管理的范疇。

而對訓(xùn)練、創(chuàng)建、部署、重新評估、重新訓(xùn)練、發(fā)布到生產(chǎn)環(huán)境及模型版本、標(biāo)簽和描述之類的事件的管理都屬于模型管理的范疇。這些事件的標(biāo)簽可以是注釋，如項(xiàng)目、用戶、時(shí)間戳和有關(guān)原始值與更新值的詳細(xì)信息。

實(shí)驗(yàn)管理與模型管理的實(shí)現(xiàn)通常需要將與數(shù)據(jù)科學(xué)家工作流程相關(guān)聯(lián)的元數(shù)據(jù)進(jìn)行記錄和保存。這里的記錄和保存可以通過API的封裝來實(shí)現(xiàn)。除了通過API與元數(shù)據(jù)集進(jìn)行編程交互，還需要有前端界面的功能來實(shí)現(xiàn)可視化管理，在前端界面上進(jìn)行操作時(shí)所產(chǎn)生和檢索的數(shù)據(jù)也是通過上述API來實(shí)現(xiàn)與后端數(shù)據(jù)庫交互的。

服務(wù)

服務(wù)是一個(gè)更大系統(tǒng)中的獨(dú)立單元，提供一些特定的功能。服務(wù)可以被認(rèn)為是構(gòu)成一個(gè)系統(tǒng)的黑盒子。舉個(gè)例子，一個(gè)大型媒體網(wǎng)站的后端系統(tǒng)可能是由若干個(gè)共同為媒體網(wǎng)站的用戶提供文章推薦的服務(wù)組成的。其中，一個(gè)服務(wù)提供一組關(guān)于一篇文章的統(tǒng)計(jì)數(shù)據(jù)，另一個(gè)服務(wù)可能會(huì)啟動(dòng)ML訓(xùn)練作業(yè)，并將訓(xùn)練好的模型提供給一個(gè)對ML結(jié)果進(jìn)行后處理的服務(wù)，記為ML推薦服務(wù)，最終網(wǎng)站的前端調(diào)用推薦服務(wù)獲取推薦結(jié)果。

這些工作通常被稱為服務(wù)，每個(gè)獨(dú)立的服務(wù)都是強(qiáng)分離的。雖然不同企業(yè)定義的服務(wù)標(biāo)準(zhǔn)各不相同，但還是有共性的，如下所述。

• 服務(wù)是黑盒子，它們的實(shí)現(xiàn)邏輯對用戶是隱藏的。

• 服務(wù)是自主的，它們要對它們所服務(wù)的功能負(fù)責(zé)。

• 服務(wù)是無狀態(tài)的，要么返回預(yù)期的值，要么返回一個(gè)錯(cuò)誤信息。當(dāng)返回錯(cuò)誤信息時(shí)，需要能夠在不影響系統(tǒng)的情況下重新啟動(dòng)一個(gè)可用的新服務(wù)。

服務(wù)應(yīng)該是可以復(fù)用的，這對MLOps平臺(tái)來說特別有用，比如，特征存儲(chǔ)的在線服務(wù)就是可復(fù)用的，可以滿足不同團(tuán)隊(duì)和不同模型的使用要求。

在生產(chǎn)環(huán)境中，在模型服務(wù)化（服務(wù)化后產(chǎn)生的服務(wù)被稱為模型推理服務(wù)或預(yù)測服務(wù)）階段，其對應(yīng)的API通常需要處理大量的請求負(fù)載，很多時(shí)候單機(jī)很難滿足需求。有許多種方法可以擴(kuò)展一個(gè)生產(chǎn)系統(tǒng)。

第一種方法是垂直擴(kuò)展，指的是增加網(wǎng)絡(luò)中單個(gè)節(jié)點(diǎn)容量的過程。如果模型服務(wù)已經(jīng)在多個(gè)節(jié)點(diǎn)上運(yùn)行，它指的是增加一部分網(wǎng)絡(luò)或整個(gè)網(wǎng)絡(luò)的容量。垂直擴(kuò)展的主要問題是，隨著單個(gè)節(jié)點(diǎn)容量的增加，與增加第二個(gè)類似規(guī)格的節(jié)點(diǎn)相比，它的成本會(huì)非線性地增加。垂直擴(kuò)展通常是首選的方法。一般來說，這種方法在擴(kuò)展時(shí)不需要修改代碼。

第二種方法是水平擴(kuò)展，即添加更多的節(jié)點(diǎn)到網(wǎng)絡(luò)中，在節(jié)點(diǎn)之間分配容量。這種方法通常需要引入負(fù)載均衡器，該負(fù)載均衡器將一個(gè)給定的請求分流到一個(gè)（可能）當(dāng)前不忙的節(jié)點(diǎn)。同樣，這種方法在擴(kuò)展時(shí)也不需要改變應(yīng)用程序的代碼。不過，與垂直擴(kuò)展相比，它會(huì)帶來更多的復(fù)雜性，因?yàn)橐胴?fù)載均衡器和增加網(wǎng)絡(luò)規(guī)模。

除了這兩種擴(kuò)展方式，還有其他很多方式可以優(yōu)化生產(chǎn)系統(tǒng)的性能。最常見的方式是，優(yōu)化應(yīng)用程序代碼本身的性能，比如，尋找方法使代碼片段處理得更快、分批進(jìn)行數(shù)據(jù)庫的調(diào)用、避免不必要的循環(huán)和嵌套，以及將網(wǎng)絡(luò)調(diào)用做成異步的等。有時(shí)，我們還需要在低延遲和準(zhǔn)確性之間找到一個(gè)折中的方案。在使用這些方法調(diào)整模型服務(wù)之后，模型服務(wù)的響應(yīng)會(huì)變得更快。

此外，為了優(yōu)化模型服務(wù)組件（模塊）的成本，托管技術(shù)的選擇至關(guān)重要，比如，在容器中運(yùn)行多個(gè)模型可以最大限度地利用資源（CPU/GPU的內(nèi)存）來處理推理請求。模型服務(wù)組件本身應(yīng)具有模型生命周期管理的功能，以支持版本的推出。自動(dòng)擴(kuò)展是MLOps底層基礎(chǔ)設(shè)施的一個(gè)重要特性，用于滿足高峰時(shí)段的需求及降低非高峰時(shí)段的成本。比如，對長時(shí)間沒有接收到流量的模型，可以靈活降低對該模型服務(wù)的資源分配。

生產(chǎn)環(huán)境中的模型可以在正常運(yùn)維范圍內(nèi)運(yùn)行，通過監(jiān)控組件的可視化指標(biāo)進(jìn)行觀察。當(dāng)模型的運(yùn)行行為發(fā)生變化時(shí)，需要引入持續(xù)訓(xùn)練機(jī)制來解決模型的漂移問題。

前面討論過，ML 管道包括傳入數(shù)據(jù)的驗(yàn)證、模型評估、推理請求的監(jiān)控和日志管理等任務(wù)，這些任務(wù)中的每一個(gè)都是管道中的獨(dú)立組件。管道中每個(gè)組件產(chǎn)生的結(jié)果需要存儲(chǔ)在中央存儲(chǔ)中，以確保模型生命周期的可觀察性。

通過驗(yàn)證和評估的開發(fā)環(huán)境中的模型，在推送到生產(chǎn)環(huán)境后，其實(shí)時(shí)性能需要由專門的監(jiān)控模塊進(jìn)行跟蹤，以確保對業(yè)務(wù)的影響正向?？梢酝ㄟ^多種方法來監(jiān)控運(yùn)行中的模型服務(wù)和預(yù)測行為。理想的方法是，記錄模型服務(wù)被請求時(shí)所做的預(yù)測，然后將它們與后續(xù)業(yè)務(wù)系統(tǒng)運(yùn)行過程中觀測到的用戶反饋結(jié)果結(jié)合起來，最后評估運(yùn)行中的模型性能是否滿足預(yù)期。