1. 引入

如果要將AI嵌入到企業計算系統中，企業必須重新調整其機器學習（ML）開發流程以使得數據工程師、數據科學家和ML工程師可以在管道中自動化開發，集成，測試和部署。本博客介紹了與機器學習平臺進行持續集成（CI），持續交付（CD）和持續培訓（CT）的平臺和方法，並詳細介紹瞭如何通過特徵存儲（Feature Store）執行CI / CD機器學習操作（MLOps）。以及特徵存儲如何將整體的端到端ML管道重構爲特徵工程和模型訓練管道。

2. 什麼是MLOps

MLOps是最近出現的一個術語，描述瞭如何將DevOps原理應用於自動化ML系統的構建，測試和部署。持續交付基金會SIG-MLOps將MLOps定義爲：“是DevOps方法論的擴展，將機器學習和數據科學資產作爲DevOps生態中的一等公民”。MLOps旨在統一ML應用程序的開發和操作，使得團隊可以更容易更頻繁地部署更好的模型。Martinfowler.com將MLOps定義爲：“一種軟件工程方法，其中跨職能團隊能基於代碼、數據和模型以較小且安全的增量生成機器學習應用程序，並且可以在較短的週期內被複制和可靠地發佈。”

與Devops相比，MLOps的一些主要挑戰是如何處理版本化數據（不僅僅是版本化代碼），如何管理專用硬件（GPU）以及如何管理模型的數據治理和合規性。

3. DevOps vs MLOps

Git是世界上最受歡迎的源代碼版本控制系統，它用於跟蹤隨時間的變化並支持不同版本的源代碼。支持版本控制是自動化和持續集成（CI）解決方案的先決條件，因爲它可以以完全自動化的方式對任何環境進行可複製的配置。也就是說我們假定環境所需的配置信息和將要測試系統的源代碼都存儲在版本控制系統中。通常，在使用DevOps時，每次Git提交都會觸發軟件包的自動創建，這些軟件包可以僅使用版本控制中的信息就可以部署到任何環境中。

在大多數DevOps配置中，一般Jenkins與Git一起用作自動化服務器，以可控制、可預測的方式構建、測試和部署版本化代碼。Jenkins對於CI / CD管道遵循的典型步驟是：提供測試虛擬機（VM）/容器，將代碼簽出到計算機上，編譯代碼，運行測試，打包二進制文件和部署二進制文件。對於Java而言，在將二進制文件部署至暫存或生產系統中之前，會運行諸如maven之類的構建工具來編譯、測試和打包二進制文件。對於Docker，這意味着編譯Dockerfile並將Docker鏡像部署到Docker註冊表。

MLOps最具代表性的特徵可能是需要對數據和代碼進行版本控制，以實現可重現的訓練模型工作流。Git不適合作爲控制數據版本的平臺，因爲它無法擴展以存儲大量數據。

對於MLOps而言，Git和Jenkins還遠遠不夠，因爲MLOps的構建過程需要運行復雜的分佈式工作流，同時我們需要帶版本的代碼和數據，以確保可重現自動化構建。工作流就是我們所說的ML管道，即組件圖，其中每個組件都有入參和數據，成功的工作流會將模型部署到生產中。標準ML管道至少包括以下組件：驗證輸入數據，計算輸入數據的特徵，生成訓練/測試數據，訓練模型，驗證模型，部署模型以及在生產中監視模型。實際生產環境中這種簡化的管道可能會更加複雜，其中模型訓練階段可以細分爲超參數調整、 模型簡化測試和分佈式訓練。

已經有許多支持運行業務流程ML管道的端到端ML框架：TensorFlow Extended（TFX）支持Airflow、Beam和Kubeflow管道；Hopsworks支持Airflow；MLFlow支持Spark；Kubeflow支持Kubeflow管道。這些框架使工作流能夠自動執行，並且可重複執行，例如僅更改輸入參數就可以重新訓練模型，具有在組件之間傳遞數據的能力以及指定基於事件觸發工作流的能力（例如 在一天的特定時間，新數據到達時或模型性能降到給定水平以下時）。TFX，MLFlow和Hopsworks還支持使用Beam或Spark進行分佈式處理，從而支持在使用大量數據的集羣上橫向擴展。

3. MLOps: 代碼和數據版本化

3.1 Git風格的數據版本

由Dmitry Petrov開發的DVC，提供了一種對雲存儲中的文件/對象進行版本控制的開源工具，該工具使用Git來存儲有關文件和reflink（支持數據文件的透明寫時複製）的元數據，以確保 git目錄和數據文件的一致性。類似地，Kubernetes上的ML平臺Pachyderm也提供了使用類似git語義的數據版本控制平臺。但是，這些類似git的方法只跟蹤不可變的文件，而不存儲文件之間的差異。它們無法處理時間旅行（time-travel）查詢，例如“給我2016/2018年範圍內的訓練/測試數據”或“給我這些特徵在2018年9月6日的價值”。如果沒有時間旅行，它們將無法支持增量特徵工程，如僅對自上次運行（1小時前，一天前等）以來發生變化的數據計算特徵。

3.2 時間旅行查詢和增量拉取的數據版本控制

類似於git的數據版本控制系統的替代方法是使用提供版本化、結構化數據集的事務數據湖。版本化的數據集不僅具有其數據的模式（schema）版本，其中模式可能會隨着時間而演化，而且對數據湖的更新是原子化的，並通過提交（commit）進行標識。最著名的此類平臺是開源項目：Delta Lake，Apache Hudi，Apache Iceberg。用戶可以執行時間旅行查詢以返回給定的時間點（commit-id）的數據，或者返回給定時間間隔的數據，或者從給定的時間點變更的數據。它們使用索引（ bloom filters, z-indexes, data-skipping indexes）高效地執行時間旅行查詢，這些索引大大減少了需要從文件系統或對象存儲中讀取的數據量。事務性數據湖還允許客戶端僅讀取給定時間點以來數據集中的變更，從而可以開啓增量特徵工程，即僅針對最近一小時或一天中變更的數據計算特徵。

4. Hopsworks特徵存儲

用於機器學習的特徵存儲是一種特徵計算和存儲服務，它使特徵可以被註冊、發現和用作ML管道的一部分以及用於模型推理的在線應用程序。通常需要特徵存儲來存儲大量特徵數據併爲在線應用程序提供對特徵的低延遲訪問。它們通常實現爲雙數據庫系統：低延遲在線特徵存儲（通常是鍵值存儲或實時數據庫）和橫向擴展SQL數據庫，用於存儲大量特徵數據，用於訓練和批處理應用程序。在線特徵存儲使在線應用程序能夠在執行推理請求之前以接近實時的特徵數據豐富特徵向量。離線特徵存儲可以存儲大量特徵數據，這些特徵數據用於創建訓練/測試數據以用於模型開發，或者用於批處理應用程序以用於模型評分。特徵存儲解決了ML管道中的以下問題：

  • 通過在團隊/項目之間共享特徵以複用特徵管道；

  • 能夠大規模且低延遲地提供特徵；

  • 確保訓練和服務之間特徵的一致性，一次特徵工程後便可以緩存在在線和離線特徵存儲中；

  • 確保特徵在不同時間點的正確性，在做出預測並在稍後獲取結果時，也需要能夠查詢過去給定時間點上不同特徵的值。

ML的特徵存儲由在線和離線數據庫組成，並將來自後端系統的原始數據轉換爲經過設計的特徵，這些特徵可供在線和批處理應用程序進行推理，並可供數據科學家創建用於模型開發的訓練/測試數據。

