從軟件開發轉型為數據科學家,第一年該怎麼做?

萬事開頭難,從一個軟件開發程序員轉型為數據科學家,第一年該怎麼做?


一位博主就記錄了自己從全棧工程師轉行數據科學家第一年的心路歷程,包括好的方面和不好的方面,希望能幫助到同樣處境的人。

從軟件開發轉型為數據科學家,第一年該怎麼做?

我覺得自己非常幸運僱主給了我一個機會,讓我從一個全棧軟件開發人員轉型變成數據科學家,和內部數據團隊一起工作。

入職一年,我很享受這份工作給我帶來的全新挑戰,完全不同於以前做開發。我想寫這篇文章,首先是為了回顧過去一年所做的事情:我經歷的改變,我做得好的地方,我可以改進的地方。第二,通過記錄我曾經遇到過的問題和挑戰,我希望能幫助到和我處境相似的人。

在開始之前,我先介紹一下我的背景:我之前不是做軟件開發的,我擁有計算機科學的碩士學位和博士學位。因此,我不算冷啟動,我有工具、模型和分析方法方面的相關經驗。我從事開發工作將近8年。自從我的論文發表以後,我經歷了很多變動。

本文將分為兩部分。進展順利的部分和進展不佳的部分。對於那些只對結果感興趣的人,也可以拉到底直接看最後的結論。


Python 和 R

剛開始,我不確定在項目中該使用Python或R。所以一開始我對這兩種語言均作了研究學習,並在項目中結合使用了這兩種語言。

R經常讓我想起Matlab,兩者在用來編寫和執行代碼的界面非常像(我嘗試了R Studio和Visual Studio的R插件),同時寫代碼和處理數據的方法也很像。

