本文主要介紹機器學習（以下簡寫為ML）算法和架構在MLOps框架下的工程實踐。

當從業者具備了足夠豐富的知識儲備時，就可以開始嘗試ML了。

通常情況下，ML實踐會涉及研究和生產兩個主要環境。

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

• 生產環境是模型投產的環境，ML在生產環境中通常需要相對長期的持續運行，生產環境中的任務一般需要自動化和持續迭代。

下面舉個僅需要在研究環境中進行數據分析或建模即可滿足需求的例子，即在文章標題中找到與較高點擊率相關的關鍵詞。數據分析師的交付方式可能是將探索出的規律和結論報告給一個運營團隊，這樣運營人員就可以在新的標題中嘗試使用探索出的規律和結論來提高點擊率。

再舉一個數據分析和建模需要在研究環境中完成而建模結果需要在生產環境中發布的例子，該情況下的模型需要不斷迭代，比如在電商網站上運行的推薦模型。在生產環境中運行的模型會涉及后續的管理和運維，當運行中出現異常或模型衰退時，需要通過監控機制發出預警信號。

這兩類環境對從業者的要求很不相同。大多數初級ML圖書講述的是研究環境中的ML，很少會涉及生產環境中的ML。

一般來說，一個完備的ML項目的工作流程是，先在研究環境中探索和開發ML模型，制作一個ML應用程序的原型，然后符合預期的模型會被推送到生產環境，進行自動化部署和監控。開發一個用于生產環境的ML應用程序的工作比分析、探索的工作要復雜得多，需要把在研究環境中運行的ML作業轉換成能在生產環境中自動運行的作業，我們通常把這一過程稱為ML的生產化或工程化。

回顧前面ML的定義，從廣義上講，ML是一門通過算法和統計模型從數據中學習知識的學科，ML工程顧名思義就是構建基于ML的應用程序的計算實踐。

ML工程是建立在ML的工作基礎上并將研究環境中開發的ML模型應用于生產環境的技術。ML工程與ML的區別在于側重點不同，ML更關心算法的優化和模型的訓練，ML工程則更關心從不同業務系統采集數據，并訓練一個兼顧模型性能和計算性能的模型，使其能在生產環境中穩定運行，保證模型的可監控、可維護、可更新、可被業務系統使用，為模型生產化提供工程保障。

ML工程包括從數據收集、特征工程、模型訓練到模型投入應用、管理和運維的所有階段。這個過程與高中時期考試的不同階段類似，ML開發過程相當于平時的模考，關心的是對知識點的消化和總結，ML工程相當于高考，在兼顧平時模考習得的知識點的同時，還需要綜合考察實考環境下的心理壓力、時間分配、考題內容等因素。

事實上，數據科學團隊通常專注于研究新穎的算法或訓練高精準的模型，但與實際ML項目中需要的全流程（如特征工程、部署、監控等）相比，ML算法只是ML項目非常小的一部分，一個真正要投產的ML項目通常需要大量的工程工作和基礎設施的配合，以實現ML模型在生產環境中順利運行。

2015年，谷歌發布的論文指出，為了避免無休止的“技術債”纏身，應該強調將ML生產化視為一門學科的重要性（在當前的ML技術主流中確實如此），通過加強工程技術的投入來順利實現ML的生產化。如圖1所示，ML模型的生產化是由多個模塊組成的，在實際場景中需要在這些模塊間建立溝通機制來配合完成ML模型的生產化。

圖1  ML生產化模塊

機器學習工程模塊的設計原則

關注點分離（SoC）是一個可行的設計原則，指的是計算機科學中對應用程序、代碼塊和其他對象系統進行劃分的方式，關注點被“分離”的程度因系統而異。比如，一個存在相互依存關系的系統一般是關注點的弱分離，簡稱弱分離；而一個可以完全獨立負責自己工作的系統或模塊，一般認為是關注點的強分離，簡稱強分離。

ML 工程模塊的設計既可以使用弱分離的設計原則，也可以使用強分離的設計原則。在弱分離的設計原則下，訓練和預測必須在同一臺服務器上運行，訓練步驟和預測步驟被捆綁在同一個模塊中。比如，在輸入數據上調用一個名為train的函數，該函數返回一個模型，該模型會作為predict函數的輸入，在運行時會按順序依次執行train和predict函數。而在強分離的設計原則下，訓練和預測可以在兩個不同的服務器或進程中運行。在這種情況下，訓練和預測是相互獨立發生的，訓練步驟和預測步驟分別歸屬不同的模塊。

一般來說，面向服務的架構（SOA）是符合強分離設計原則的，我們認為在生產場景下使用SOA來設計和開發ML系統是可行的。

此外，無論是設計MLOps平臺還是傳統的ML系統，建議在設計時考慮以下幾項關鍵原則。

• 從一開始就為可重復性而構建：保留所有模型的輸入和輸出，以及所有相關元數據，如配置信息、依賴項、操作時間戳等。注意版本控制，包括所用的訓練數據。

• 將ML過程中的不同管道視為系統的一部分：如特征工程、自動化訓練、模型部署和發布等。

• 提前考慮可擴展性：如果系統需要定期更新模型，則需要在設計系統的時候就仔細考慮如何做到這一點。

• 模塊化：盡可能地對ML生命周期的各個環節進行模塊化，這會極大地提高系統的復用性。

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

進行機器學習工程的模塊設計時需要注意的細節

設計架構和模塊的出發點應該是滿足業務需求和公司更長遠的目標。在開始設計和使用最新技術之前，需要了解現有條件的限制、預期會創造的價值及在為誰創造價值等，需要考慮當前公司的業務場景及未來可能會新增的場景。比如，在現有的業務場景下是否需要提供實時預測？如果需要實時預測，那么業務側允許的延遲是毫秒級的還是秒級的，又或者只需在接收輸入數據后的30分鐘或一天內交付預測結果就能滿足需求。

具體地，以下幾個細節值得考慮。

• 針對公司業務，希望多久更新一次模型？

• 預測的需求（流量）是什么？

• 需要處理多大量級的數據？

• 希望使用哪些算法？比如，是否會使用深度網絡類的算法（需要評估是否真的需要）？

• 是否處在一個對系統審計要求非常高的監管環境中？

• 當前要設計的ML系統是在之前的基礎上升級的還是重構的？

• 當前的工程團隊有多大？是否包含了數據科學家、ML工程師及DevOps工程師等？當前團隊是否有開發ML系統的經驗？

一旦團隊對這些基礎問題進行了評估，便可以在此基礎上考慮ML系統的一些高級體系結構選項，比如，打造獨立的模型訓練系統、模型服務系統，抑或全流程的MLOps平臺。

需要注意的是，為了避免從業者在使用上混淆“系統”和“平臺”，這里對二者的定義進行說明。

系統通常指的是一個具體的軟件，而平臺則是指進行某項工作所需的信息化環境或條件，是一個相對抽象的生態環境。系統強調的是功能，平臺側重的是場景。系統有明確的輸入、處理過程和輸出，而平臺則是基于同一套規則和體系，由多個主體共同參與的生態圈，這套規則和體系往往是由系統組成的。

編碼環境與模型探索

如果數據科學家在研究環境中使用的編程語言與生產環境中的一致，那么整個工作流程的處理會輕松一些，這里涉及的編程語言通常是Python語言，因為它擁有豐富的關于數據科學和數據處理的開源代碼和包。然而，如果運行速度是一個要考慮的選項，那么Python語言可能是不可行的（盡管有很多種方法可以幫助其進一步優化運行速度）。

出于性能的考慮，何時進行語言的轉換變得格外重要，因為研究團隊和生產團隊之間的額外溝通成本將會成為一個很大的負擔。當然，如果你周圍所有的數據科學家都精通Scala、Java或C++語言，那么這個問題就變得簡單多了。

當然，不同的角色可能會使用不同的工具或編程語言，沒有一個工具可以涵蓋所有任務，更重要的是，單個任務通常需要多個角色和多個工具來協作實現。以分析工程師、數據科學家和數據工程師為例，如圖2所示，數據工程師可能會使用IntelliJ中的Scala創建包含數億個事件的數據集的聚合，分析工程師可能會在相關業務的分析報告中使用SQL和Tableau對該聚合進行分析和可視化，而數據科學家可能會使用Python處理該聚合并參考分析工程師的分析結果進行線上營銷模型的構建。

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

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

幸運的是，有一個開源項目Jupyter（該項目也是當前數據科學家最常用的開源項目之一）的設計做到了這一點。當前市面上很多專攻MLOps領域的公司都是使用Jupyter來提供建模或分析環境的，如cnvrg.io、Domino Data Lab、InfuseAI等。其中InfuseAI公司旗下的PrimeHub平臺最初就是從提供在線Jupyter建模環境開始的，后來才慢慢增加了模型部署和管理等功能，并逐步擴展成為MLOps平臺。

Jupyter提供了一個標準的消息傳遞API協議與充當計算引擎的內核進行通信，該協議啟用了一個可組合的架構，將編寫代碼內容的位置（UI）和執行代碼的位置（內核）分開。通過將運行時與UI界面隔離（實際上MLOps的設計也借鑒了類似的思路），Jupyter可以跨越多種編程語言，同時保持執行環境配置方式的靈活性。

具體地，隨著新的ML開發框架不斷興起并取代傳統工具，不建議對MLOps平臺支持的語言或框架制定限制性的標準。MLOps平臺的設計應該足夠靈活并模塊化，以支持添加新框架，比如，需要能夠隨意加載TensorFlow、PyTorch和Scikit-Learn這些數據科學家必備的工具或框架。不過在MLOps框架內搭建Jupyter環境時要注意一點，需要按用戶或項目生成隔離空間，比如，將新增的Jupyter服務創建在Python的虛擬環境中，或者使用容器進行創建，因為不同的項目或不同的用戶可能會使用不同版本的ML工具或框架。

當我們準備開發一個可能在生產中運行的ML原型時，我們喜歡使用一些可視化的開發工具，如Jupyter。從業者可以在Jupyter中編寫代碼的同時撰寫模型說明和數據探索的結論。

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

圖3  Jupyter Notebook中數據幀的基礎可視化

數據探索是任何ML項目的第一個具體的、手動的步驟，通常也是從業者最熟悉的步驟。但當將一個ML項目推進到產品化階段時，往往會產生認知偏差，因為這兩個階段需要不同的工具和思維方式。

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

模型探索可以與數據探索重疊，但也可以認為它是一個獨立的步驟。在模型探索步驟中，數據科學家會分析和評估不同模型的可行性，如評估使用回歸、決策樹或隨機森林等算法在現有數據上的表現。

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

此外，隨著ML項目的不斷增加，撰寫模型文檔也成為數據科學家開發模型不可或缺的環節，在MLOps平臺內嵌Jupyter后，數據科學家不但可以使用相關功能進行模型的訓練和部署，而不必關心底層資源的管理，還可以在Jupyter內輕松撰寫數據探索和模型建模過程，形成知識庫，以在整個團隊內共享。

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

特征存儲

在ML項目中，通常需要與許多類型的數據源打交道，這是因為沒有一個數據源適合所有的應用。數據庫對于存儲大量的數據是極方便的，但在返回結果時相對比較慢，因為它們是從磁盤中讀取數據的，而讀取時間或磁盤的I/O通常會限制網絡應用的性能。一些對延遲時間有要求的應用可能需要尋求方案來解決這個瓶頸問題，一種常用的方法是使用緩存，即將常用的數據存儲起來，使其保存于內存中并隨時可用，而不是從磁盤中“分頁”提取。

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

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

• 數據倉庫：處理過的數據、建模和結構化數據的存儲裝置，企業通常使用數據倉庫來存儲和檢索運營指標、業務指標等。數據倉庫通常是企業級的，能為整個企業各個部門的運作提供數據決策支持。

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

• 特征存儲：數據倉庫的一種特殊形式，幫助數據科學家訪問數據和管理ML的特征。它包含的特征是經過處理的數據，可以被ML模型直接消費。與數據倉庫不同的是，特征存儲提供了檢索穩健性更高和延遲更低的訪問渠道，以實現快速推理（預測），以及為頻繁的模型持續訓練過程提供訓練數據。

特征存儲好比數據科學的數據倉庫，它的主要目標是使數據科學家能夠縮短從數據攝取到ML模型訓練和推理的時間，填補了MLOps生命周期中的一個重要空白。

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

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

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

實驗管理和模型管理

實驗管理和模型管理都與ML模型的迭代、版本化及評估等關鍵事件息息相關，應確保可重復性，并提供模型和結果的可視化管理界面。

