數據科學家幹嘛做 DevOps？
假如你打算繪製機器學習產品的管線圖，一開始你就要設計和訓練模型等，顯然這屬於數據科學職能。
按照正常的流程，通常在將模型投入生產的時候，將由數據科學過渡到基礎架構任務。直觀地講，在此時數據科學團隊會將事情交接給其他人，比如DevOps團隊。
但並非總是如此。在更多的情況下，數據科學家們還要把模型部署到生產環境中。
據Algorithmia稱，調查中大多數數據科學家，在模型部署這一任務上就花費了超過25%的時間。有趣的是，你可以看一下在數據科學家的招聘資訊中，有多少要求應聘者具有Kubernetes，Dockers和EC2等的「必要經驗」的，這足以驗證上面的調查結果。
為什麼數據科學家不必處理模型服務呢？
最簡單的回答就是，模型服務是基礎設施問題，而不是數據科學問題。你可以通過比較每個任務所使用的堆棧看出來：
模型開發 vs. 模型部署
當然，有些數據科學家喜歡DevOps，也能跨功能工作，但這樣的人畢竟是少數。事實上我想說，人們經常高估數據科學和DevOps之間的重疊程度。
反過來想，你會期望一個DevOps工程師能設計新的模型架構，或者擁有
豐富的超參數調整的經驗嗎？可能會有一些DevOps工程師掌握了這些數據科學技巧，也能學習這些知識。但將這些視為你的DevOps團隊的工作職責，是很奇怪的。
十有八九，數據科學家們不會擔心彈性收縮，或編寫Kubernetes清單。那為什麼公司還要讓他們這樣做呢？
公司忽略了他們的基礎設施
在很多組織中，人們根本不明白模型服務的複雜程度。他們的態度通常是，「現在只要在Flask中打包模型就夠好了」。
實際上，任何規模的模型服務都涉及一些基礎架構的挑戰。例如：
- 如何在不停機的情況下，自動更新生產中的模型呢？
- 一個運行在GPU上的５GB的模型，該如何有效地實現彈性收縮呢？
- 如何監視和調試生產部署呢？
- 如何在不消耗大量雲費用的情況下，完成所有這些工作呢？
現在，機器學習基礎設施是一個很新的概念。兩年前，Uber才透露了他們最先進的內部機器學習基礎設施，Michelangelo。機器學習基礎設施的很多方面還在發展之中。
然而，也有很多例子說明了，即使沒有Uber的工程資源，一個組織該如何區分數據科學和DevOps的關注點。
如何區分數據科學和DevOps
我對這些主題的看法，主要來自我在Cortex上的工作。Cortex是我們的開源模型服務平台，我們通過它把數據科學和DevOps區分開來，並且使我們正在編寫的所有基礎設施程式碼自動化。開源以後，我們一直與採用該平台的數據科學團隊合作，他們的經驗也為我們提供了參考。
我們構建了一個簡單抽象的架構，「模型-應用程式介面-客戶
」（Model-API-Client），來實現數據科學、DevOps和產品工程之間壁壘的概念化：
- 模型。一個經過訓練的模型，它包含一些predict()函數。即使不具備必需數據科學專業知識的工程師，也能使用這個模型。
- API。採用經過訓練的模型，並將其部署為Web服務的基礎結構層。我們構建Cortex來實現這一層自動化。
- 客戶。與部署在API層中的Web交互的實際應用程式。
在模型階段，數據科學家訓練並導出模型。他們還可能編寫用於模型生成和過濾預測結果的predict()函數。
然後他們將此模型交給API階段，這時完全由DevOps功能負責。對於DevOps功能，該模型只是一個Python函數，需要把模型轉化為微服務，集群化後完成部署。
一旦啟用了模型-微服務，產品工程師就會像對其他API一樣，對其進行查詢。對他們來說，這個模型只是另一個Web服務罷了。
模型-應用程式介面-客戶體系結構，並非唯一區分數據科學和工程的重點的方法。但是它表明了，不用花費過多的開銷或者構建昂貴的端到端平台，你也能夠劃清數據科學和DevOps之間的界限。
僅通過在機器學習管線的不同的功能之間，建立清晰的切換點，你就能解放數據科學家，讓他們去做自己最擅長的工作——數據科學。
原文鏈接，選題由雷鋒字幕組提供
