Azure Databricks 上的 MLOps 工作流程
本文說明如何在 Databricks 平台上使用 MLOps 來最佳化機器學習 (ML) 系統的效能和長期效率。 其中包括針對 MLOps 結構的一般建議，還說明了使用 Databricks 平台的通用工作流程，您可將該工作流程用作 ML 開發至生產程序的模型。 如需有關此 LLMOps 應用程式工作流程的修改，請參閱 LLMOps 工作流程。
如需詳細資料，請參閱 The Big Book of MLOps。
什麼是 MLOps？
MLOps 是一組程序和自動化步驟，用於管理程式碼、資料和模型，以提高 ML 系統的效能、穩定性和長期效率。 其結合了 DevOps、DataOps 和 ModelOps。
程式碼、資料和模型等 ML 資產的開發依次經過以下階段：早期開發階段 (沒有嚴格的存取限制且未經過嚴格測試)、中期測試階段和最終生產階段 (受到嚴格控制)。 Databricks 平台可讓您使用統一存取控制在單一平台上管理這些資產。 您可以在相同平台上開發資料應用程式和 ML 應用程式，從而降低與移動資料關聯的風險和延遲。
MLOps 的一般建議
本節包含一些 Databricks 上的 MLOps 的一般建議，以及有關詳細資訊的連結。
為每個階段建立個別環境
執行環境是程式碼建立或取用模型和資料的位置。 每個執行環境都由計算執行個體、其執行階段和程式庫以及自動化工作組成。
Databricks 建議為 ML 程式碼和模型開發的不同階段建立個別環境，並在階段之間明確定義轉換。 本文所述的工作流程遵循此程序，使用階段的一般名稱：
其他組態也可用於符合組織的特定需求。
存取控制和版本設定
存取控制和版本設定是任何軟體作業程序的關鍵元件。 Databricks 建議如下：
- 使用 Git 進行版本控制。 管線和程式碼應儲存在 Git 中以進行版本控制。 然後，在階段之間移動 ML 邏輯可以解譯為將程式碼從開發分支移至預備分支，再至發行分支。 使用 Databricks Git 資料夾與 Git 提供者整合，並將筆記本和原始程式碼與 Databricks 工作區同步。 Databricks 還為 Git 整合和版本控制提供額外工具；請參閱開發人員工具和指導。
- 使用差異資料表將資料儲存在 Lakehouse 結構中。 資料應儲存在雲端帳戶的 Lakehouse 結構中。 原始資料和特徵資料表都應儲存為具有存取控制的差異資料表，以確定誰可以進行讀取和修改。
- 使用 MLflow 管理模型開發。 您可以使用 MLflow 來追蹤模型開發程序，並儲存程式碼快照、模型參數、計量及其他中繼資料。
- 使用 Unity Catalog 中的模型來管理模型生命週期。 使用 Unity Catalog 中的模型來管理模型版本設定、控管和部署狀態。
部署程式碼，而非模型
在大多數情況下，Databricks 建議在 ML 開發程序中，將程式碼 (而不是模型) 從一個環境提升至下一個環境。 以此方式移動專案資產可確保 ML 開發程序中的所有程式碼都經過相同的程式碼檢閱和整合測試程序。 還可確保模型的生產版本在生產程式碼上進行訓練。 如需選項和權衡的更詳細討論，請參閱模型部署模式。
建議的 MLOps 工作流程
下列各節說明典型的 MLOps 工作流程，涵蓋三個階段：開發、預備和生產。
本節使用術語「資料科學家」和「ML 工程師」作為原型角色；MLOps 工作流程中的特定角色和職責因團隊和組織而異。
開發階段
開發階段的重點是實驗。 資料科學家開發特徵和模型，並執行實驗以最佳化模型效能。 開發程序的輸出是 ML 管線程式碼，其中可以包括特徵計算、模型訓練、推斷和監視。
編號的步驟與圖表中顯示的數字對應。
1. 資料來源
開發環境由 Unity Catalog 中的開發目錄表示。 資料科學家在開發工作區中建立暫存資料和特徵資料表時，對開發目錄具有讀寫存取權。 在開發階段建立的模型會註冊至開發目錄。
理想情況下，在開發工作區中工作的資料科學家還可以對生產目錄中的生產資料具有唯讀存取權。 允許資料科學家讀取存取生產目錄中的生產資料、推斷資料表和計量資料表，可讓他們分析目前生產模型預測和效能。 資料科學家應也能夠載入生產模型進行實驗和分析。
如果無法授與對生產目錄的唯讀存取權，則可以將生產資料的快照寫入開發目錄，讓資料科學家開發和評估專案程式碼。
2. 探勘資料分析 (EDA)
資料科學家使用筆記本在互動式反覆程序中探索和分析資料。 目標是評估可用資料是否有可能解決商務問題。 在此步驟中，資料科學家開始識別用於模型訓練的資料準備和特徵化步驟。 此臨時的程序通常不屬於將要部署在其他執行環境中的管線。
Databricks AutoML 透過為資料集產生基準模型來加速此程序。 AutoML 執行並記錄一組試用，並為每次試用執行提供一個包含原始程式碼的 Python 筆記本，以便檢閱、重現和修改程式碼。 AutoML 還會計算資料集的摘要統計資料，並將此資訊儲存在可檢閱的筆記本中。
3. 程式碼
程式碼存放庫包含 ML 專案的所有管線、模組和其他專案檔案。 資料科學家可在專案存放庫的開發 ("dev") 分支中建立新的或已更新的管線。 從 EDA 和專案的初始階段開始，資料科學家應在存放庫中工作，以共用程式碼和追蹤變更。
4. 訓練模型 (開發)
資料科學家使用開發或生產目錄中的資料表，在開發環境中開發模型訓練管線。
此管線包含 2 個任務：
訓練和調整。 訓練程序會將模型參數、計量和成品記錄至 MLflow 追蹤伺服器。 訓練並調整超參數後，最終模型成品將記錄至追蹤伺服器，以記錄模型、訓練依據的輸入資料以及用於產生它的程式碼之間的聯繫。
評估。 透過測試保留的資料來評估模型品質。 這些測試的結果將記錄至 MLflow 追蹤伺服器。 評估的目的是確定新開發的模型的效能是否優於目前生產模型。 如果權限足夠，可以將任何註冊至生產目錄的生產模型載入到開發工作區中，並與新訓練的模型進行比較。
如果貴組織的控管需求包括有關模型的其他資訊，您可以使用 MLflow 追蹤進行儲存。 典型成品是純文字描述和模型解譯，例如由 SHAP 生產的繪圖。 特定控管需求可能來自資料控管官員或商務利害關係人。
模型訓練管線會輸出儲存在 MLflow 追蹤伺服器的 ML 模型成品，用於開發環境。 如果在預備或生產工作區中執行管線，模型成品將儲存在該工作區的 MLflow 追蹤伺服器中。
模型訓練完成後，將模型註冊至 Unity Catalog。 設定管線程式碼，以將模型註冊至與模型管線的執行環境對應的目錄 (在本範例中是開發目錄)。
使用建議的結構，您可以部署一個多任務 Databricks 工作流程，其中第一個工作是模型訓練管線，然後是模型驗證和模型部署工作。 模型訓練任務會產生模型驗證任務可以使用的模型 URI。 您可以使用任務值將此 URI 傳遞給模型。
5. 驗證和部署模型 (開發)
除了模型訓練管線，其他管線 (如模型驗證和模型部署管線) 也在開發環境中開發。
模型驗證。 模型驗證管線採用模型訓練管線中的模型 URI，從 Unity Catalog 載入模型，並執行驗證檢查。
驗證檢查取決於內容。 其中可以包括基本檢查 (如確認格式和所需的中繼資料) 和高度管制產業可能需要的更複雜的檢查 (如預先定義的合規性檢查和確認所選資料配量上的模型效能)。
模型驗證管線的主要功能是確定模型是否應繼續執行部署步驟。 如果模型通過預先部署檢查，則可以在 Unity Catalog 中為其指派「挑戰者」別名。 如果檢查失敗，此程序將結束。 您可以將工作流程設定為通知使用者驗證失敗。 請參閱新增工作事件的電子郵件和系統通知。
模型部署。 模型部署管線通常透過更新別名將新訓練的「挑戰者」模型直接提升為「冠軍」狀態，或者將現有「冠軍」模型與新的「挑戰者」模型進行比較。 此管線還可以設定任何必需的推斷基礎結構，例如模型服務端點。 如需模型部署管線中所涉及步驟的詳細討論，請參閱生產。
6. 提交程式碼
在開發訓練、驗證、部署和其他管線的程式碼後，資料科學家或 ML 工程師會將開發分支變更提交到原始檔控制中。
預備階段
此階段的重點是測試 ML 管線程式碼，以確保其已為生產做好準備。 在此階段測試所有 ML 管線程式碼，包括用於模型訓練的程式碼以及特徵工程管線、推斷程式碼等。
ML 工程師建立一個 CI 管線來實作在此階段執行的單元和整合測試。 預備程序的輸出是一個發行分支，其觸發 CI/CD 系統以啟動生產階段。
1. 資料
預備環境應在 Unity Catalog 中具有自己的目錄，用於測試 ML 管線和將模型註冊到 Unity Catalog。 此目錄在圖表中顯示為「預備」目錄。 寫入此目錄的資產通常是暫時的，僅保留到測試完成時。 開發環境可能還需要存取此預備目錄以進行偵錯。
2. 合併程式碼
資料科學家使用開發或生產目錄中的資料表，在開發環境中開發模型訓練管線。
提取要求。 在原始檔控制中針對專案的主分支建立提取要求時，部署程序開始。
單元測試 (CI)。 提取要求會自動建置原始程式碼，並觸發單元測試。 如果單元測試失敗，提取要求會遭拒。
單元測試是軟體開發程序的一部分，在開發任何程式碼期間持續執行並新增至程式碼基底。 將單元測試作為 CI 管線的一部分執行，可確保在開發分支中所做的變更不會破壞現有功能。
3. 整合測試 (CI)
然後，CI 程序執行整合測試。 整合測試執行所有管線 (包括特徵工程、模型訓練、推斷和監視)，以確保它們一起正常運作。 預備環境應盡可能與生產環境緊密相符。
如果要部署具有即時推斷的 ML 應用程式，您應在預備環境中建立並測試服務基礎結構。 其中涉及觸發模型部署管線，其會在預備環境中建立服務端點並載入模型。
為了減少執行整合測試所需的時間，一些步驟可以在測試的逼真度與速度或成本之間進行權衡。 例如，如果模型訓練昂貴或耗時，您可以使用較小的資料子集或執行較少的訓練反覆項目。 對於模型服務，根據生產需求，可以在整合測試中執行全面負載測試，或者僅測試小型批次工作或對暫時端點的要求。
4. 合併至預備分支
如果所有測試都通過，新程式碼將合併到專案的主分支中。 如果測試失敗，CI/CD 系統應通知使用者並在提取要求上發佈結果。
您可以在主分支上排程定期整合測試。 如果此分支經常使用來自多個使用者的並行提取要求進行更新，這是個好主意。
5. 建立發行分支
通過 CI 測試且將開發分支合併到主分支後，ML 工程師會建立一個發行分支，這會觸發 CI/CD 系統更新生產工作。
生產階段
ML 工程師擁有部署和執行 ML 管線的生產環境。 這些管線觸發模型訓練，驗證並部署新的模型版本，將預測發佈至下游資料表或應用程式，並監視整個程序，以避免效能降低和不穩定。
資料科學家在生產環境中通常沒有寫入或計算存取權。 但是，他們必須能夠查看測試結果、記錄、模型成品、生產管線狀態和監視資料表。 這使他們能夠識別和診斷生產中的問題，並將新模型的效能與目前生產中的模型進行比較。 您可以授與資料科學家對生產目錄中資產的唯讀存取權，以實現這些目的。
編號的步驟與圖表中顯示的數字對應。
1. 訓練模型
此管線可以由程式碼變更或自動重新訓練工作觸發。 在此步驟中，生產目錄中的資料表用於下列步驟。
訓練和調整。 在訓練過程中，記錄將記錄至生產環境 MLflow 追蹤伺服器。 這些記錄包括模型計量、參數、標籤和模型本身。 如果您使用特徵資料表，則使用 Databricks Feature Store 用戶端將模型記錄至 MLflow，該用戶端將模型與在推斷時使用的特徵查詢資訊封裝在一起。
在開發期間，資料科學家可能會測試許多演算法和超參數。 在生產訓練程式碼中，通常僅考慮效能最佳的選項。 以此方式限制調整可節省時間，並且可以減少與自動重新訓練中調整的差異。
如果資料科學家可以唯讀存取生產目錄，他們也許可以確定模型的最佳超參數集。 在此情況下，可以使用所選的超參數集 (通常作為組態檔案包含在管線中) 執行部署在生產中的模型訓練管線。
評估。 透過對保留生產資料的測試來評估模型品質。 這些測試的結果將記錄至 MLflow 追蹤伺服器。 此步驟使用資料科學家在開發階段指定的評估計量。 這些計量可能包含自訂程式碼。
註冊模型。 模型訓練完成後，模型成品將儲存為 Unity Catalog 的生產目錄中所指定模型路徑的已註冊模型版本。 模型訓練任務會產生模型驗證任務可以使用的模型 URI。 您可以使用任務值將此 URI 傳遞給模型。
2. 驗證模型
此管線使用步驟 1 中的模型 URI，並從 Unity Catalog 載入該模型。 然後，它會執行一系列驗證檢查。 這些檢查取決於您的組織和使用案例，可以包括基本格式和中繼資料驗證、所選資料配量的效能評估以及符合組織需求 (例如標籤或文件的合規性檢查)。
如果模型成功通過所有驗證檢查，您可以將「挑戰者」別名指派給 Unity Catalog 中的模型版本。 如果模型未通過所有驗證檢查，程序將離開，並自動通知使用者。 您可以根據這些驗證檢查的結果，使用標籤來新增索引鍵/值屬性。 例如，您可以建立標籤 “model_validation_status”，並在測試執行時將值設定為 “PASSED”，然後在管線完成後將其更新為 “PASSED”或 “FAILED”。
由於模型已註冊至 Unity Catalog，因此在開發環境中工作的資料科學家可以從生產目錄載入此模型版本，來調查模型是否未通過驗證。 不論驗證結果如何，都會使用模型版本的註釋將結果記錄至生產目錄中的已註冊模型。
3. 部署模型
與驗證管線一樣，模型部署管線取決於組織和使用案例。 本節假設您已為新驗證的模型指派了「挑戰者」別名，並且已為現有的生產模型指派了「冠軍」別名。 在部署新模型之前，首先要確認其表現至少和目前生產模型相當。
將「挑戰者」與「冠軍」模型進行比較。 您可以離線或線上執行此比較。 離線比較可針對保留資料集評估這兩個模型，並使用 MLflow 追蹤伺服器來追蹤結果。 對於即時模型服務，您可能需要執行長期的線上比較，例如 A/B 測試或逐步推出新模型。 如果「挑戰者」模型版本在比較中表現更好，則會取代目前「冠軍」別名。
Mosaic AI 模型服務和 Databricks Lakehouse 監視可讓您自動收集和監視包含端點的要求和回應資料的推斷資料表。
如果沒有現有的「冠軍」模型，您可以將「挑戰者」模型與商務啟發或其他閾值進行比較作為基準。
此處所述的程序是完全自動化的。 如果需要手動核准步驟，您可以使用模型部署管線中的工作流程通知或 CI/CD 回撥來設定這些步驟。
部署模型。 您可以設定批次或串流推斷管線，以使用具有「冠軍」別名的模型。 對於即時使用案例，您必須設定基礎結構以將模型部署為 REST API 端點。 您可以使用 Mosaic AI 模型服務建立和管理此端點。 如果端點已用於目前模型，您可以使用新的模型來更新端點。 Mosaic AI 模型服務透過使現有組態保持執行直到新組態準備就緒，從而執行零停機時間更新。
4. 模型服務
設定模型服務端點時，您可以指定 Unity Catalog 中模型的名稱和要服務的版本。 如果模型版本是使用 Unity Catalog 中資料表的特徵進行訓練的，則模型會儲存特徵和函數的相依性。 模型服務會自動使用此相依性關係圖，在推斷時從適當的線上存放區查詢特徵。 此方法還可用于套用函數進行資料預先處理，或在模型評分期間計算隨需特徵。
您可以建立具有多個模型的單一端點，並指定這些模型之間的端點流量分割，讓您線上比較「冠軍」與「挑戰者」。
5. 推斷：批次或串流
推斷管線從生產目錄讀取最新資料，執行函數來計算隨需特徵，載入「冠軍」模型，對資料評分，並返回預測。 對於更高輸送量、更高延遲的使用案例，批次或串流推斷通常是最具成本效益的選項。 對於需要低延遲預測，但可以離線計算預測的案例，可以將這些批次預測發佈至線上索引鍵/值存放區 (如 DynamoDB 或 Cosmos DB)。
Unity Catalog 中的註冊模型由其別名參考。 推斷管線設定為載入並套用「冠軍」模型版本。 如果「冠軍」版本更新為新的模型版本，推斷管線會自動使用新版本進行下一次執行。 因此，模型部署步驟就與推斷管線分離了。
批次工作通常將預測發佈至生產目錄中的資料表、一般檔案或透過 JDBC 連線發佈。 串流工作通常將預測發佈至 Unity Catalog 資料表或訊息佇列，例如 Apache Kafka。
6. Lakehouse 監視
Lakehouse 監視可監視輸入資料和模型預測的統計屬性，例如資料漂移和模型效能。 您可以根據這些計量建立警示，或在儀表板中發佈警示。
- 資料擷取。 此管線從批次、串流或連線推斷讀取記錄。
- 檢查精確度和資料漂移。 管線計算有關輸入資料、模型預測和基礎結構效能的計量。 資料科學家會在開發期間指定資料和模型計量，而 ML 工程師則指定基礎結構計量。 您也可以使用 Lakehouse 監視來定義自訂計量。
- 發佈計量並設定警示。 管線會寫入生產目錄中的資料表，以供分析和報告。 您應將這些資料表設定為可從開發環境讀取，以便資料科學家可以存取這些資料表進行分析。 您可以使用 Databricks SQL 建立監視儀表板以追蹤模型效能，並設定監視工作或儀表板工具以在計量超過指定閾值時發出通知。
- 觸發模型重新訓練。 當監視計量顯示輸入資料存在效能問題或變更時，資料科學家可能需要開發新的模型版本。 您可以設定 SQL 警示，在發生這種情況時通知資料科學家。
7. 重新訓練
此結構支援使用上述相同模型訓練管線來自動重新訓練。 Databricks 建議從排程的定期重新訓練開始，在需要時移至觸發的重新訓練。
- 已排程。 如果定期有新資料可用，您可以建立排程工作以對最新的可用資料執行模型訓練程式碼。 請參閱 Databricks 工作的觸發程序類型
- 已觸發。 如果監視管線可以識別模型效能問題並傳送警示，則它也可以觸發重新訓練。 例如，如果傳入資料的分佈發生顯著變更或者模型效能降低，則自動重新訓練和重新部署可以透過最少的人為介入提升模型效能。 這可以透過 SQL 警示來實現，檢查計量是否異常 (例如，根據閾值檢查資料漂移或模型品質)。 警示可以設定為使用 Webhook 目的地，該目的地隨後可以觸發訓練工作流程。
如果重新訓練管線或其他管線出現效能問題，資料科學家可能需要返回開發環境，進行其他實驗來解決這些問題。