數據科學家和工程師的“五誡”

在實際的工作中，數據科學家們不僅要學會如何實用工具，還要懂得如何與同事合作。The Yhat Blog這篇文章探討了在實際的數據建模和數據處理的過程中數據科學家和數據工程師應該如何處理好關系順利地完成項目的問題。它引用“摩西十誡”的典故， 提出了給數據處理者的五個“誡律”。我們一起來參考一下!

1.了解你的數據

好的模型依賴于好的數據。要建立真正具有生產力的模型，數據科學家需要知道他們基于創造和存儲產品的數據庫是否可靠，以及數據庫更新的頻率。這些信息在項目開始之前就應該被收集并且分享給工程團隊，以避免項目進程之中可能產生的阻礙。

在 一個理想的世界里，科學家和工程師都應該提前做好應對即將發生的變化的準備(例如，多種變量類型之間的變化)，使他們能夠據此共同創建，測試和部署相應的 新版本。即使不能夠保證避免每一個程序中的事故，共享資源和盡早發現缺陷也可以使工程師們降低風險和預見解決可能出現問題的部分。

2.熟悉合作伙伴使用的工具

數 據科學家運用的主要編程語言是R或Python，這種語言便于數據的清潔，探索和建模。而工程師，卻需要使用多種不同的工具集來構建可擴展的網絡和移動應 用程序(例如，NET、Ruby on Rails、Node.js 或 JVM)。雖然期望一個人完全懂得使用這兩套工具是不切合實際的，但是跨過技術“藩籬”的限制對對方使用的語言和流程有一個基本的了解將大大有助于合作的 開展。

將統計代碼手動重新編寫為另一種語言是一項費時費力又極其容易犯錯的工程，所以當出現問題的擔憂增加的時候，建立良好的溝通機制(面對面和網絡數字化的)絕對是至關重要的。

3.了解技術的局限

當數據科學家和工程師運用不同的工具包工作的時候必然會遇到技術的限制。這常常使他們發狂，因為沒有人喜歡被要求返工，或者看著自己辛勤勞作創造出來的產品不理想，甚至更糟糕，看到自己的辛勤勞動付諸東流。

一 旦你清楚了模型開發和部署所需要使用的語言(見誡條2)，就應該花時間研究一下使用這種語言做什么是可能的，什么是完全不能夠實現的。然后就應該設定定期 的跨職能討論會的時間表，科學家和工程師雙方要經常溝通例如：你考慮在哪些方面做一些突破?雙方在哪些地方可以做出讓步?哪些又是技術完全實現不了的?有 沒有其他選擇?要實施需要付出多少努力?這些努力符合商業價值的考量嗎?

在實際工作 中，假設你是一個數據科學家正在為一個Ruby編寫的APP編寫一段使用R語言的反欺詐算法，那么你應該知道的是R的GLM功能(用于構建廣義線性模型的 函數)，在Ruby(或Java，對這個問題來說)中并沒有相對應的本地功能。這時候就需要大家一起來一場頭腦風暴來找尋出路啦。

4.互相尊重

在任何時候，一個數據科學家的工作總是需要大家共同的努力才能夠完成，在這個過程中充滿了產生誤解的可能。那我們的建議是什么呢?就是像老話講的，己所不欲，勿施于人。

對于數據科學家來說，你要做的就是寫出便于維護和使用的高質量的代碼，積極聽取工程師關于重構模型和采取更好替代方法的建議，詢問他們怎樣才是一個現實的可實行的時間表，你還能提供哪些幫助等。

對于工程師來說，與數據科學家合作，需要明確必須的職責，并且共同商討達成一份書面的處理問題的優先次序文件，遵循一個不斷更新的和現實的路線圖，并根據項目的進程不斷檢驗、細化和落實科學的數據模型。

5.履行你的責任和義務

有人認為一個模型一旦創造出來，并且投入了實際的商業運用，無論是創造它的數據科學團隊，還是實現了它的工程師們就可以自由地著手下一個大項目，不需要再管理這個項目了。這種想法是非常危險的。事實上，這只是分析的生命周期的另一階段的開始。

因 為，數據科學家和工程師建立生產過程中的監控和管理模型的計劃是非常重要的。誰將會監督模型和服務器的穩定性?如何將輸入和輸出數據存儲和共享?升級版 本，再培訓和重新測試的路線圖是什么?還要為解決可能出現的問題制作一個行動計劃。如果模型吞吐量增加怎么辦?擴展需要花費多少時間和金錢?由此確定共同 承認的公平的前期職責劃分，相應地分配團隊成員的工作時間。

總結

數據科學家和數據工程師都在朝著同一個目標努力：運用代碼建造程序來解決實際的商業問題。不幸的是，誤解和技術效率低下常常導致人們忽略了這一目標。當我們 在工作中處理和他人的關系的時候，雖然沒有萬能的神奇公式，但是這五個誡律應該可以在消除數據工程師和數據科學家之間的鴻溝上產生深遠的影響。