如何讓你的數(shù)據(jù)科學(xué)家與數(shù)據(jù)工程師合作共贏

大數(shù)據(jù)文摘出品

來源：VB

編譯：張秋玥

開發(fā)機(jī)器學(xué)習(xí)模型過程漫長，數(shù)據(jù)科學(xué)家與數(shù)據(jù)工程師們需要通力合作——但實(shí)際上往往他們并不太能做得到這一點(diǎn)。

本文作者就表示，自己見過無數(shù)次模型花了幾個(gè)月時(shí)間才被投入生產(chǎn)，因?yàn)閿?shù)據(jù)科學(xué)家在等數(shù)據(jù)工程師建造適合該模型的生產(chǎn)系統(tǒng)，而數(shù)據(jù)工程師在等數(shù)據(jù)科學(xué)家建造適合生產(chǎn)系統(tǒng)的模型。

VentureBeat之前有篇文章報(bào)道說，87%的ML項(xiàng)目最終無法落地，其主要原因在于數(shù)據(jù)問題以及團(tuán)隊(duì)缺乏合作。從合作這個(gè)方面來說，數(shù)據(jù)科學(xué)家與工程師之間的緊張關(guān)系常常會導(dǎo)致毫無必要的延誤與失敗。盡管經(jīng)常開會確保大家互相理解共情可以緩解一下這一局面，要從根本上解決問題還是要使用MLOps技術(shù)。

在親身經(jīng)歷這種“折磨”過后，來聽聽作者是如何向我們傳授數(shù)據(jù)科學(xué)家與數(shù)據(jù)工程師的信任度提升大法的~

在討論解決方案之前，我們需要對問題進(jìn)行更深入的分析?？茖W(xué)家與工程師（無論是否是數(shù)據(jù)方面）常常是水火不容一般的存在。你隨便去網(wǎng)上搜一搜“科學(xué)家vs工程師”都能看到一大堆關(guān)于誰更厲害更高大上的爭論。工程師一般會接到一些搭建、運(yùn)營與維護(hù)的任務(wù)，因此他們會關(guān)注于如何建造最簡潔高效可靠的系統(tǒng)。而科學(xué)家們一般會接到建造最最精確的模型的任務(wù)，因此他們會希望能夠有權(quán)限接入所有的數(shù)據(jù)，并且能夠利用其建造復(fù)雜精密又獨(dú)樹一幟的模型。

與其著重強(qiáng)調(diào)區(qū)別，我認(rèn)為承認(rèn)雙方都會帶來巨大的價(jià)值并思考如何才能最大化雙方的技能更加高效。倘若我們關(guān)注于雙方的共同點(diǎn)——建立一個(gè)能夠提供及時(shí)并高質(zhì)量數(shù)據(jù)的穩(wěn)定系統(tǒng)——我們就能夠培養(yǎng)一個(gè)更加有協(xié)作性的環(huán)境了。通過了解雙方的痛點(diǎn)，兩個(gè)團(tuán)隊(duì)可以建立基本的共情與理解，以幫助他們合作愉快。此外，現(xiàn)在還有許多新興技術(shù)來幫助彌補(bǔ)兩個(gè)團(tuán)隊(duì)之間的差距。

MLOps是一項(xiàng)將DevOps思想應(yīng)用到數(shù)據(jù)科學(xué)與機(jī)器學(xué)習(xí)生態(tài)圈的新興技術(shù)。它減輕了數(shù)據(jù)科學(xué)家建立并維護(hù)的重負(fù)，同時(shí)為數(shù)據(jù)科學(xué)家提供了靈活性與自由度。這是一個(gè)雙贏的解決方案。我們接下來可以看一些常見的問題，以及這些新技術(shù)是如何解決他們的。

??

模型編制：將模型放到生產(chǎn)環(huán)境的第一個(gè)坎就是部署問題——部署到哪里，在哪里托管，怎么進(jìn)行管理。這主要是個(gè)工程問題。所以當(dāng)你的團(tuán)隊(duì)里既有數(shù)據(jù)科學(xué)家又有數(shù)據(jù)工程師的時(shí)候，它一般會由工程師們負(fù)責(zé)。

建立系統(tǒng)需要花費(fèi)數(shù)周甚至數(shù)月，而工程師們原本可以將其用于改善數(shù)據(jù)流或者模型來著。模型編制平臺可以幫助標(biāo)準(zhǔn)化模型部署框架，將這一步變得更加簡單。Facebook這種大公司有能力投資FBLearner這樣的平臺來處理模型編制問題，但對于小微企業(yè)來說這個(gè)方法不太具有可行性。幸好現(xiàn)在已經(jīng)出現(xiàn)了不少相關(guān)的開源平臺了——比如MLFlow和KubeFlow，他們都是使用容器化來解決模型部署基礎(chǔ)設(shè)施方面問題的產(chǎn)品。