大多數大型AI公司（Uber，Twitter，AirBnb，Google，Facebook，Netflix，Comcast）都建立了自己內部特徵庫，但也有兩個開源特徵庫：Hopsworks特徵庫（基於Apache Hudi / Hive，MySQL Cluster和 HopsFS）和Feast （基於Big Query，BigTable和Redis構建）。特徵存儲還使用的其他數據庫包括Cassandra，S3和Kafka，以及自定義鍵值存儲。

4.1. Hopsworks特徵存儲的端到端ML管道

MLOps和DataOps CI/CD管道與傳統DevOps的不同之處在於，它們可能由新的數據到達時進行處理而觸發（以及由於數據工程或模型訓練管道的源代碼更新而觸發）。DataOps涉及數據處理管道（在我們的情況下爲特徵管道）的自動化測試和部署，以及數據驗證和數據管道等階段。另外MLOps還涉及自動化訓練和部署ML模型，以及模型訓練、模型驗證和模型部署等階段。

特徵存儲支持將ML工作流分解爲兩個工作流：（1）用於工程特徵的“DataOps”工作流，並驗證將特徵存儲在特徵存儲的數據，以及（2）用於訓練模型的“ MLOps”工作流，使用特徵存儲中的特徵，分析和驗證這些模型，將其部署到在線模型服務基礎架構中以及監視生產中的模型性能。

一些ML生命週期框架（例如TensorFlow Extended（TFX）和MLFlow），都是基於端到端ML管道，這些管道以原始數據開始並以生產模型結束。但是，端到端ML管道的第一步將原始數據轉換爲模型的訓練數據可能會非常昂貴。Airbnb報告稱如果沒有特徵存儲，創建訓練/測試數據可能會花費數據科學家多達60-80％的時間。特徵存儲使轉換後的數據（特徵）可以在不同模型中複用。有了特徵存儲後，不再需要從原始數據到模型的端到端ML管道。可以將端到端ML管道分解爲兩個單獨的管道，每個管道都以自己的節奏運行：（1）特徵管道，這些數據管道從後端系統中提取數據，對其進行驗證，特徵化並緩存在特徵存儲中；以及（2 ）訓練管道，該訓練管道從特徵數據訓練模型，驗證那些模型並將其部署到生產中。

引入用於MLOps的特徵存儲的動機是，提取和特徵化新數據的過程與使用許多不同來源的特徵的訓練模型的過程是分開的。也就是說，與模型訓練的節奏相比，特徵工程的節奏通常存在差異。有些特徵可能每隔幾秒鐘更新一次，而其他特徵則每隔幾個月更新一次。另一方面，可以按需（定期（例如每天或每週））或在監視顯示模型的性能下降時對模型進行訓練。當新數據到達時，特徵工程流水線通常以固定的間隔觸發；當將源代碼推送到git時，特徵工程流水線通常按需觸發，因爲變更了特徵的設計方式。

4.2. 有狀態的ML管道

開發數據管道的最佳實踐是使它們無狀態且冪等的，以便在發生故障時可以安全地重新運行它們。但是，ML管道是具有狀態的。在將模型部署到生產之前，你需要一些上下文信息：該模型的性能是否比當前部署的模型好？該決策需要有關當前部署模型的狀態信息。理想情況下，我們還需要歷史狀態，這樣我們可以隨時間觀察和評估模型的性能，以及隨時間推移構建模型的處理時間/成功率。Hopsworks、TFX和MLFlow提供了一個元數據存儲，以使ML管道能夠做出有狀態的決策，記錄其執行步驟，存儲它們產生的artifacts以及存儲最終模型的來源。TFX和MLFlow都很麻煩，開發人員使用其組件模型（每個階段都有明確定義的輸入和輸出）在每個階段都需要重寫代碼，這樣他們可以截取組件的輸入參數，並將它們記錄到元數據存儲中。Hopsworks提供了一個很好的元數據模型，在該模型中，管道可以對HopsFS（HDFS）文件系統進行讀/寫操作，並使用Hopsworks API與特徵存儲進行交互。這樣，元數據事件、artifacts、執行（execution）和出處就隱式存儲到元數據存儲中，而無需像TFX或MLFlow那樣重寫notebook或python程序。

5. 特徵管道反饋Hopsworks特徵存儲

特徵存儲使特徵管道能夠緩存特徵數據以供許多下游模型訓練管線使用，從而減少了創建/回填特徵的時間。特徵組通常一起計算，並具有自己的攝取節奏，請參見上圖。可以使用流應用程序每隔幾秒鐘實時更新在線特徵存儲中的特徵，而批處理特徵可以每小時，每天，每週或每月更新。

在實踐中，特徵管道是數據管道，該管道的輸出是經過清理、驗證和特徵化的數據。由於通常無法保證輸入數據的正確性，因此必須驗證輸入數據，並且必須處理所有丟失的值（通常通過估算或忽略它們）。TFX數據驗證和AWS Deequ是兩種流行的數據驗證框架，它們支持擴展傳統的基於模式的數據驗證（例如，此列包含整數）以及數據驗證規則，以檢查數值或分類值是否等於預期。例如，雖然架構確保數值特徵爲浮點類型，但還需要其他驗證規則以確保這些浮點在預期範圍內。還可以進一步檢查以確保列的值是唯一的，而不是null，以確保其描述性統計信息在一定範圍內。然後，將經過驗證的數據轉換爲數字和分類特徵，然後將其緩存在特徵存儲中，隨後將其用於訓練模型以及進行批處理/在線模型推斷。

特徵管道與數據管道共享許多相同的最佳實踐DevOps實踐。數據/特徵自動測試的類型包括：

  • 所有特性代碼的單元測試和集成測試（將代碼推送到Git時，Jenkins可以運行這些測試）；

  • 測試特徵值是否在預期範圍內（TFX數據驗證或Deequ）；

  • 測試特徵的唯一性，完整性和獨特性（Deequ）；

  • 測試特徵分佈是否符合預期（TFX數據驗證或Deequ）；

  • 測試每個特徵與標籤之間的關係，以及各個信號之間的成對相關性（Deequ）；

  • 測試每個特徵的成本（自定義測試）；

  • 測試個人信息沒有泄漏到特徵中（自定義測試）。

當特徵存儲可用時，特徵流水線的輸出就是緩存特徵數據並存儲到特徵存儲。理想情況下，目標數據輸出需要支持版本化數據，例如Hopsworks特徵存儲中的 Apache Hudi 。在Hopsworks中，特徵流水線將數據向上插入（插入或更新）到現有特徵組中，其中特徵組是一起計算的一組特徵（通常是因爲它們來自同一後端系統，並且由某些實體或鍵關聯）。每當運行特徵管道時，都會在Hudi數據集中創建一個新的提交。這樣我們可以跟蹤和查詢對特徵存儲中特徵組的不同提交，並監視隨時間變化的攝取數據統計信息的變化。

6. 從特徵存儲開始的模型訓練管道

模型訓練管道屬於MLOps範式，在該模型中，從Hopsworks特徵存儲中的Apache Hudi讀取版本化的特徵，以創建訓練/測試數據，用於訓練模型，然後在生產中對其進行部署和監視。ML artifacts和執行（execution）的來源存儲在Hopsworks的元數據存儲中，並且ML管道由Hopsworks協調。

使用特徵存儲進行模型訓練通常在工作流中涉及至少三個階段（或程序）：

  • 選擇特徵，文件格式以及用於從特徵存儲中的特徵創建的訓練/測試數據集的文件系統（或對象存儲）。注意，對於Hopsworks特徵存儲，還可以提供時間戳（對應於Hudi commit-id）來重現訓練/測試數據集，就像過去的某個時間點一樣。

  • 使用在步驟1中創建的訓練數據集來訓練模型（訓練可以進一步分解爲以下步驟：超參數優化，模型簡化測試和模型訓練）；

  • 使用自動化測試驗證模型，並將其部署到批處理應用程序的模型註冊表和/或在線應用程序的在線模型服務器。

