2018年12月15日 星期六

敏捷開發與數據科學的故事



數據科學可以用敏捷的方法來跑嗎? 對於許多公司與團隊來說,數據科學家就像一個黑魔法自動販賣機,對於公司唯一能做的事就是定期把錢和原料投進進去,然後等待.....等待......等待新武器的產生。

所以許多公司很容對於這種投入很大,卻不容易估算預期產出的東西充滿恐懼....

而我們的故事是這樣開始的.....

團隊角色:

  • DS君:身處遠方的資料科學家
  • DE君:Python苦手的Data Engineer,號稱敏捷導入者
  • D-Team:由一群擅長邊緣運算(Edge Comuting)的邊緣人組成的維運一條龍團隊

最初的故事:


D-Team的主要任務是開發/維運系統,並且定期會準備資料交給DS君做實驗,而身處在遠方的DS君被賦予任務是研究Paper,並且希望從中找出各種可能用來優化推薦系統的演算法,由於平時獨立在遠方做研究,所以對於團隊來說是個魔法黑箱子的存在。

對於D-Team來說光是要處理開發和維運的事情就已經夠頭痛了,實在沒有太多精力去處理與追蹤DS君的進度,所以遲遲等不到魔法黑箱子所產生的新武器。

查克拉提煉敏捷導入:


其實要讓開發團隊和Data Scientist 能順利合作並且有產出就跟提煉查克拉一樣,是把兩種不同能量提取並且加以混和的一種技能!而要變強的關鍵就是要能進行控制持續放出的修練。




那要怎麼把這個查克拉修行法敏捷方法套到數據科學呢?
重點就是在 Iteration!Iteration!Iteration!
也就是透過的控制維持產出,持續改進Iteration的順暢



其實說穿了就是嘗試引入了幾個敏捷開發的元素:
  • Time Box
  • Experiment Story (類似User Story)
  • Iteration Process
  • Review Meeting

Time Box

一個實驗需要做多久/收集多少資料才能被檢驗?何時該放棄?畢竟每個實驗都是有成本的...

Experiment Story



在這邊我們嘗試使用Experiment Story 的方式來描述工作,透過讓目標和產出物更為明確,希望可以讓雙方的溝通夠為順暢,工作主要分為兩種:
  • DS君的研究與實驗 (POC)
  • DS君希望請DE君幫忙的實驗 (上線A/B Test)

通常的情境如下:
Phase1:DS君研究出一個方法,並且在小資料層級做出可能有效的實驗。
Phase2:DE君加入幫忙,把這個實驗程式Spark化,套用在Production 層級資料
Phase3:把這這個實驗串上Producton 層級的Data pipeline 做A/B Test。

Iteration Process

這部分主要是DE君的工作,跟D-Team 討論Data Pipeline該怎麼設計,怎麼把整個實驗掛上Production 的環境,讓實驗能快速的被修改與驗證。

Data Pipeline 舉例如下:

如果一個W2V的Model 要上線被測試,中間能被切成幾個階段,每個階段該把資料存在哪裡?各服務之間該怎麼呼叫和交換資訊?


並且在每個階段的資料都是可以被拿出來檢視和驗證的




Review Meeting

當定好了流程,接下來就是每個iteration 定期討論研究內容與後續方向,主要產出:
  • 研究週報 (請DS君每週產出一些實驗的數據和圖表提供討論)
  • 討論接下來的研究方向與Prouction化的可行性

心得 

做數據科學真得是燒錢又漫長的道路....XDrz...
先不論是否有沒有產出很厲害的 outcome,至少在持續交付 output 的部分有得到了很大的改善。


延伸閱讀:
[1] A manifesto for Agile data science


沒有留言 :