對模型訓練期間產生的特定信息，如變量、特征、屬性、評分、性能指標、歷史版本及位置信息的管理屬于實驗管理的范疇。

而對訓練、創建、部署、重新評估、重新訓練、發布到生產環境及模型版本、標簽和描述之類的事件的管理都屬于模型管理的范疇。這些事件的標簽可以是注釋，如項目、用戶、時間戳和有關原始值與更新值的詳細信息。

實驗管理與模型管理的實現通常需要將與數據科學家工作流程相關聯的元數據進行記錄和保存。這里的記錄和保存可以通過API的封裝來實現。除了通過API與元數據集進行編程交互，還需要有前端界面的功能來實現可視化管理，在前端界面上進行操作時所產生和檢索的數據也是通過上述API來實現與后端數據庫交互的。

服務

服務是一個更大系統中的獨立單元，提供一些特定的功能。服務可以被認為是構成一個系統的黑盒子。舉個例子，一個大型媒體網站的后端系統可能是由若干個共同為媒體網站的用戶提供文章推薦的服務組成的。其中，一個服務提供一組關于一篇文章的統計數據，另一個服務可能會啟動ML訓練作業，并將訓練好的模型提供給一個對ML結果進行后處理的服務，記為ML推薦服務，最終網站的前端調用推薦服務獲取推薦結果。

這些工作通常被稱為服務，每個獨立的服務都是強分離的。雖然不同企業定義的服務標準各不相同，但還是有共性的，如下所述。

• 服務是黑盒子，它們的實現邏輯對用戶是隱藏的。

• 服務是自主的，它們要對它們所服務的功能負責。

• 服務是無狀態的，要么返回預期的值，要么返回一個錯誤信息。當返回錯誤信息時，需要能夠在不影響系統的情況下重新啟動一個可用的新服務。

服務應該是可以復用的，這對MLOps平臺來說特別有用，比如，特征存儲的在線服務就是可復用的，可以滿足不同團隊和不同模型的使用要求。

在生產環境中，在模型服務化（服務化后產生的服務被稱為模型推理服務或預測服務）階段，其對應的API通常需要處理大量的請求負載，很多時候單機很難滿足需求。有許多種方法可以擴展一個生產系統。

第一種方法是垂直擴展，指的是增加網絡中單個節點容量的過程。如果模型服務已經在多個節點上運行，它指的是增加一部分網絡或整個網絡的容量。垂直擴展的主要問題是，隨著單個節點容量的增加，與增加第二個類似規格的節點相比，它的成本會非線性地增加。垂直擴展通常是首選的方法。一般來說，這種方法在擴展時不需要修改代碼。

第二種方法是水平擴展，即添加更多的節點到網絡中，在節點之間分配容量。這種方法通常需要引入負載均衡器，該負載均衡器將一個給定的請求分流到一個（可能）當前不忙的節點。同樣，這種方法在擴展時也不需要改變應用程序的代碼。不過，與垂直擴展相比，它會帶來更多的復雜性，因為要引入負載均衡器和增加網絡規模。

除了這兩種擴展方式，還有其他很多方式可以優化生產系統的性能。最常見的方式是，優化應用程序代碼本身的性能，比如，尋找方法使代碼片段處理得更快、分批進行數據庫的調用、避免不必要的循環和嵌套，以及將網絡調用做成異步的等。有時，我們還需要在低延遲和準確性之間找到一個折中的方案。在使用這些方法調整模型服務之后，模型服務的響應會變得更快。

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

生產環境中的模型可以在正常運維范圍內運行，通過監控組件的可視化指標進行觀察。當模型的運行行為發生變化時，需要引入持續訓練機制來解決模型的漂移問題。

前面討論過，ML 管道包括傳入數據的驗證、模型評估、推理請求的監控和日志管理等任務，這些任務中的每一個都是管道中的獨立組件。管道中每個組件產生的結果需要存儲在中央存儲中，以確保模型生命周期的可觀察性。

通過驗證和評估的開發環境中的模型，在推送到生產環境后，其實時性能需要由專門的監控模塊進行跟蹤，以確保對業務的影響正向。可以通過多種方法來監控運行中的模型服務和預測行為。理想的方法是，記錄模型服務被請求時所做的預測，然后將它們與后續業務系統運行過程中觀測到的用戶反饋結果結合起來，最后評估運行中的模型性能是否滿足預期。