但我只在碩士論文中用了R,還在博士學位論文中用了一些。除此之外,R和其他編程語言相比(這些年來,我在軟件開發中經常使用C#)就沒什麼共性了。R這個工具極度以數據為中心,與數據進行交互的方法也很不一樣。

在R裡有:列表,矩陣,向量,數組和數據幀。每個都有不同的使用場景,你需要學會什麼時候使用。R與C#的語法很不一樣,所以剛開始學R我遇到了不小的困難。我並不是說R不好,只是我使用Matlab10年,並且作為開發我的腦子已經習慣了某種思維方式,所以比較難轉變。所以我剛開始的時候覺得R很難上手。

作為一名有8年C#開發經驗的程序員,我覺得Python比R更容易起步。很可能是因為我的大腦已經習慣了C#的思維方式。python比R更接近於C#,所以我學Python比R快很多。

在使用這兩個語言時,我沒覺得兩者有明顯區別,尤其是對於可用的庫,兩者在我想做的工作的實現方面有差不多的處理能力,我也會得到相同的結果。但在摸索過程中,我對兩個工具分別都有些困惑。

總的來說,編程編久了, Python對於我的程序員思維更友好。

所以我很快放棄了學習R,轉而專注Python。這有助於我更快地進步,不必再花時間閱讀新語法,事情變得簡單許多,我一直覺得簡單才是王道。這對我應對角色的許多其他變化也是有幫助的,因此,這樣做可以最大程度地減少更改。

關於使用哪種以及何時使用,我敢肯大家定對此有很多意見,但是對我來說,從開發人員過渡到數據科學家後,我發現Python變得更容易掌握和使用,尤其是在我擔任新職位後想快速發展並取得成果的初期。

所以與R相比,使用Python讓我更快進入狀態,在輸出方面,我沒有發現兩者有任何明顯區別。所以我把這個歸類為進展順利,因為我很早做出了決定,且至今沒有遇到任何情況讓我覺得自己選錯了Python,相反我節省了不少時間,所以我能更快地開始工作。


文檔記錄


記錄一切我定義的一切是從模型超參數到從何處以及如何獲得訓練數據,到在整個項目中做出選擇的理由。另外,以有序的邏輯方式編寫文檔,實現這一目標的一個秘訣是, 哪怕你只是寫給自己看(例如,在我的情況下,我是唯一的數據科學家),你應該想象有人會讀這份文檔。

此外,記錄時要對自己有一定的約束,不要拖拉,不要走捷徑。不然等你開始寫的時候,你可能已經忘記一些需要注意的細節。因此一定要及時寫下來。在完成文檔之前,我覺得工作就還沒做完。我從一開始就遵循這種方法,我覺得至關重要。

我發現一件事是,即使在一箇中型企業,等到一個項目的研究成果在公司開始推廣已經是一段時間以後了,利益相關方因為有其他事要忙,所以不會立刻作出回應。

有時候在我完成一個項目幾個月後,有人跑來問我問題,我一時想不起來,但如果我翻看我之前做的文檔記錄就能馬上提供詳盡答案。例如,有一次我與另一位經理聊起幾個月前做的一個項目,我向他展示了我已經完成的工作,他問我訓練集的大小是多少,以及我用來獲取數據的日期區間。我並記不得那些數據,但我記得自己已經寫下過,而且我也記得寫在了哪裡。所以我能馬上把文檔拿給他們看。

我發現自己遇到的另一種情況是當業務優先級發生變化,你可能會需要停下手頭還沒完成的項目去做另一個項目。當你再回到之前開始的項目時,完整的文檔可以讓你從之前停下的地方繼續進行下去。


數據存儲

回顧前一年,進展不順利的一個原因是我

處理數據的方式(對於數據科學家而言這非常關鍵)。當我沒有使用數據庫的經驗時,我基本上覆用了在博士期間使用數據的方式。使用平面文件(特別是CSV)來存儲數據。我把從生產環境中提取的初始數據,清洗後的中間過程數據,分析後的數據和結果都存在了CSV裡。我工作流程中的每一步驟都需要通過Python腳本讀取上一步創建的文件,並創建新的文件。

這種把內容存儲在硬盤上,並通過Python腳本與數據交互的原始辦法,很快就出現了一些問題:

  • 有時很難在大量文件中找到我要找的那個文件。即使我記錄了文件的內容和位置,但有時還是很難找到我想要的確切文件,因為文件實在太多了。
  • 我似乎總是在忙著用Python把從文件中讀取數據或者將數據寫入文件。我寫了很多文件訪問的命令,但其實是在做重複勞動,寫這些代碼對我要做的工作並沒什麼幫助。
  • 想快速地將數據總結一下似乎都有點費力:讀取數據,彙總統計,輸出統計,查看統計結果。
  • 有些文件很大,用起來很困難(在notepad中打開10GB以上的文件很麻煩)。

第一年,我花了很長時間才意識到SQL是我的解藥

在從事數據科學家工作之前我使用過SQL,但是我一開始沒有意識到它對我的價值。當我意識到SQL就是我的解決方案後,我花了很多時間來學習更多有關SQL的知識,因為我在做程序員的時候稍微學了一點SQL。

具體來說,我學習瞭如何查詢數據(特別是我以前沒接觸過的高級語句)以及搭建和維護數據庫的基礎知識。我甚至通過了兩個Microsoft SQL的考試。我現在主張儘可能用SQL。我把所有項目的數據都存在了SQL數據庫中,儘量在SQL中做數據查詢和操作。

我的原則是:能在SQL中完成的處理,就在SQL中做。SQL處理不了的任務再用Python(例如,模型訓練和執行)這裡延伸出一個問題:你需要學會使用Python庫,例如 SQLAlchemy,從 SQL讀取數據到Python裡。

現在我的後SQL生活變得容易很多:

  • 所有項目數據存儲在一個容易找到的地方。
  • 沒有重複代碼用於讀寫文件。
  • 我能快速查詢數據並從數據中輕鬆得到統計結果。
  • 我能夠很容易地查看大量數據,特別是前幾行的數據。
  • 額外的好處是現在很容易把不同的數據聯繫起來,因為數據都已經在關係數據庫中了,現在安全性也提高了:把數據存在本地磁盤上有潛在的風險。數據都在服務器裡,安全很多。

因此,我強烈推薦學好SQL並用起來。


如何展示成果?


還有一個進展不順利的地方是我做的一些展示。從開發人員到數據科學家的一個變化是,我做演示的場合變多。展示的內容各種各樣,有面向技術人員的demo演示,有面向業務相關人員的項目報告,再到與公司內部其他部門討論項目工作,甚至向公司外部的第三方合作方展示工作。

對於這些人我覺得我沒有做好的一點是我沒有根據受眾來調整自己的展示方法。有些展示我做得還不錯,比如對開發人員的技術演示我覺得我做得還不錯。因為我跟技術人員擁有差不多的背景所以說技術的內容彼此也聽得懂,交流起來會更容易一些。其他類型的演示更難一些,不幸地是很多時候我在展示的時候才意識聽眾對我講的內容不是很在意。

我的受眾分為四類,從展示的難易程度來分如下:從最簡單的(最左邊)開始,到最難的(最右邊):開發人員,業務方,其他部門以及外部人員。

我還可以將最左邊的那些受眾標記為最技術性的,將右邊的那些受眾標記為更“銷售型”的,當從左向右移動時,兩者之間會有一個過渡。我發現針對左邊受眾的展示是最容易準備的——他們對我正在使用的技術或所從事的業務領域有深刻的瞭解。

針對外部人員的演示是最難的,因為他們往往相關知識最少。過去,我與這些聽眾進行交流的時候會直接進入到技術細節,就像我和左邊聽眾交流時一樣,但是結果很不好,因為他們不一定具有任何數據科學或機器學習的背景,所以我談論許多概念對他們沒有多大意義,他們不知道我在說什麼。對這些受眾來說,如果我花點時間介紹一下我正在做的工作以及更多的背景知識,效果會更好。甚至對某些受眾來說,向他們介紹機器學習的概念,為什麼我們要使用它以及它的好處。有時候,對我來說,不過多討論技術細節反而是好事,給他們一些大概的框架概念就好。

在反思了這一點之後,我現在在準備演示材料時,會更多地考慮我的目標受眾。具體來說,我會考慮聽眾可能知道或不知道的內容,以及需要向他們呈現的內容,以幫助我準備需要討論的內容和專業程度。這樣他們就可以更好地理解我正在談論什麼=,並從演示中得到一些收穫。為此,在準備演示文稿時我為自己準備了一些有用的問題,如下:

  • 聽眾對於數據科學領域瞭解多少?
  • 聽眾對於我試圖解決的問題了解多少?
  • 聽眾知道我在使用的技術嗎?
  • 聽眾對於我採用的技術細節或者結果感興趣嗎?

計劃


與做程序員時相比,做數據數據家的工作計劃更有挑戰。作為開發人員,工作相對比較直接,所以也更好估算和排期。你通常知道你要實現的目標以及如何實現。當我還是一名開發人員的時候,我使用敏捷開發工具。

因此,工作內容可以先評估、計劃,然後排好優先級就開始做。在敏捷的方法論指導下,如果工作沒什麼意義,或者你不清楚如何做,你就不會把它排進工作計劃。因為無法評估,因為未知,你要等到所有不明確的地方明確後才開展工作。

數據科學的工作並不像這樣簡單,對於給定的問題你不會總是提前知道什麼會起作用。也不會總是知道哪種類型的模型最準確。類似這樣的情況與剛才提出的觀點出現矛盾,當你是開發人員時,只有問題明確後,你才會把他們放入你的工作列表中。作為數據科學家,未知是你工作的一部分,因為你的工作就是要回答這些問題。或者你正在處理的問題可能會隨著項目進展而改變。因此,有時候你提前做的幾周計劃可能很快要重新考慮。

在計劃方面,我喜歡將開發工作視為線性的——你知道自己在做什麼以及如何做。數據科學工作我覺得是分叉樹,可能需要試不同的道路,可能會碰到死衚衕。

數據科學家做短期工作計劃還是可行的,比如你正在訓練和測試的模型之類的——接下來

一兩週的工作,但是,長期計劃很難做。你不可能總是提前知道什麼會起作用,什麼不會。所以我們才要進行實驗和測試,這是數據科學家工作的核心價值。

最後,花點時間去做不一定會有成果的工作,即使不起作用,也沒什麼大不了的。

回答正確的問題


在過去一年中(這讓我栽過很多跟頭),我發現數據科學工作的關鍵部分是回答問題,但更重要的是回答正確的問題。

正如我所說,我栽過幾次跟頭,當時我正在回答一個問題,但並沒有回答業務方實際想要回答的問題,之所以發生這種情況,是因為業務方使用的業務語言跟我用的的技術語言有差異,有時候我們用一樣的詞但要表達的意思卻不同。

針對這問題我的解決方法是在做項目的實際工作(現在稱為“項目前”工作)之前先做準備性工作,在這個階段,我會從業務方那裡收集初始需求和信息。做一些初步分析,然後給業務方展示。

運用敏捷的工作思路,我希望在每個sprint實現一個可交付的成功,並向業務方展示該成果。這樣,我與業務方建立了一個有效的循環反饋機制,向他們展示一些東西並詢問他們的意見,這可以建立一個有效對話,從而更清晰地定義真正要解決的問題。這個方法在項目各個階段都有效,不僅僅是初始階段。當你向業務方展示你的工作結果時,可能會激發他們不同的想法以及他們之前沒有考慮過的思路。從而你能找到他們真正的痛點。

所以過去一年來我發展的一項關鍵技能是與業務方的互動交流,深入挖掘他們真正想要的東西。


總結

Python比R更容易學習,因為對於程序員來說python與其他編程語言更接近。

  • 邊執行邊做文檔
  • 學習如何使用關係數據庫,比如SQL,用數據庫來查詢,操縱和存儲數據。
  • 你需要準備很多展示,不僅是向項目業務方的報告,還要向公司其他同事報告,甚至是公司外面的人。
  • 你需要提高演講能力以滿足不同受眾(技術或非技術)的需求。

工作計劃不是一帆風順的,因為你無法預知什麼起作用什麼無效,要有心理準備有時候花了時間不一定取得預想的結果。

花時間找你真正要解決的問題,不要不加思考就埋頭開始做,與業務方建立反饋閉環是很有必要的。

-END-


分享到:


相關文章: