如何建立一個數據科學專案？
摘要： 在一個新的資料科學專案，你應該如何組織你的專案流程？資料和程式碼要放在那裡？應該使用什麼工具？在對資料處理之前，需要考慮哪些方面？讀完本文，會讓你擁有一個更加科學的工作流程。
假如你想要開始一個新的資料科學專案，比如對資料集進行簡單的分析，或者是一個複雜的專案。你應該如何組織你的專案流程？資料和程式碼要放在那裡？應該使用什麼工具？在對資料處理之前，需要考慮哪些方面？
資料科學是當前一個不太成熟的行業，每個人都各成一家。雖然我們可以在網上參照各種模板專案、文章、部落格等建立一個數據科學專案，但是目前也沒有教科書對這些知識做一個統一的回答。每個資料科學家都是從經驗和錯誤中不斷的探索和學習。現在，我逐漸瞭解到什麼是典型的“資料科學專案”，應該如何構建專案？需要使用什麼工具？在這篇文章中，我希望把我的經驗分享給你。
工作流程
儘管資料科學專案的目標、規模及技術所涉及的範圍很廣，但其基本流程大致如下：
如上圖所示，專案不同，其側重點也會有所不同：有些專案的某個過程可能特別複雜，而另一些專案可能就不需要某一過程。舉個例子來說，資料科學分析專案通常就不需要“部署”（Deployment）和“監控”（Monitoring）這兩個過程。現在，我們逐一來細說各個過程。
源資料訪問
不管是你接觸到人類基因組還是iris.csv，通常都會有 “原始源資料”這一概念。資料有很多種形式，可以是固定的，也可以是動態變化的，可以儲存在本地或雲端。其第一步都是對源資料訪問，如下所示：
•源資料是*.csv檔案集合。使用Cookiecutter工具在專案的根資料夾中建立一個data/raw/子目錄，並將所有的檔案儲存在這裡；建立docs/data.rst檔案描述源資料的含義。
•源資料是*.csv檔案集合。啟動SQL伺服器，建立一個raw表，將所有的CSV檔案作為單獨的表匯入。建立docs/data.rst檔案描述源資料及SQL Server位置。
•源資料是基因組序列檔案、患者記錄、excel及word文件組合等，後續還會以不可預測的方式增長。這樣可以在雲伺服器中建立SQL資料庫，將表匯入。你可以在data/raw/目錄儲存特別大的基因組序列，在data/raw/unprocessed目錄儲存excel和word檔案；還可以使用DVC建立Amazon S3儲存器，並將data/raw/目錄推送過去；也可以建立一個Python包來訪問外部網站；建立docs/data.rst目錄，指定SQL伺服器、S3儲存器和外部網站。
•源資料中包含不斷更新的網站日誌。可以使用ELK stack 並配置網站以流式傳輸新日誌。
•源資料包含10萬張大小為128*128畫素的彩色影象，所有影象的大小則為100,000*128*128*3，將其儲存在HDF5檔案images.h5中。建立一個Quilt資料包並將其推送給自己的私人Quilt儲存庫；建立/docs/data.rst檔案，為了使用資料，必須首先使用quilt install mypkg/images匯入工作區，然後再使用 from quilt.data.mypkg import images匯入到程式碼中。
•源資料是模擬資料集。將資料集生成實現為Python類，並在README.txt檔案中記錄其使用。
通常來說，在設定資料來源的時候可以遵循以下規則：
•儲存資料的方式有意義，另外還要方便查詢、索引。
•保證資料易於共享，可以使用NFS分割槽、Amazon S3儲存器、Git-LFS儲存器、Quilt包等。
•確保源資料是隻讀狀態，且要備份副本。
•花一定的時間，記錄下所有資料的含義、位置及訪問過程。
•上面這個步驟很重要。後續專案會你可能會犯任何錯誤，比如原始檔無效、誤用方法等等，如果沒有記住資料的含義、位置及訪問過程，那將很麻煩。
資料處理
資料處理的目的是將資料轉化為“乾淨”的資料，以便建模。在多數情況下，這種“乾淨”的形式就是一個特徵表，因此，“資料處理”通常歸結為各種形式的特徵工程（feature engineering），其核心要求是：確保特徵工程的邏輯可維護，目標資料集可重現，整個管道可以追溯到源資料表述。計算圖（computation graph）即滿足以上要求。具體例子如下：
•根據cookiecutter-data-science規則，使用Makefile來描述計算圖。通過指令碼實現每個步驟，該指令碼將一些資料檔案作為輸入，然後輸出一個新的資料檔案並存儲在專案的data/interim或data/processed目錄中。可以使用 make -j <njobs>命令進行並行運算。
•使用DVC來描述和執行計算圖，其過程與上面類似，此外還有共享生成檔案等功能。
•還可以使用Luigi、Airflow或其他專用工作流管理系統來描述和執行計算圖。除此之外，還可以在基於web的精美儀表板上檢視計算進度。
•所有源資料都以表的形式儲存在SQL資料庫中，在SQL檢視中實現所有的特徵提取邏輯。此外，還可以使用SQL檢視來描述物件的樣本。然後，你可以根據這些特徵和樣本檢視建立最終的模型資料集。
首先，允許使用者輕鬆的跟蹤當前所定義的特徵，而不用儲存在大型資料表中。特徵定義僅在程式碼執行期間有效；其次，模型從部署到生產非常簡單，假設實時資料庫使用相同的模式，你就只需要複製相應的檢視。此外，還可以使用CTE語句將所有的特徵定義編譯為模型最終預測的單個查詢語句。
在進行資料處理時，請注意一下問題：
1.重複以計算圖的形式處理資料。
2.考慮計算基礎架構。是否進行長時間計算？是否需要平行計算還是聚類？是否可以從具有跟蹤任務執行的管理UI作業中獲益？
3.如果想要將模型部署到生產環境中，請確保系統支援該用例。如果正在開發一個包含JAVA Android應用程式模型，但是還是想用Python開發，為了避免不必要的麻煩，就可以使用一個專門設計的DSL，然後將這個DSL轉換為Java或PMML之類的中間格式。
4.考慮儲存特徵或臨時計算的元資料。可以將每個特徵列儲存在單獨的檔案中，或使用Python函式註釋。
建模
完成資料處理和特徵設計後即可開始進行建模。在一些資料科學專案中，建模可以歸結為單個m.fit（X，y）或某個按鈕；而在其他專案中則可能會涉及數週的迭代和實驗。通常來說，你可以從“特徵工程”建模開始，當模型的輸出構成了很多特徵時，資料處理和建模這兩個過程並沒有明確的界限，它們都涉及到計算。儘管如此，將建模單獨列出來作為一個步驟，仍然很有意義，因為這往往會涉及到一個特殊的需求：實驗管理（experiment management）。具體例子如下：
•如果你正在訓練一個模型，用於在iris.csv資料集中對Irises進行分類。你需要嘗試十個左右的標準sklearn模型，每個模型都有多個不同的引數值，並且測試不同的特徵子集。
•如果你正在設計一個基於神經網路的影象分類模型。你可以使用ModelDB（或其他實驗管理工具，如TensorBoard，Sacred，FGLab，Hyperdash，FloydHub，Comet.ML，DatMo，MLFlow，...）來記錄學習曲線和實驗結果，以便選擇最佳的模型。
•使用Makefile（或DVC、工作流引擎）實現整個管道。模型訓練只是計算圖中的一個步驟，它輸出model-<id>.pkl 檔案，將模型最終AUC值附加到CSV檔案，並建立 model-<id>.html報告，還有一堆用於評估的模型效能報告。
•實驗管理/模型版本控制的UI外觀如下：
模型部署
在實際應用中，模型最終都要部署到生產環境中，一定要有一個有效的計劃，下面有些例子：
•建模管道輸出一個訓練過模型的pickle檔案。所有的資料訪問和特徵工程程式碼都是由一系列Python函式實現。你需要做的就是將模型部署到Python應用程式中，建立一個包含必要函式和模型pickle檔案的Python包。
•管建模道輸出一個訓練過的模型的pickle檔案。部署模型需要使用Flask建立一個REST服務將其打包為一個docker容器，並通過公司的Kubernetes雲伺服器提供服務。
•訓練管道生成TensorFlow模型。可以將TensorFlow服務當做REST服務。每次更新模型時，都要建立測試並執行。
•訓練管道生成PMML檔案。你可以用Java中的JPMML庫來讀取，一定要確保PMML匯出器中要有模型測試。
•訓練管道將模型編譯為SQL查詢，將SQL查詢編碼到應用程式中。
我們對模型部署做一下總結：
1.模型部署的方式有很多種。在部署之前一定要了解實際情況，並提前做計劃：是否需要將模型部署到其他語言編寫的程式碼庫中？如果使用REST服務，服務的負載時多少？能否進行批量預測？如果打算購買服務，費用是多少？如果決定使用PMML，那麼就要確保它能夠支援你的預期預處理邏輯。如果在訓練期間使用第三方資料來源，那麼就要考慮是否在生產中能夠與它們整合，以及如何在管道匯出模型中對訪問資訊進行編碼。
2.模型一旦部署到生產環境，它就轉變為一行行實際的程式碼，所以也要滿足所有需求，因此，這就需要測試。在理想情況下，部署管道應該產生用於部署的模型包以及測試時需要的所有內容。
模型監控
將模型成功部署到生產環境，也許訓練集中的輸入分佈與現實不同，模型需要重新練或重新校準；也許系統性能沒有達到預期。因此，你需要收集模型效能的資料並對其進行監控。這就需要你設定一個視覺化儀表板，具體事例如下：
•將模型的輸入和輸出儲存在logstash或資料表中，設定Metabase（或Tableau，MyDBR，Grafana等）並建立視覺化模型效能和校準指標報告。
進一步探索和報告
在整個資料科學專案中，你還需要嘗試不同的假設，以生成圖示和報告。這些任務與構建管道有所不同，主要體現在兩個方面：
首先，大部分任務不需要可再現性，即不用包含在計算圖中。另外，也沒必要使用模型的可重複性，在Jupyter中手動繪製圖即可。
其次，這些“進一步探索”的問題往往具有不可預測性：可能需要分析效能監控日誌中的一個異常值；或者測試一個新的演算法。這些探索會塞滿你的筆記本中，團隊中的其他人可能看不懂你的記錄。因此按照日期排列子專案很重要。
•在專案中建立project目錄，子資料夾命名格式為：projects/YYYY-MM-DD -專案名稱。如下所示：
./2017-01-19 - Training prototype/
(README, unsorted files)
./2017-01-25 - Planning slides/
(README, slides, images, notebook)
./2017-02-03 - LTV estimates/
README
tasks/
(another set of
date-ordered subfolders)
./2017-02-10 - Cleanup script/
README
script.py
./... 50 folders more ...
注意，你可以根據需要自由組織每個子專案的內部目錄，因為每個子專案很可能也是一個“資料科學專案”。在任何情況下，在每個子專案中都要有個README資料夾或README.txt檔案，簡要列出每個子專案目錄的資訊。
如果專案列表太長，你需要重新組織專案目錄，比如壓縮一部分檔案移動到存檔資料夾中。“探索性”的任務有兩種形式，即一次性分析和可重複性使用的程式碼，這時候建立一些約定很有必要。
服務清單
資料科學專案可能會依賴一些服務，可以指定提供以下9個關鍵服務，來描述期望：
1.檔案儲存。任何一個數據科學專案都必須有個儲存專案的地方，且需要整個團隊共享。它是網路驅動器上的一個資料夾？還是Git儲存庫中的一個資料夾？
2.資料服務。如何儲存和訪問資料？這裡的“資料”指的是計算機讀取或輸出的所有內容，包括源資料、中間結果及第三方資料集訪問、元資料、模型及報告等。
3.版本。程式碼、資料、模型、報告和文件都需要有版本控制，另外一定要備份！
4.元資料和文件。如何記錄專案及子專案？是否有任何機器都可讀的特徵、指令碼、資料集或模型的元資料？
5.互動式計算。在互動式計算中，你選擇JupyterLab、RStudio、ROOT、Octave還是Matlab？您是否為互動式平行計算設定了一個聚類（如ipyparallel或dask）？
6.作業佇列和排程程式。程式碼如何執行？是否需要安排定期維護？
7.計算圖。如何描述計算圖並建立可重複性？
8.實驗管理。如何收集、檢視和分析模型培訓進度和結果？使用 ModelDB、Hyperdash還是 FloydHub？
9.監控儀表板。如何收集和跟蹤模型在生產環境中的具體表現？使用元資料庫、Tableau、 PowerBI還是Grafana？
最後，我總結了一個電子表格，包含了本文提到的所有工具，可自行下載使用。