1.4 MLOps需求層次

考慮機器學習系統的一種方法是考慮馬斯洛的需求層次，如圖1-2所示。金字塔的較低層反映了“生存”需求，人類的真實潛能在基本生存和情感需求得到滿足之后才會出現。

同樣的概念也適用于機器學習。ML系統是一個軟件系統，當DevOps和數據工程最佳實踐到位的話，軟件系統能有效、可靠地運行。如果組織中DevOps的基本規則不存在或數據工程沒有完全自動化，那該如何發揮機器學習的真正潛能？圖1-3的機器學習需求層次不是一個明確指南，但是一個好的開始。

阻礙機器學習項目的主要因素之一是必要的DevOps基礎。這個基礎完成后，接下來是數據自動化，然后是平臺自動化，最后是真正的ML自動化或MLOps。MLOps的巔峰是一個有效的機器學習系統。那些操作和構建機器學習應用程序的人是機器學習工程師或數據工程師。讓我們從DevOps開始深入了解ML層次的每一步并確保你牢牢掌握如何實施它們。

1.4.1 實施DevOps

DevOps的基礎是持續集成。沒有自動化測試，DevOps沒辦法向前推進。對用現代工具創建的Python項目來說，持續集成相對比較容易。第一步是搭建Python項目的腳手架，如圖1-4所示。

Python機器學習項目的運行環境大多在Linux操作系統上。因此，后續的Python項目結構直接用來實現機器學習項目。你閱讀本節時，可以訪問此源代碼GitHub（https://oreil.ly/4dei0）上的示例來參考。具體包含如下組件：

Makefile

Makefile是基于Unix的操作系統中通過make系統運行的“配方”（recipe）。因此，Makefile是簡化持續集成步驟的理想選擇。Makefile是一個項目很好的起點，并且通常演化成需要被自動化的新片段。

如果你的項目使用Python虛擬環境，則在使用Makefile之前你需要對虛擬環境進行源代碼配置，因為Makefile只運行命令。Python新手經常將Makefile與虛擬環境混淆。類似地，假設你使用Microsoft Visual Studio之類的代碼編輯器。這種情況下，你需要告訴編輯器你的Python虛擬環境，這樣它才能準確地提供語法高亮、代碼校驗和其他可用庫。

Make install

此步驟通過make install命令安裝軟件。

Make lint

此步驟通過make lint命令檢查語法錯誤。

Make test

此步驟通過make test命令運行測試。

requirements.txt

requirements.txt是Python默認安裝工具pip中使用的約定。如果不同的包需要安裝不同環境的話，一個項目可以包含一個或多個這種文件。

源代碼和測試

Python腳手架的最后一部分是添加源代碼文件和測試文件，如下所示。這些腳本保存在文件hello.py中：

接下來，使用pytest框架創建測試文件非常簡單。這個腳本將在與hello.py相同目錄的test_hello.py中，這樣from hello import add能夠正常工作：

Makefile、requirements.txt、hello.py和test_hello.py這4個文件都需要開始持續集成之旅，除非創建本地Python虛擬環境。為此，首先創建它：

請注意，通常有兩種方法可以創建虛擬環境。首先，許多Linux發行版包含命令行工具virtualenv，它的功能與python3 -m venv相同。

接下來，運行source命令激活這個環境：

為什么要創建和使用Python虛擬環境？這個問題對Python新手來說十分普遍，這里有一個直觀的回答。因為Python是一種解釋型語言，它可以從操作系統的任何地方“抓取”庫。Python虛擬環境把第三方包隔離到特定目錄。還有很多其他工具也可以解決這個問題。它們有效地解決了同樣的問題：Python庫和解釋器獨立于特定項目。

設置好Python腳手架后，你可以執行以下本地持續集成步驟：

1.使用make install為項目安裝庫。

輸出類似于圖1-5［此例展示GitHub Codespaces（https://oreil.ly/xmqlm）中的運行］

2.運行make lint對項目進行代碼校驗：

3.運行make test來測試項目：

如果這個過程在本地生效，就可以直接將相同過程集成到遠程SaaS構建服務器。具體選項包括一個云原生構建服務器（如AWS Code Build、GCP CloudBuild、Azure DevOps Pipelines）GitHub Actions，或者一個開源自托管構建服務器（如Jenkins）。

1.4.2 GitHub Actions持續集成環境配置

實現持續集成的最直接方法之一是將Python腳手架項目與GitHub Actions一起使用。為此，你可以在GitHub UI中選擇“Actions”來創建一個新對象，或者在你創建的目錄中生成一個新文件，如下所示：

GitHub Actions文件可以直接創建，如下就是一個例子。請注意，要根據Python項目解釋要求配置確定的Python版本。在這個例子中，我想檢查在Azure上運行的特定Python版本。持續集成的步驟很容易完成，因為困難是在前期生成Makefile：

當在GitHub上執行“push”事件時，GitHub Actions的概覽如圖1-6所示。

此步驟完成了設置持續集成的最后一部分。把機器學習項目自動推送到生產環境的持續部署是下一個邏輯步驟。這個步驟會利用持續交付流程和IaC（基礎設施即代碼）把代碼部署到指定位置，如圖1-7所示。

