數據科學項目管理中的“黃金標準”
大數據文摘出品
編譯:茶西、陳同學、Aileen
如何建立一個數據科學項目管理?建立的標準又是什么?
我想大多數人至少承認這一點:“你的研究需要讓其他人能夠輕松地理解你在項目中做了什么,并能復制這些結果”。
此外,你還得對文件的命名方式多加注意,具體做法如何,我們一起來看看吧。
研究結果的可復制性和分享性
首先,你所做的項目必須具有非常強的可復制性以及可分享性,因為只有這樣才能讓你的同行檢驗項目的成果。
例如,杜克大學的研究人員曾經發表了一項關于將個人基因信息用于患者化療的研究。來自MD Anderson癌癥研究中心的兩位研究人員Baggary和Coombs想要對研究進行復現。但是復現之前必須獲取數據和代碼是必須的。
經過數月的時間,終于,這兩位認真的研究人員拿到了想要的數據和代碼。雖然,拿到的時候這些資料還是未經整理、雜亂無章的。
又經過很長時間的實驗驗證,這兩位研究人員發現已發表的研究中的代碼出現了一個錯誤,這個錯誤嚴重到研究的成果會將患者置于危險境地。
所以,幾個月份來,兩位研究者一直在對一項錯誤的研究進行復現,更重要的是,他們大多數的時間花費到了“無意義”的數據收集與整理上。
這就是弱分享性以及弱復制性帶來的危害,驗證實驗結果可能花費不了多少成本。但是由于研究作者對數據的保護,使得你需要用更長的時間收集相關數據。
那么,為什么研究者大多不愿意分享研究數據呢?
當你聯系一個研究員想要獲得他的研究的源代碼和初始數據時,你需要解釋你是誰,你為誰工作,為什么需要這些數據,以及你要如何處置這些數據。
另外,你還經常收到如下回復:
- 我不得不說如果沒有解釋的話,這就是一個不太正常的要求。請讓你的導師發一封詳細的,我再強調一遍,詳細的郵件給我來解釋一下。
- 這些數據文件是我們的資產,并且不是免費使用的,所以請告訴我們你想要用這些文件來做什么,然后我們看看可以如何幫到你。
- 我們通常不會將我們的內部數據分享給非合作單位。
- 這些代碼是我和同事多年努力的結晶,這些數據也是我與合作者們千辛萬苦花了很長時間收集到的,所以也需要得到他們的允可。
- 通常我們不會提供這類數據給不認識的人。可能你想要查驗數據分析,這可能對于我們也有用,但是在你發表你的研究時請恰當地提到我們。.
- 感謝你對我們的文章感興趣。在計算中我用的是我們自己的代碼,目前還沒有公共版本可供下載。鑒于目前的代碼不是很易用,而且還在持續改進中,所以我傾向于暫不分享。
- 很抱歉我們的代碼在創建時并沒有想過給他人使用。代碼現在并未文檔化,我們也沒有時間和資源來文檔化。如果你有一個特別的計算要做,且不是我們現在做的東西的主要延伸的話,我們可以幫你跑這個代碼。
- R是一個免費的軟件,你可以在www.r-project.org/找到。我用R是因為XX模型。你可能有所了解XX和XX十分復雜。但是我可能不必說這些你已經是個統計學學生了。我都是用Matlab來處理幾何的問題。
所以,建議你在閱讀研究成果時,先看是否有一份附有所有的原始數據和代碼的可重復性聲明。如果沒有看到一份這樣的東西,你可以暫時忽略這個研究。
可重復使用說明范例
不能讓你的項目具有可復制性是學術上的不端行為,可能會產生嚴重的后果。例如“未能妥善記錄和保存研究成果”是近日康奈爾大學研究員Brian Wansink的受到的不光彩的指控之一 。
在Daniele Procida關于軟件文檔的黃金標準上,他很好地總結了這一點:
“不管你的軟件有多好,如果說明文檔不夠好,人們就不會使用它。即使出于某種原因,人們沒有選擇而不得不使用它,沒有好的說明文檔的話,大家也不能有效地使用它,更不會按照你希望的方式使用它。” |
因此,遵循Procida先生的明智建議,你的研究需要讓其他人能夠輕松地理解你在項目中做了什么,并能復制這些結果。這對于現在和同事的合作至關重要,也對后人有很大幫助(例如,未來某一天你要重新運行一個六個月沒碰過的分析的時候,或者任何其他研究員想要重新看一看你的工作的時候)。Leek認為 “花費數據科學項目中10-20%的時間來對你的工作進行組織與文檔化”是非常重要的。
文件命名
文件的命名的方式在數據科學項目中也是非常重要的。
一位對R語言腳本設計、工作流程和文件組織與命名方面頗有見地的數據科學家Jenny Bryan認為有三個原則是必須遵守的:
- 機器可讀
- 人類可讀
- 很好地處理默認排序
為了機器的可讀性,我們希望避免空格、標點符號、句號和任何其他特殊字符(除了“_”和“-”)。
針對人類的可讀性,需要您給文件賦予有意義的名稱。當命名R對象時,如果包含了注釋的話,縮寫對象名稱的也是可以的。例如,cv_perf_Recoke_rf是對隨機森林模型的每個交叉驗證的驗證召回的計算。
但是在命名文件時,我建議除非絕對必要,不要使用縮寫詞;如果使用了的話,請在自述文件中列明這些信息。
另外一個建議是將日期和數字放在文件名的開頭。始終使用ISO 8601的日期格式(yyyy-mm-dd)和左起帶0的數字。數字的最大位數取決于一共要生成多少個文件。假設你想要保存100個建筑MRI圖像文件,那么它應該看起來如此001_t1_mri.nii.gz。假設你認為你實際上會生成1000個文件,它看起來應該如此0025_t1_mri.nii.gz。
Leek還指出,應該避免大小寫的敏感性,例如Esophageal-Cancer_Report.md(食道癌報告.md)顯然是一個可怕的文件名(輸入這串包含大小寫的字母和字符真是累死了)。
你也可以用esophagealCancer_report.md,因為它更能看起來更令人愉快,也并未有Leek提到的風險;只要不要忘記在linux中使用find指令時用-iname標志來忽略大小寫就好。如果你健忘,或者只是效率很高(也就是懶),你總是可以把它包含在.bashrc文件中作為別名。
讓文件名以大寫字母開頭顯然是個壞主意,因為它會導致你需要額外的按鍵來生成大寫字母(例如Shift)。然而,使用camelCase方式,您可以通過使用選項卡來自動完成以避免額外的按鍵。
OMT
如果你使用R,你應該讀一讀Jenny Bryan的here()包,它消除了setwd()可能導致的麻煩的工作流程問題。
另外,建議大家去閱讀她的博客文章“面向項目的工作流程”它清楚明白的告訴我們更多關于“怎樣做”以及“為什么這樣做”的信息。
面向項目的工作流程:https://www.tidyverse.org/articles/2017/12/workflow-vs-script/
遵循這個數據科學項目管理黃金標準的建議,在處理“大數據”時你將得心應手許多。
相關報道:
https://www.r-bloggers.com/the-gold-standard-of-data-science-project-management/amp/
【本文是51CTO專欄機構大數據文摘的原創文章,微信公眾號“大數據文摘( id: BigDataDigest)”】