最近聽了一場微軟在EngineeringDaily的關於數據科學團隊協作和工作流的Podcast分享，覺得挺有意思，於是爬上去看了看，發現還是挺不錯的。這篇文章主要用來描述在微軟，數據科學項目是如何被執行落地和交付的。之後會再想辦法挖一下啊其他家大廠的這個方向上的工作流。當然我個人認爲工作流最有價值的點不是具體執行什麼內容，而是爲什麼要執行這些內容和什麼時候去執行這些內容。
順便貼一下原文地址：https://docs.microsoft.com/en-us/azure/machine-learning/team-data-science-process/。
概覽
大致的工作流流程
首先從大致的工作流程出發，這一點非常直觀。下邊兒這張圖比較簡明扼要的概括了一個數據科學項目有哪些流程。主要是：
- 商業理解
- 數據獲取清理
- 建模
- 部署
- 成果檢測與交付
角色介紹
具體這5個流程中每個流程應該完成那些事情，以及對應的Deliverable會在後面詳細介紹一下。然後在這整個5大塊的工作流程過程當中，又分爲一下4種角色：
- Solution Architect 解決方案架構師
- Project Manager 項目經理
- Data Scientist 數據科學家
- Project Lead 項目負責人
具體的這4個角色是如何在上邊兒幾個流程裏協同工作的流程以及不同流程的Deliverable可以參考下面這個流程圖：
標準模版項目結構
對數據科學團隊（大概4人以上）來說，標準化數據科學項目對於項目執行以及管理是非常重要的。如果團隊非常小，只有2個人，其實不太需要拘泥於標準化項目結構。但是當團隊擴張之後就需要有一個好的標準化的模版來參考。在微軟的標準數據科學項目中，一個項目主要由3個部分組成：項目文檔，數據源，代碼。這裏對於項目代碼文檔和項目功能性/商業需求文檔是分開的，項目代碼文檔應當存在代碼這個部分裏面。因爲看這兩類的人羣不一樣，意圖也不太一樣，所以最好分開。
數據科學項目技術架構與工具
這邊微軟的官方文檔上邊兒給了幾個推薦，分別是雲端存儲，數據庫，分佈式計算框架比如Hadoop和Spark集羣還有一些機器學習服務。他們的GitHub上面有專門的一個Repo來介紹工具。我這邊個人來講一般會把工具分爲3類：存儲，引擎，和算法平臺。具體每塊有哪些工具可以選型之後會再寫篇文章總結一下。不過這裏實際上去和項目應用的時候應當按照具體環境實施。如果有解決方案架構師的話，他們往往能給出非常不錯的參考建議。
詳細工作流程介紹
講完概覽，我們這邊來詳細講一下工作流程
階段1:商業理解
階段目標
- 定義問題：明確模型要解決的問題以及相關的評估標準。
- 定義數據源：明確解決這個問題所需要的數據是否是已有的或者是可能需要額外收集的。
如何達到這些目標
-
定義問題
- 在定義問題的過程中，我們需要知道整個項目想要預測分析的目標量是什麼。它可以是Regression來帶的Forecast，也可以是某個記錄爲某個特定Class的可能性。這裏其實就是需要 Data Science 團隊裏面能有人去提供行業背景知識和業務背景知識的了（Industrial Expertise）
- 明確問題的類型。微軟把數據科學解決的問題分爲了5個大類
- 迴歸：預測量
- 分類：預測類別
- 分組：就是Clustering，分組
- 異常檢測：也就是常說的Anomaly Detection
- 推薦
- 定義團隊角色和分工
- 定義可衡量的項目成功標準。這裏微軟推薦用SMART標準來制定這一標準：
- Specific
- Measurable
- Achievable
- Relevant
- Time-bound
-
定義數據源
這裏邊數據主要可以分爲兩類，一類就是我們的相關數據或者特徵, Indpendent Variables。還有一類就是Dependent Variable。前者可以去確保我們能夠通過建模來解決我們的問題，後者可以幫助我們評估模型的效果。
階段性交付內容
階段2:數據獲取清理
階段目標
- 構建一個乾淨的，質量優秀的，與階段1中的目標量相關且瞭解關係是什麼樣的數據集。並且將這分數據放在即將要建模的環境裏面。
- 構建一個能夠方便產生上述數據集的數據清洗管道。比如很多ETL都是做這個的。
如何達到這些目標
這一步主要有3步，主要是獲取數據，探索數據集，設置數據管道。下面分開講講。
- 獲取數據：這一步需要明確如何獲取數據，具體內容視架構而定。比如工具選擇上Sqoop還是Flume都得視具體環境決定。解決方案架構師應當幫助數據科學團隊明確技術選型。
- 探索數據集：數據探索分析，也就是常說的EDA。這裏微軟提供了一個樣例的數據探索分析的JupyterNotebook,非常具有參考價值。在數據探索完成之後，便可以開始着手對數據的組成以及情況進行了解，之後纔是進行建模。對數據分佈，組成，以及意義進行了解之後，在模型選擇以及構建這一步其實會更加的遊刃有餘。但是我們不可置否這一步常常會經常的重複進行，因爲我們也許會對數據質量不滿意或者認爲需要更多緯度/特徵。
- 設置數據工作流：這一步我們需要根據我們的數據以及軟件架構建造一個相對簡便的數據獲取自動化的流程。這一步往往有3種數據收集的方式：
- 批式收集
- 流式收集
- 二者混合
階段性交付內容
- 數據質量報告 可參考上方提到的樣例的數據探索分析JupyterNotebook
- 解決方案架構：它可以是數據管道的架構圖或者是解釋。我們會用這個架構來測試新構建的模型。這個結構應該也能夠支持我們基於新的數據來刷新之前構建的模型。
- 決策點： 重新評估項目，評估是否項目是否可行。
階段3:建模
階段目標
- 找出對於模型來說最適合的特徵
- 構造出一個最精準的可用於解決業務問題的機器學習模型
- 構造出一個適合部署的機器學習模型
如何達到這些目標
- 特徵工程
這一步會通過對於數據的總結，聚合以及變形來幫助構造新的特徵以達到分析的目的。如果我們想要知道模型的背後是怎麼構成的，那麼我們就得去理解特徵構成的規則以及我們使用的機器學習算法是如何利用特徵來構造出這些模型的。這一步其實需要算法能力和業務能力結合。特徵工程其實是在平衡儘可能找到相關特徵並且避免無關特徵。相關特徵會幫助我們提升模型的效果，但是無關特徵則會給數據集帶來很多噪音。
- 模型訓練
基於解決的問題類型不同，我們選擇的算法往往也不一樣。算法選擇方向上微軟有給一篇參考文章。模型訓練大致來說有以下4步：
- 切割數據爲訓練集合和測試集合
- 構建模型
- 評估模型
- 選擇最優解決方案
微軟這裏非常良心的給了一個Baseline模型的生成工具 是用R語言寫的。喜歡R的小夥伴們可以關注一下。但是這個文件最近一次更新是3年前，所以我估計也沒什麼人在用或者就是非常穩定導致沒有更新哈哈哈。
階段性交付內容
特徵列表：構建模型所用到的特徵列表。這裏微軟也有給出一個參考文檔，非常推薦。
模型報告：同樣，也有模版，不過個人認爲不要太糾結於模版，而是要思考模版裏邊兒的每一塊兒背後都是什麼，爲什麼要有它。
決策點：這裏有2個主要的決策點：1. 這個模型是否能夠解決我們提出的問題 2. 如果不能，我們是否需要去回到階段2重新收集數據，建模。
階段4:部署
階段目標
將模型成功部署到生產環境，爲線上業務提供穩定的服務。
如何達到這些目標
儘可能的將模型的部署做到組件化、積木化。具體取決於業務場景。個人認爲這塊兒主要分爲在線預測和離線預測的，這兩種場景的部署方式都是大不相同的。
階段性交付內容
- 模型性能以及表現的看板
- 模型部署結果報告
- 解決方案架構
階段5:成果檢測與交付
階段目標
交付項目，確認數據管道工作流以及模型效果和部署都能滿足需求方的目標。
如何達到這些目標
- 確認功能上模型能夠解決需求方的問題。
- 將項目交付給使用模型的組，或者是ML ops團隊。
階段性交付內容
項目結束報告，這裏微軟也有給出參考的文檔 主要還是總結歸納並且探索之後如何優化。其實還是離不開項目覆盤的那幾大塊。引用最近看的一個主播常說的這叫做一通百通。
結語
- 微軟在進行數據科學項目的規範化的時候我們還是能非常直觀的感受到大公司的這種流程制定標準的。某種程度上來說，它降低了公司的管理成本，同時也能幫助職員們更好的執行內容。但是這些的前提，我認爲還是需要去了解哪些流程是必要的，哪些流程是也許可以省略的。畢竟很多公司可能數據科學團隊就3個人，流程搞得太複雜反而會降低效率。
- 微軟也很認可數據科學項目需要和實際的業務應用場景結合，要接地氣。我相信對於在做數據科學的同學們來說，如何和行業專家有效交流的這種能力在這類項目裏面是非常寶貴的。
- 一個平臺型的工具，微軟Azure的ML Service，其實還是有一定的learning curve的。產品設計合理的時候，配合產品的培訓往往會給項目團隊帶來非常不錯的return。不過這裏也說到了，產品設計是否合理，其實是很難界定的。從我個人的角度出發，我覺得一個好的平臺型還是得能靈活多變，配套不同的使用場景。比如Excel，你甚至能在一些遊戲發佈會上看到這個產品的身影。當然，這裏的Trade off就是scale的成本。往往不標準化的產品，用的好的能上天，用不習慣的往往覺得設計反人類。
作者簡介：
魚哲， 阿里雲史上最年輕產品經理，有從0到1構建數據科學團隊的經驗，知名開源軟件Jupyter Lab貢獻者。
本文轉載自公衆號：“數據科學老司機”。
原鏈接：https://mp.weixin.qq.com/s/3Y6aNFXw-NdxaJ3m_8e5sQ