MLOps工作流在Databricks上
本文描述如何在Databricks Lakehouse平台上使用mlop來優化機器學習(ML)係統的性能和長期效率。Beplay体育安卓版本它包括MLOps體係結構的一般建議，並描述了使用Databricks Lakehouse平台的通用工作流，您可以將其用作ML開發到生產過程的模型。Beplay体育安卓版本
什麼是MLOps?
MLOps是一組用於管理代碼、數據和模型的過程和自動化步驟。它結合了DevOps、DataOps和ModelOps。
ML資產(如代碼、數據和模型)的開發是分階段進行的，從沒有嚴格訪問限製和嚴格測試的早期開發階段，經過中間測試階段，到嚴格控製的最終生產階段。Databricks Lakehouse平台允許您Beplay体育安卓版本在一個具有統一訪問控製的單一平台上管理這些資產。您可以在同一個平台上開發數據應用程序和ML應用程序，從而減少與移動數據相關的風險和延遲。Beplay体育安卓版本
mlop的一般建議
本節包括Databricks上mlop的一些一般建議，並提供更多信息的鏈接。
為每個階段創建單獨的環境
執行環境是代碼創建或使用模型和數據的地方。每個執行環境由計算實例、它們的運行時和庫以及自動化作業組成。
Databricks建議為ML代碼和模型開發的不同階段創建單獨的環境，並在各個階段之間明確定義轉換。本文中描述的工作流遵循這個過程，使用階段的通用名稱:
還可以使用其他配置來滿足組織的特定需求。
訪問控製和版本控製
訪問控製和版本控製是任何軟件操作過程的關鍵組成部分。Databricks的建議如下:
使用Git進行版本控製。管道和代碼應該存儲在Git中進行版本控製。在階段之間移動ML邏輯可以解釋為將代碼從開發分支移動到登台分支，再移動到發布分支。使用磚回購與您的Git提供者集成，並與Databricks工作區同步筆記本和源代碼。Databricks還為Git集成和版本控製提供了額外的工具;看到開發人員工具和指導．
使用Delta表在Lakehouse體係結構中存儲數據。數據應該存儲在Lakehouse架構在你的雲帳戶中。原始數據和特征表都應該存儲為三角洲表通過訪問控製來確定誰可以讀取和修改它們。
使用MLflow管理模型和模型開發。你可以使用MLflow跟蹤模型開發過程並保存代碼快照、模型參數、度量和其他元數據。使用模型注冊管理模型版本和部署狀態。模型注冊中心提供人則和一個API，所以你可以集成CD係統，也處理模型的訪問控製．
部署代碼，而不是模型
在大多數情況下，Databricks建議在ML開發過程中進行推廣代碼，而不是模型，從一個環境到另一個環境。以這種方式移動項目資產可以確保ML開發過程中的所有代碼都經過相同的代碼審查和集成測試過程。它還確保模型的生產版本在生產代碼上得到訓練。有關選項和權衡的更詳細討論，請參見模型部署模式．
推薦的MLOps工作流
下麵幾節描述了一個典型的MLOps工作流，涵蓋了三個階段:開發、階段和生產。
本節使用術語“數據科學家”和“機器學習工程師”作為原型角色;MLOps工作流中的具體角色和職責將在團隊和組織之間有所不同。
發展階段
開發階段的重點是實驗。數據科學家開發特征和模型，並運行實驗來優化模型性能。開發過程的輸出是ML管道代碼，包括特征計算、模型訓練、推斷和監控。
編號的步驟與圖中顯示的數字相對應。
1.數據源
在開發環境中工作的數據科學家通常對生產數據具有隻讀訪問權。在某些情況下，為了滿足數據治理需求，開發環境可能隻能訪問生產數據的鏡像或編校版本。數據科學家還擁有對單獨的開發存儲環境的讀寫訪問權，以開發和試驗新功能和其他數據表。
3.代碼
ML係統的所有代碼都存儲在代碼庫中。數據科學家在Git項目的開發分支中創建新的或更新的管道。代碼可以在Databricks內部或外部開發，並使用Databricks與Databricks工作區同步磚回購．
4.更新特性表
模型開發管道從原始數據表和現有特性表中讀取數據，並將數據寫入特色商店．該管道包括2個任務:
數據準備。檢查數據質量問題。
創建或更新特性表。數據科學家開發或更新代碼來創建功能。這些管道可以從Feature Store和其他Lakehouse表中讀取，也可以寫入開發存儲環境中的特性表。然後，數據科學家使用這些開發特性表來創建原型模型。當代碼升級到生產環境時，這些更改將更新生產特性表。
特性管道可以與其他ML管道分開管理，特別是當它們屬於不同的團隊時。
5.火車模型
數據科學家在隻讀生產數據或非生產數據上開發模型訓練和其他管道。管道可以在開發環境或prod環境中使用特性表。
該管道包括2個任務:
訓練和調優。模型訓練過程從特征存儲和銀色或金色級別的Lakehouse表中讀取特征，並將模型參數、度量標準和工件記錄到MLflow跟蹤服務器。
當訓練和超參數調優完成後，數據科學家將最終的模型工件保存到跟蹤服務器。這記錄了模型、輸入數據和用於生成模型的代碼之間的鏈接。
當這個培訓管道在登台或生產中運行時，ML工程師(或他們的CI/CD代碼)可以通過使用模型URI(或路徑)加載模型，然後將模型推到模型注冊表進行管理和測試。
評估。通過測試保留數據來評估模型質量。這些測試的結果被記錄到MLflow跟蹤服務器。
如果您的組織的治理需求包括關於模型的附加信息，您可以使用MLflow跟蹤．典型的工件是純文本描述和模型解釋，就像由SHAP或LIME生成的那樣。
分段階段
這個階段的重點是測試ML管道代碼，以確保它可以投入生產。所有的ML管道代碼都在這個階段進行測試，包括模型訓練的代碼以及特征工程管道、推理代碼等等。
ML工程師創建一個CI管道來實現在此階段運行的單元和集成測試。登台流程的輸出是一個發布分支，它觸發CI/CD係統啟動生產階段。
編號的步驟與圖中顯示的數字相對應。
登台環境可以有自己的存儲區域，用於測試特征表和ML管道。這種存儲通常是臨時的，隻保留到測試完成。開發環境可能還需要訪問此數據存儲以進行調試。
3.集成測試(CI)
然後CI流程運行集成測試。集成測試運行所有管道(包括特性工程、模型訓練、推斷和監控)，以確保它們一起正確地工作。登台環境應該盡可能地與生產環境相匹配。
為了減少運行集成測試所需的時間，模型訓練步驟可以在測試的保真度和速度之間進行權衡。例如，您可能使用數據的小子集或運行更少的訓練迭代。根據模型的預期用途，您可以選擇在此時進行全麵的負載測試。
集成測試通過登台分支後，您可以將代碼提升到生產環境。
生產階段
ML工程師擁有部署ML管道的生產環境。這些管道計算新的特征值，訓練和測試新的模型版本，向下遊表或應用程序發布預測，並監控整個過程以避免性能下降和不穩定。
數據科學家在生產環境中通常沒有寫入或計算訪問權。然而，重要的是他們對測試結果、日誌、模型工件和生產管道狀態具有可見性，以允許他們識別和診斷生產中的問題。
編號的步驟與圖中顯示的數字相對應。
2.火車模型
在完整的生產數據上訓練模型的生產版本，並將其注冊到MLflow模型注冊中心。這個管道可以由代碼更改或自動再培訓作業觸發。
該管道包括2個任務:
訓練和調優。與開發階段一樣，自動記錄將訓練過程的記錄保存到MLflow跟蹤服務器。這包括模型指標、參數、標簽和模型本身。
在開發過程中，數據科學家可能會測試許多算法和超參數。在生產訓練代碼中，通常隻考慮性能最好的選項。以這種方式限製調優可以節省時間，並可以減少自動再訓練中調優的方差。
評估。模型質量是通過測試生產數據來評估的。這些測試的結果被記錄到MLflow跟蹤服務器。這一步使用數據科學家在開發階段指定的評估指標。這些指標可能包括自定義代碼。
模型訓練完成後，將模型工件注冊到MLflow模型注冊表用於生產環境。初始的Model Registry階段是“None”。
3.連續部署(CD)
CD流程獲取新模型(在模型注冊表“stage=None”中)，測試它們(通過“stage=Staging”過渡)，如果成功部署它們(將它們提升到“stage=Production”)。CD可以使用模型注冊表網鉤或者你自己的CD係統。
該管道包括3個任務:
合規檢查。這些測試從model Registry加載模型，執行組織所需的任何遵從性檢查(例如，標簽或文檔)，並根據測試結果批準或拒絕請求。如果遵從性檢查需要人力專業知識，則此自動化步驟可以計算統計數據或可視化以進行手動檢查。無論結果如何，使用標簽中的元數據和描述中的注釋將模型版本的結果記錄到model Registry。
您可以使用MLflow UI手動管理階段轉換和轉換請求，也可以使用MLflow api和webhook自動化它們。如果模型通過了遵從性檢查，那麼轉換請求將被批準，模型將被提升到“stage=Staging”。如果模型失敗，轉換請求將被拒絕，模型將被移動到模型注冊表中的“stage=Archived”。
比較登台和生產。為了防止性能下降，您應該將升級到Staging的模型的性能與當前的生產版本進行比較。比較指標和方法取決於用例，可以包括金絲雀部署、A/B測試或其他方法。比較測試的結果應該保存到Lakehouse的度量表中。
如果這是第一次部署，並且還沒有生產版本，那麼您可以將登台版本與業務啟發式或其他閾值作為基線進行比較。
請求模型轉換到生產。如果候選模型通過了比較測試，您可以在模型注冊表中請求將其轉換為“stage=Production”。您可以使用MLflow UI手動完成，也可以使用MLflow API和webhooks自動完成。在這一點上考慮需要人的批準也是一個好主意。這是將模型發布到生產環境並集成到現有業務流程之前的最後一步。您可以包括人工檢查，以驗證合規性檢查、性能比較和任何其他難以自動化的檢查。
4.在線服務(REST api)
對於低延遲用例，您可以使用MLflow部署用於在線服務的模型。選項包括Databricks模型服務、雲提供商服務端點或自定義服務應用程序。
服務係統從模型注冊中心加載生產模型版本。對於每個請求，它從在線特征存儲中獲取特征，對數據進行評分，並返回預測。您可以使用服務係統、數據傳輸層或模型記錄請求和預測。
5.推理:批處理或流處理
對於批處理或流推理作業，管道從Feature Store讀取最新數據，從model Registry裝入生產模型版本，對數據進行評分，並返回預測。批處理或流推理通常是高吞吐量、高延遲用例中最具成本效益的選擇。
批處理作業通常通過JDBC連接將預測發布到Lakehouse表或平麵文件。流作業通常將預測發布到Lakehouse表或消息隊列(如Apache Kafka)。
6.監控
您應該監視輸入數據和模型預測的統計屬性(例如數據漂移和模型性能)和計算性能(例如錯誤和吞吐量)。您可以根據這些指標創建警報，或者在儀表板中發布警報。
無論采用何種部署模式，您都可以將模型的輸入查詢和預測記錄到Delta表中。您可以創建作業來監視數據和建模漂移，還可以使用Databricks SQL在儀表板上顯示狀態並發送警報。數據科學家可以訪問開發環境中的日誌和度量，以調查生產問題。
該管道包括3個任務:
數據攝取。該管道從批處理、流或在線推理中讀取日誌。
檢查準確性和數據漂移。管道計算關於輸入數據、模型預測和基礎設施性能的度量。數據科學家在開發過程中指定數據和模型指標，而機器學習工程師指定基礎設施指標。
發布標準。管道寫入Lakehouse表進行分析和報告。您可以使用Databricks SQL創建監控儀表板來跟蹤模型性能，並設置監控作業或儀表板工具，以便在指標超過指定閾值時發出通知。
7.觸發模型再訓練
您可以創建一個計劃作業，用最新的數據重新訓練模型，或者您可以設置一個監控器，在檢測到數據或模型中的漂移時觸發重新訓練。如果模型監視指標表明存在性能問題，數據科學家可能需要返回開發環境並開發一個新的模型版本。
請注意
完全自動化的模型再訓練很難得到正確的結果，因為如何修複由模型監控檢測到的問題可能並不明顯。例如，由觀測到的數據漂移引起的模型性能問題可以通過在更新的數據上重新訓練模型來解決，或者可能需要額外的(手動)特征開發工作來編碼數據中的新信號。
如果定期有新數據可用，則可以創建安排的工作在最新可用數據上運行模型訓練代碼。
如果監控管道可以識別模型性能問題並發送警報，則可以將其配置為自動觸發再培訓。如果管道可以檢測到傳入數據分布的變化或模型性能的下降等情況，那麼自動再訓練和重新部署可以在最小化人工幹預的情況下提高模型性能。