特征庫：將模型投入生產(chǎn)的路上第二個(gè)坎兒是數(shù)據(jù)問題。經(jīng)常模型使用數(shù)據(jù)庫內(nèi)的歷史數(shù)據(jù)來進(jìn)行訓(xùn)練，但卻使用生產(chǎn)環(huán)境的數(shù)據(jù)來進(jìn)行預(yù)測。這兩個(gè)系統(tǒng)之間存在的差異經(jīng)常會導(dǎo)致模型表現(xiàn)極差。數(shù)據(jù)工程師會需要花費(fèi)大量精力來改動模型或環(huán)境來保證正常運(yùn)營。

我自己曾經(jīng)就花費(fèi)數(shù)周來搭建一些非常有用的特征，結(jié)果最后因?yàn)閿?shù)據(jù)工程師沒有精力將其生產(chǎn)化從而導(dǎo)致這些特征被丟棄。特征庫——也就是專門為ML模型訓(xùn)練與生產(chǎn)化而建立的數(shù)據(jù)庫——能夠通過保證開發(fā)環(huán)境中的數(shù)據(jù)和特征能夠立刻被生產(chǎn)環(huán)境所用而幫助改善這一問題。數(shù)據(jù)科學(xué)家們可以放心去建造模型，而數(shù)據(jù)工程師們可以不用花費(fèi)大量精力去保證兩個(gè)系統(tǒng)完全一致了。優(yōu)步和Airbnb這些大公司也有自己搭建自己的特征庫（分別是Michelangelo和ZipLine），不過第三方平臺在市面也可以見到了。比如所Logical Clocks就有為其Hopsworks平臺提供特征庫服務(wù)；我在Kaskada的團(tuán)隊(duì)也在建立一個(gè)基于事件的數(shù)據(jù)特征庫。

DataOps：因?yàn)槟Ｐ捅憩F(xiàn)不對勁所以深更半夜被同事打電話叫回公司已經(jīng)很惱火了，但更惱火的是，你經(jīng)常在檢查半天模型之后得出結(jié)論：是數(shù)據(jù)出現(xiàn)變化帶來的問題。

以下這種對話多得我都要聽吐了：

• 數(shù)據(jù)工程師：你的模型在報(bào)錯(cuò)，哪里壞了？

• 數(shù)據(jù)科學(xué)家：我的模型沒壞，是你的數(shù)據(jù)流壞了

• 數(shù)據(jù)工程師：OK那你跟我說哪個(gè)數(shù)據(jù)流壞了我改還不行嗎

• 數(shù)據(jù)科學(xué)家：我也不知道哪壞了但我知道就是壞了

發(fā)現(xiàn)這種問題的原因就跟大海撈針一樣困難。幸運(yùn)的是，我們現(xiàn)在有了新框架和新工具來對數(shù)據(jù)和數(shù)據(jù)源進(jìn)行監(jiān)管與測試，能幫我們節(jié)約大量的時(shí)間。Great Expectations就是一個(gè)例子——他們幫助改善數(shù)據(jù)庫建立、錄入以及監(jiān)控這些方面。還有一個(gè)數(shù)據(jù)流監(jiān)控的例子是Databand.ai——他們最近剛在Medium上發(fā)了篇文章，關(guān)于為什么傳統(tǒng)數(shù)據(jù)流監(jiān)控解決方案并不適用于數(shù)據(jù)工程與數(shù)據(jù)科學(xué)領(lǐng)域。

通過使用這些工具，團(tuán)隊(duì)可以降低需求復(fù)雜度并提升數(shù)據(jù)科學(xué)家與數(shù)據(jù)工程師之間的共情力與信任度。數(shù)據(jù)科學(xué)家可以放心去進(jìn)行開發(fā)，不用擔(dān)心會給工程師們帶來過大任務(wù)量。兩個(gè)團(tuán)隊(duì)都可以專注于進(jìn)行他們最擅長的各自領(lǐng)域的工作，而非如何和對方撕逼。這些工具能夠幫助我們將好斗的團(tuán)隊(duì)風(fēng)氣轉(zhuǎn)變成一個(gè)大家都開開心心和睦相處的環(huán)境。

相關(guān)報(bào)道：