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

?[[436701]]??

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

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

軟件開發(fā)中的 CI/CD

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

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

CI/CD 的第二部分，持續(xù)部署，是指將新構(gòu)建的應(yīng)用程序遷移到生產(chǎn)環(huán)境中。每分鐘更新數(shù)以萬計的桌面應(yīng)用程序幾乎不可行（而且部署過程更復(fù)雜）。但是對于基于服務(wù)器的應(yīng)用程序，隨著越來越多的基于云的工具可用，我們可以更頻繁地推出更改和完成更新；如果我們最終推出了一些有問題的東西，我們也可以快速恢復(fù)。部署的應(yīng)用程序?qū)⑿枰掷m(xù)監(jiān)控可能的故障，但如果測試做得好，這往往不是問題。

數(shù)據(jù)科學(xué)中的 CI/CD

數(shù)據(jù)科學(xué)流程往往不是由不同的團隊獨立構(gòu)建，而是由不同的專家協(xié)作構(gòu)建：數(shù)據(jù)工程師、機器學(xué)習(xí)專家和可視化專家。非常重要的是要注意，數(shù)據(jù)科學(xué)的創(chuàng)建與ML 算法開發(fā)（即軟件工程）無關(guān)，而是與 ML 算法在數(shù)據(jù)上的應(yīng)用有關(guān)。算法開發(fā)和算法使用之間的這種差異經(jīng)常引起混淆。

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

但是，在集成階段，軟件開發(fā)和數(shù)據(jù)科學(xué)之間存在很大差異。在軟件開發(fā)中，我們構(gòu)建的是正在部署的應(yīng)用程序。也許在集成過程中刪除了一些調(diào)試代碼，但最終產(chǎn)品是在開發(fā)過程中構(gòu)建的。在數(shù)據(jù)科學(xué)中，情況并非如此。

在數(shù)據(jù)科學(xué)創(chuàng)建階段，已經(jīng)構(gòu)建了一個復(fù)雜的過程，以優(yōu)化組合和轉(zhuǎn)換數(shù)據(jù)的方式和數(shù)據(jù)。這種數(shù)據(jù)科學(xué)創(chuàng)建過程通常會迭代模型的不同類型和參數(shù)，甚至可能在每次運行時以不同的方式組合其中的一些模型。集成過程中發(fā)生的事情是將這些優(yōu)化步驟的結(jié)果組合到數(shù)據(jù)科學(xué)生產(chǎn)過程中。換句話說，在開發(fā)過程中，我們生成特征并訓(xùn)練模型；在集成過程中，我們將優(yōu)化的特征生成過程和訓(xùn)練好的模型結(jié)合起來。這種集成包括生產(chǎn)過程。

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

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

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

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

MLOps、ModelOps 和 XOps

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

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

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

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