【51CTO.com快譯】敏捷編程是最常用的方法，它使開發團隊能夠將他們的軟件發布到生產中，經常收集反饋并細化底層需求。為了讓敏捷在實踐中發揮作用，需要允許自動構建修改后的應用程序并將其發布到生產中的流程——通常稱為持續集成/持續部署，或 CI/CD。CI/CD 通過定期讓實際用戶參與并反復整合他們的反饋，使軟件團隊能夠構建復雜的應用程序，而不會冒錯過初始需求的風險。

?[[436701]]??

數據科學面臨著類似的挑戰。盡管數據科學團隊錯過初始要求的風險現在威脅較小（這將在未來十年發生變化），但將數據科學自動部署到生產中所固有的挑戰使許多數據科學項目陷入停頓。首先，將任何東西放入生產系統時往往需要 IT 參與。其次，驗證通常是一項未指定的手動任務（如果它存在的話）。第三，可靠地更新生產數據科學過程通常非常困難，它被視為一個全新的項目。

那數據科學可以從軟件開發中學到什么？讓我們先看看軟件開發中 CI/CD 的主要方面，然后再深入研究哪些方面有相似之處以及數據科學家需要在哪些方面采取不同的轉變。

軟件開發中的 CI/CD

軟件開發的可重復生產流程已經存在一段時間了，持續集成/持續部署是當今普遍使用的標準。大規模軟件開發通常遵循高度模塊化的方法。團隊處理部分代碼庫并獨立測試這些模塊（通常對這些模塊使用高度自動化的測試用例）。

在 CI/CD 的持續集成階段，代碼庫的不同部分被插入在一起，并再次自動地整體測試。理想情況下，這種集成工作經常完成（因此是“連續的”），以便可以立即發現不會影響單個模塊但會破壞整個應用程序的副作用。在理想情況下，當我們擁有完整的測試覆蓋率時，我們可以確保幾乎立即捕獲由任何模塊更改引起的問題。實際上，沒有任何測試設置是完整的，完整的集成測試可能每晚只運行一次。但我們可以嘗試靠近。

CI/CD 的第二部分，持續部署，是指將新構建的應用程序遷移到生產環境中。每分鐘更新數以萬計的桌面應用程序幾乎不可行（而且部署過程更復雜）。但是對于基于服務器的應用程序，隨著越來越多的基于云的工具可用，我們可以更頻繁地推出更改和完成更新；如果我們最終推出了一些有問題的東西，我們也可以快速恢復。部署的應用程序將需要持續監控可能的故障，但如果測試做得好，這往往不是問題。

數據科學中的 CI/CD

數據科學流程往往不是由不同的團隊獨立構建，而是由不同的專家協作構建：數據工程師、機器學習專家和可視化專家。非常重要的是要注意，數據科學的創建與ML 算法開發（即軟件工程）無關，而是與 ML 算法在數據上的應用有關。算法開發和算法使用之間的這種差異經常引起混淆。

數據科學中的“集成”也指將底層部分整合在一起。在數據科學中，這種集成意味著確保特定工具包的正確庫與我們的最終數據科學過程捆綁在一起，并且，如果我們的數據科學創建工具允許抽象，則確保這些模塊的正確版本也捆綁在一起。

但是，在集成階段，軟件開發和數據科學之間存在很大差異。在軟件開發中，我們構建的是正在部署的應用程序。也許在集成過程中刪除了一些調試代碼，但最終產品是在開發過程中構建的。在數據科學中，情況并非如此。

在數據科學創建階段，已經構建了一個復雜的過程，以優化組合和轉換數據的方式和數據。這種數據科學創建過程通常會迭代模型的不同類型和參數，甚至可能在每次運行時以不同的方式組合其中的一些模型。集成過程中發生的事情是將這些優化步驟的結果組合到數據科學生產過程中。換句話說，在開發過程中，我們生成特征并訓練模型；在集成過程中，我們將優化的特征生成過程和訓練好的模型結合起來。這種集成包括生產過程。

那么什么是數據科學的“持續部署”？如前所述，生產過程——即需要部署的集成結果——不同于數據科學的創建過程。實際部署則類似于軟件部署。我們希望自動替換現有的應用程序或 API 服務，理想情況下使用所有常見的優點，例如正確的版本控制以及在生產過程中捕獲問題時回滾到先前版本的能力。

數據科學生產過程的一個有趣的附加要求是需要持續監控模型性能——因為現實往往會改變！變更檢測對于數據科學流程至關重要。我們需要建立機制來識別我們的生產過程的性能何時惡化。然后我們要么自動重新訓練和重新部署模型，要么提醒我們的數據科學團隊注意這個問題，這樣他們就可以創建一個新的數據科學流程，重新觸發數據科學 CI/CD 流程。

因此，雖然監控軟件應用程序往往不會導致自動代碼更改和重新部署，但這些是數據科學中非常典型的要求。這種自動集成和部署如何涉及（部分）原始驗證和測試設置取決于這些自動更改的復雜性。在數據科學中，測試和監控都是流程本身不可或缺的組成部分。我們較少關注測試我們的創建過程（盡管我們確實希望存檔/版本化解決方案的路徑），我們更關注持續測試生產過程。這里的測試用例也是“輸入-結果”對，但比測試用例更可能由數據點組成。

這種監控差異也會影響部署前的驗證。在軟件部署中，我們確保我們的應用程序通過測試。對于數據科學生產過程，我們可能需要進行測試以確保仍然預測標準數據點屬于同一類（例如，“好”客戶繼續獲得較高的信用等級）并且仍然捕獲已知異常（例如，已知的產品故障仍被歸類為“故障”）。我們還可能希望確保我們的數據科學過程仍然拒絕處理完全荒謬的模式。簡而言之，我們希望確保引用典型或異常數據點或簡單異常值的測試用例繼續按預期處理。

MLOps、ModelOps 和 XOps

所有這些與 MLOps、ModelOps 或 XOps（正如 Gartner 所說的 DataOps、ModelOps 和 DevOps 的組合）有何關系？提到這些術語的人往往會忽略兩個關鍵事實：首先，數據預處理是生產過程的一部分（而不僅僅是投入生產的“模型”），其次，生產環境中的模型監控通常只是靜態和非反應性。

目前，許多數據科學堆棧僅解決數據科學生命周期的一部分。不僅其他部分必須手動完成，而且在許多情況下，技術之間的差距需要重新編碼，因此生產數據科學過程的全自動提取幾乎是不可能的。在人們意識到真正生產化數據科學不僅僅是將一個包裝精美的模型扔在墻上之前，每當組織試圖可靠地使數據科學成為其運營不可或缺的一部分時，我們將繼續看到失敗。

數據科學過程還有很長的路要走，但 CI/CD 提供了很多可以借鑒的經驗教訓。但是，用于數據科學的 CI/CD 和用于軟件開發的 CI/CD 之間存在兩個根本區別。首先，集成過程中自動創建的“數據科學生產過程”與數據科學團隊創建的不同。其次，生產中的監控可能會導致自動更新和重新部署。也就是說，部署周期可能由檢查生產中數據科學流程的監控流程自動觸發，只有當監控檢測到重大變化時，我們才會回到戰壕并重新啟動整個流程。

【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】