在Hopsworks平臺中，這三個步驟通常是python程序或Jupyter notebooks，它們作爲Airflow DAG（有向無環圖）的一部分執行。也就是說，Airflow協調了管道的執行。Airflow使DAG可以定期進行調度，但是也可以配置爲在新特徵數據到達特徵存儲區或模型訓練管道代碼推送Git提交時運行工作流。

在模型驗證步驟中執行的自動測試的類型包括：

  • 測試模型如何在不同的數據切片上執行以檢查偏差。

  • 測試模型對分佈特徵向量的魯棒性。

Hopsworks支持Jupyter notebook使用Google的假設分析（What-if）工具進行模型分析。研究反事實（將數據點與模型預測不同結果的最相似點進行比較）時非常有用，這樣可以更輕鬆地開發之後在生產管道中使用的模型驗證測試。

Google的假設分析工具可用於分析模型，詢問反事實並測試不同數據片段上的偏差。此處的知識發現可以轉移到模型驗證測試中。

6.1 監控在線模型

將模型部署到模型服務器以供在線應用程序使用時，我們需要監視模型的性能及其輸入特徵。我們需要確定生產中的輸入特徵在統計上是否不同於用於訓練模型的輸入特徵。在實踐中，我們可以通過將在訓練數據（可通過特徵存儲API調用訪問）上計算出的統計數據與在運行時從輸入特徵中收集的統計數據進行比較來做到這一點。在Hopsworks中，我們會將模型的所有預測請求發送到Kafka中的主題。然後便可以編寫一個Spark Streaming或Flink應用程序，該應用程序在Kafka中處理預測請求，在基於時間的窗口中計算統計信息，並將這些統計信息與特徵存儲中的訓練數據統計信息進行比較。如果給定特徵基於時間的Windows統計信息與訓練統計信息相差很大，則流應用程序可以通知ML工程師輸入功能與預期不符，流應用程序通常還可以爲模型計算業務級別的KPI，並提供一個UI，以使操作員能夠可視化模型的性能。更具體地說，要在在線監視中查找的錯誤信號包括：

概念漂移（Concept drift）

在模型中，目標變量是模型試圖預測的變量。例如，可能是金融交易被懷疑是欺詐或不是欺詐。當模型的統計屬性以非預期的方式隨時間變化時（例如出現了一個新的欺詐方案，該欺詐方案增加了欺詐的總量），概念就會漂移。

數據漂移（Data drift）

如果輸入特徵的統計屬性以意外的方式隨時間變化，則會對模型的性能產生負面影響。例如，如果用戶由於假期而執行了比正常情況多得多的金融交易，但模型並未經過訓練以處理假日，則模型的性能可能會降低（丟失欺詐行爲或將太多交易標記爲可疑） 。

特徵管道變化（Feature pipeline changes）

如果在特徵管道中計算特徵的方式發生了變化，並且在線模型使用在線特徵存儲中的特徵數據來豐富其特徵向量，則可能會對模型的性能產生負面影響。例如，如果更改了計算用戶執行的交易數量的方式，則可能會對模型的性能產生負面影響。

7. 總結

現在我們已經基於MLOps原理的特徵存儲涵蓋了端到端ML管道。通過更新管道代碼或新到達的數據，可以對變更進行持續測試，並可以持續更新模型並將其部署到生產環境中。我們展示了特徵存儲如何使整體式端到端ML管道分解爲特徵管道和模型訓練管道。我們還討論瞭如何使用現代數據湖框架（如Apache Hudi）進行數據版本控制。在下一個博客我們將更詳細地介紹ML管道和可重複的Hopsworks實驗，以及如何輕鬆地將管道從開發環境轉移到生產環境，我們還將展示如何使用Airflow開發功能管道和模型訓練管道。

相關文章