如何建立一個數據科學項目？

摘要： 在一個新的數據科學項目，你應該如何組織你的項目流程？數據和代碼要放在那裏？應該使用什麼工具？在對數據處理以前，須要考慮哪些方面？讀完本文，會讓你擁有一個更加科學的工做流程。

假如你想要開始一個新的數據科學項目，好比對數據集進行簡單的分析，或者是一個複雜的項目。你應該如何組織你的項目流程？數據和代碼要放在那裏？應該使用什麼工具？在對數據處理以前，須要考慮哪些方面？

數據科學是當前一個不太成熟的行業，每一個人都各成一家。雖然咱們能夠在網上參照各類模板項目、文章、博客等建立一個數據科學項目，可是目前也沒有教科書對這些知識作一個統一的回答。每一個數據科學家都是從經驗和錯誤中不斷的探索和學習。如今，我逐漸瞭解到什麼是典型的「數據科學項目」，應該如何構建項目？須要使用什麼工具？在這篇文章中，我但願把個人經驗分享給你。

工做流程

儘管數據科學項目的目標、規模及技術所涉及的範圍很廣，但其基本流程大體以下：

如上圖所示，項目不一樣，其側重點也會有所不一樣：有些項目的某個過程可能特別複雜，而另外一些項目可能就不須要某一過程。舉個例子來講，數據科學分析項目一般就不須要「部署」（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萬張大小爲128128像素的彩色圖像，全部圖像的大小則爲100,0001281283，將其保存在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？

最後，我總結了一個電子表格，包含了本文提到的全部工具，可自行下載使用。

---

本文做者：【方向】

閱讀原文

本文爲雲棲社區原創內容，未經容許不得轉載。