1.4.3 DataOps和數據工程

ML需求層次的下一步是數據流的自動化。例如，想象一個只有一口井的城鎮。日常生活很復雜，因為我們根據需求來安排水的流動路線，我們認為理所當然的事情可能無法正常工作，例如按需熱水淋浴、按需洗碗或自動灌溉。同樣，沒有自動數據流的組織也不能可靠地做MLOps。

許多商業工具正在發展以執行DataOps。例如，由Airbnb設計、后來開源的Apache Airflow（https://oreil.ly/p55kD）可以調度和監控其數據處理任務。AWS的工具包括AWS Data Pipeline和AWS Glue。AWS Glue是一種無服務器ETL（提取、加載、轉換）工具，它能檢測數據源的模式，然后存儲數據源的元數據。其他工具像AWS Athena和AWS QuickSight可以查詢和可視化數據。

這里要考慮的一些要素有數據規模、信息變更頻率、數據清洗程度。許多組織使用集中式數據湖作為所有數據工程活動的集中地。數據湖有助于構建自動化的原因是，它在I/O方面提供了“近乎無限”的規模，同時還具有高耐用性和可用性。

數據湖與基于云的對象存儲系統（如Amazon S3）是同義的。數據湖允許數據“原地”處理而無須四處移動。數據湖通過近乎無限的容量和計算特征來實現這一目標。

當我在電影行業工作時，像《阿凡達》（https://oreil.ly/MSh29）這樣的電影，數據量巨大，移動數據需要通過一個超級復雜的系統才能完成。現在有了云，這個問題就解決了。

圖1-8展示了一個基于云數據湖的工作流。許多任務都在確定的位置執行，而無須移動數據。

專門的職位，例如數據工程師，可以把所有的時間都花在構建處理這些不同用例的系統上：

? 定期收集數據和運行作業。

? 處理流式數據。

? 無服務器和事件驅動的數據。

? 大數據作業。

? ML工程任務的數據和模型版本控制。

就像一個沒有自來水的村莊不能使用自動洗碗機，一個沒有數據自動化的組織無法使用先進的機器學習方法。因此，數據處理需要自動化和可操作化。此步驟使ML任務能夠沿著該鏈條進行操作和自動化。

1.4.4 平臺自動化

一旦有了自動化數據流，下一步就要考慮組織怎樣使用高級平臺構建機器學習解決方案。如果一個組織已經將數據收集到云平臺的數據湖中，例如Amazon S3，那么將機器學習工作流綁定到Amazon SageMaker是很自然的。同樣，如果一個組織使用谷歌，那么它可以通過谷歌AI平臺或Azure使用Azure Marching Learning Studio。同樣，如果一個組織使用Kubernetes而不是公有云，則Kubeflow（https://kubeflow.org）是合適的。

解決這些問題的一個比較好的平臺示例如圖1-9所示。AWS SageMaker為現實世界的機器學習問題編排了一個復雜的MLOps序列，包括啟動虛擬機、讀寫S3、配置生產端點。在生產環境中執行沒有自動化的基礎設施步驟是魯莽的。

ML平臺解決了現實世界的重復性、可擴展性和可操作性問題。

1.4.5 MLOps

假設所有需求層次都已完成（DevOps、數據自動化和平臺自動化）MLOps是可能的。記得之前說過使用DevOps方法自動化機器學習過程就是MLOps。構建機器學習系統的方法就是機器學習工程。

因此，MLOps是一種行為，就像DevOps是一種行為一樣。如果有些人作為DevOps工程師工作，那么軟件工程師就能使用DevOps最佳實踐更頻繁地執行任務。類似地，機器學習工程師就能使用MLOps最佳實踐來創建機器學習系統。

DevOps和MLOps是最佳實踐的結合嗎

還記得本章前面描述的DevOps實踐嗎？MLOps建立在這些實踐之上并將其擴展來直接處理機器學習系統問題。

闡明這些最佳實踐的一種方法是考慮它們創建了具有穩健模型打包、驗證和部署的可重復模型。此外，也增強了模型的解釋性和性能監控能力。圖1-10給出更多細節。

反饋循環包括以下內容：

基于可重用ML管道創建和重新訓練模型

僅創建一次模型是不夠的。數據會變，客戶會變，建模人員也會變。該解決方案是版本化的可重用ML管道。

機器學習模型的持續交付

ML模型的持續交付類似于軟件的持續交付。若所有步驟都實現了自動化，包括自動化基礎設施，使用IaC，則模型在任何時間都可以部署到新的環境中，包括生產環境。

MLOps管道的審計跟蹤

對機器學習模型進行審計至關重要。機器學習中有很多問題，包括安全性、偏見和準確性。因此，有用的審計跟蹤功能是非常重要的，就像生產環境中軟件工程項目的日志功能。此外，審計跟蹤是反饋循環和實際問題的一部分，這樣你可以不斷改善問題的解決方法。

觀察模型數據漂移以改進未來的模型

機器學習的獨特性之一是模型的數據會產生“漂移”。兩年前為客戶工作的模型，今天很可能不再適用。通過監控數據漂移，即自上次模型訓練后的數據變化增量，我們可以在生產環境出現問題之前避免準確性問題。