DataScience Process Analysis

資料科學工作流解析

假如您正在開始一個新的資料科學項目（可以是對一個資料集的簡短分析，也可以是複雜的多年合作項目）。您應該如何組織你的工作流程呢？你把資料和代碼放在哪裡？你使用什麼工具？為什麼使用它們？一般來說，在首先進入資料工作之前，您應該考慮什麼？在軟體工程行業中，這些問題具有一些衆所周知的答案。盡管每家軟體公司都有其獨特的特點和喜好，但大多數軟體公司的核心流程都基于相同的既定原則，實踐和工具。這些原則在教科書中有所描述，并在大學中教授。

資料科學是一個不太成熟的行業，各行業的具體事項是不同的。雖然你可以找到各種模闆項目，文章，部落格文章，讨論或專業平台（開源[1,2,3,4,5,6,7,8,9,10]，商業[11,12,13,14,15,16,17]和内部[18,19,20]），以幫助您組織工作流程的各個部分，還沒有教科書提供普遍接受的答案。每個資料科學家最終都會發揮他們的個人偏好，主要是從經驗和錯誤中學習。我也不例外。随着時間的推移，我逐漸了解了什麼是典型的“資料科學項目”，應該如何建構，使用什麼工具以及應該考慮什麼。我想在這篇文章中分享我的願景。

工作流

盡管資料科學項目的目标，規模和技術範圍很廣，但在某種抽象層次上，大多數項目可以實作為以下工作流程：

彩色框表示關鍵過程，而圖示是相應的輸入和輸出。 根據項目的不同，重點可能集中在一個或另一個過程上。 其中一些可能相當複雜，而另一些則瑣碎或缺失。 例如，科學資料分析項目通常缺少“部署”和“監控”元件。 現在讓我們逐一考慮每個步驟。

源資料接入

無論您是在使用人類基因組資料還是使用iris.csv，您通常都會有一些“原始源資料”的概念。 它可以是* .csvfiles的目錄，SQL Server中的表或HDFS叢集。 資料可以是固定的，不斷變化的，自動生成的或流式的。 它可以存儲在本地或雲端。 無論如何，您的第一步是定義對源資料的通路。 以下是一些示例：

•您的源資料是作為一組* .csv檔案提供的。您遵循cookiecutter-data-science方法，在項目的根檔案夾中建立一個data / raw子目錄，并将所有檔案放在那裡。您可以建立docs / data.rst檔案，在其中描述源資料的含義。 （注意：Cookiecutter-DataScience模闆實際上建議 references/作為資料字典的位置，而我個人更喜歡docs。然而這并不重要。）

•您的源資料是作為一組* .csv檔案提供的。您設定SQL伺服器，建立名為raw的模式，并将所有CSV檔案作為單獨的表導入。您可以建立docs / data.rst檔案，在其中描述源資料的含義以及SQL Server的位置和通路過程。

•您的源資料是基因組序列檔案，患者記錄，Excel檔案和Word文檔的混亂集合，後來可能以不可預測的方式增長。此外，您知道您需要查詢多個外部網站以接收額外資訊。您在雲中建立SQL資料庫伺服器，并從那裡的Excel檔案導入大多數表。您在項目中建立資料/原始目錄，将所有巨大的基因組序列檔案放入dna子目錄中。某些Excel檔案太髒而無法導入資料庫表，是以您将它們與Word檔案一起存儲在data / raw / unprocessed目錄中。您可以使用DVC建立Amazon S3存儲桶并将整個data/raw目錄推送到那裡。您建立一個用于查詢外部網站的Python包。您可以建立docs / data.rst檔案，在其中指定SQL伺服器的位置，S3存儲桶，外部網站，描述如何使用DVC從S3下載下傳資料以及Python包來查詢網站。您還可以根據您的了解描述所有Excel和Word檔案的含義和内容，以及添加新資料時要采取的步驟。

•您的源資料包含不斷更新的網站日志。您設定ELK堆棧并配置網站以在那裡流式傳輸所有新日志。您可以建立docs / data.rst，在其中描述日志記錄的内容以及通路和配置ELK堆棧所需的資訊。

•您的源資料包含100,000張尺寸為128x128的彩色圖像。将所有圖像放在一起，尺寸為100’000 x 128 x 128 x 3，并将其儲存在HDF5檔案images.h5中。您建立一個Quilt資料包并将其推送到您的私人Quilt存儲庫。您可以建立docs / data.rst檔案，在其中描述為了使用資料，必須首先通過quilt install mypkg / images将其拉入工作區，然後通過from quilt.data.mypkg import images 在代碼中導入。

•您的源資料是模拟資料集。您将資料集生成實作為Python類，并在README.txt檔案中記錄其使用。

通常，在設定源資料時請記住以下經驗法則：

1.無論何時，隻要您能夠以友善的可查詢/可索引的形式（SQL資料庫，ELK堆棧，HDF5檔案或栅格資料庫）有意義地存儲源資料，您就應該這樣做。即使您的源資料是單個csv并且您不願意設定伺服器，也請幫自己一個忙，然後将其導入到SQLite檔案中。如果您的資料幹淨整潔，可以這麼簡單：

import qlalchemy as sa
import pandas as pd   
e = sa.create_engine（“sqlite：///raw_data.sqlite”）  
pd.read_csv（“raw_data.csv”）.to_sql（“raw_data”，e）   
           

2.如果您在團隊中工作，請確定資料易于共享。使用NFS分區，S3存儲桶，Git-LFS存儲庫，Quilt包等。

3.確定您的源資料始終是隻讀的，并且您有備份副本。

4.花些時間記錄所有資料的含義及其位置和通路程式。

5.一般來說，非常認真地對待這一步。你在這裡犯的任何錯誤，無論是無效的源檔案，誤解的功能名稱，還是配置錯誤的伺服器，都可能會浪費你很多時間和精力。

資料處理

資料處理步驟的目的是将源資料轉換為“幹淨”形式，适用于以下模組化階段。 在大多數情況下，這種“幹淨”的形式是一個特征表，是以“資料處理”的要點通常歸結為各種形式的特征工程。 這裡的核心要求是確定特征工程邏輯可維護，目标資料集是可重制的，有時，整個管道可追溯到源表示（否則您将無法部署模型）。 如果處理是在明确描述的計算圖中組織的，則可以滿足所有這些要求。 但是，實作此圖表有不同的可能性。 這裡有些例子：

•您遵循cookiecutter-data-science路線并使用Makefile來描述計算圖。 每個步驟都在一個腳本中實作，該腳本将一些資料檔案作為輸入并生成一個新的資料檔案作為輸出，您将其存儲在項目的data/interim或data/processed子目錄中。 您可以通過make -j 輕松進行并行計算。

•您依靠DVC而不是Makefile來描述和執行計算圖。整個過程與上面的解決方案大緻相似，但您可以獲得一些額外的便利功能，例如輕松共享生成的檔案。

•您使用Luigi，Airflow或任何其他專用工作流管理系統代替Makefile來描述和執行計算圖。除此之外，這通常可以讓您在基于Web的精美儀表闆上觀察計算的進度，與計算叢集的作業隊列內建，或提供其他一些特定于工具的好處。

•所有源資料都作為一組表存儲在SQL資料庫中。您可以根據SQL視圖實作所有功能提取邏輯。此外，您還使用SQL視圖來描述對象的樣本。然後，您可以使用這些要素和樣本視圖，使用自動生成的查詢來建立最終的模組化資料集，像這樣：

select 
   s.Key 
   v1.AverageTimeSpent, 
   v1.NumberOfClicks, 
   v2.Country 
   v3.Purchase as Target 
from vw_TrainSample s 
left join vw_BehaviourFeatures v1 on v1.Key = s.Key 
left join vw_ProfileFeatures v2 on v2.Key = s.Key 
left join vw_TargetFeatures v3 on v3.Key = s.Key 

           

這種特殊的方法非常通用，是以讓我稍微擴充一下。首先，它允許您輕松跟蹤所有目前定義的功能，而無需将它們存儲在大型資料表中 - 功能定義僅作為代碼儲存，直到您實際查詢它們為止。其次，将模型部署到生産變得相當簡單 - 假設實時資料庫使用相同的模式，您隻需要複制相應的視圖。此外，您甚至可以使用一系列CTE語句将所有要素定義編譯為單個查詢以及最終模型預測計算：

with _BehaviourFeatures as (
 ... inline the view definition ...
),

_ProfileFeatures as (
 ... inline the view definition ...
),

_ModelInputs as (
 ... concatenate the feature columns ...
)
select 
     Key, 
     1/(1.0 + exp(-1.2 + 2.1*Feature1 - 0.2*Feature3)) as Prob 
from _ModelInputs 

           

這項技術已經在我設計的一個内部資料科學工作台工具中實作（不幸的是，到目前為止還沒有公開），并提供了一個非常簡化的工作流程。

基于SQL的功能工程管道示例無論您選擇哪種方式，請牢記以下幾點：

1.始終以計算圖的形式組織處理并保持重制性。

2.這是您需要考慮可能需要的計算基礎設施的地方。你打算進行長時間的計算嗎？您是否需要并行或租用群集？您是否可以從具有用于跟蹤任務執行的管理UI的作業隊列中受益？

3.如果您計劃稍後将模型部署到生産中，請確定您的系統支援該用例。例如，如果您正在開發一個包含在Java Android應用程式中的模型，但是您更喜歡用Python進行資料科學，那麼避免很多麻煩的一種可能性就是表達您的所有資料處理一個專門設計的DSL而不是免費的Python。然後可以将該DSL翻譯成Java或PMML之類的中間格式。

4.考慮存儲有關您的設計功能或臨時計算的一些中繼資料。這不必太複雜 - 例如，您可以将每個要素列儲存到單獨的檔案中，或者使用Python函數注釋來注釋每個要素生成函數及其輸出清單。如果您的項目很長并且涉及多個人設計功能，那麼擁有這樣的系統資料庫可能會非常有用。

模組化

完成清理資料，選擇适當的樣本并設計有用的功能後，即可進入模組化領域。 在某些項目中，所有模組化都歸結為單個m.fit（X，y）指令或單擊按鈕。 在其他情況下，它可能涉及數周的疊代和實驗。 通常，您可以從“特征工程”階段的模組化開始，當您确定一個模型的輸出本身構成了很多特征時，是以該步驟與前一個步驟之間的實際邊界是模糊的。 這兩個步驟都應該是可重複的，并且必須成為計算圖的一部分。 兩者都圍繞計算，有時涉及作業隊列或叢集。 盡管如此，單獨考慮模組化步驟仍然是有意義的，因為它往往有一個特殊的需求：實驗管理。 和以前一樣，讓我通過例子來解釋我的意思。

•您正在訓練模型，用于在iris.csv資料集中對Irises進行分類。您需要嘗試十個左右的标準sklearn模型，每個模型應用多個不同的參數值并測試手工制作的不同子集。您沒有正确的計算圖或計算基礎設施 - 您隻需使用一個Jupyter筆記本即可。但是，請確定所有訓練運作的結果都儲存在單獨的pickle檔案中，您可以稍後分析這些檔案以選擇最佳模型。

•您正在設計基于神經網絡的圖像分類模型。您使用ModelDB（或替代實驗管理工具，如TensorBoard，Sacred，FGLab，Hyperdash，FloydHub，Comet.ML，DatMo，MLFlow，…）來記錄學習曲線和所有實驗的結果，以便稍後選擇最好的一個。

•使用Makefile（或DVC或工作流引擎）實作整個管道。模型訓練隻是計算圖中的一個步驟，它輸出一個模型 - .pkl檔案，将模型最終AUC分數附加到CSV檔案并建立一個模型 - .html報告，一堆用于以後評估的有用模型性能圖表。

•這是實驗管理/模型版本控制在上述自定義工作台的UI中的外觀：

其他資訊：決定您計劃如何管理具有不同超參數的多個模型，然後選擇最佳結果。 您不必依賴複雜的工具 - 有時即使手動更新的Excel工作表也能正常使用。 但是，如果您計劃進行冗長的神經網絡教育訓練，請考慮使用基于Web的儀表闆。 所有酷酷的孩子都這樣做。

模型部署

除非您的項目純粹是探索性的，否則您可能需要将最終模型部署到生産環境中。 根據具體情況，這可能是一個相當痛苦的步驟，但仔細的計劃将減輕痛苦。 這裡有些例子：

•您的模組化管道使用經過訓練的模型吐出一個pickle檔案。您的所有資料通路和功能工程代碼都是作為一組Python函數實作的。您需要将模型部署到Python應用程式中。您建立一個Python包，其中包含必要的函數和模型pickle檔案作為檔案資源。你記得要測試你的代碼。部署過程是一個簡單的軟體包安裝，然後是一系列內建測試。

•您的管道使用經過教育訓練的模型吐出一個pickle檔案。要部署模型，您可以使用Flask建立REST服務，将其打包為docker容器，并通過公司的Kubernetes雲進行服務。或者，您将儲存的模型上載到S3存儲桶并通過Amazon Lambda提供。您確定測試了部署。

•您的教育訓練管道生成TensorFlow模型。您可以使用Tensorflow服務（或任何替代方案）将其作為REST服務提供。每次更新模型時，都不要忘記建立測試并運作它們。

•您的管道生成PMML檔案。您的Java應用程式可以使用JPMMLlibrary讀取它。確定PMML導出器包含PMML檔案中的模型驗證測試。

•您的管道以自定義JSON格式儲存模型和預處理步驟的描述。要将它部署到您的C＃應用程式中，您已經開發了一個專用元件，該元件知道如何加載和執行這些JSON編碼模型。您確定在Python中對模型導出代碼進行100％測試，C＃中的模型導入代碼以及您部署的每個新模型的預測。

•您的管道将模型編譯為SQL查詢。您将此查詢寫死到您的應用程式中。你還記得測試。

•您通過付費服務教育訓練模型，該服務還提供了将其作為REST釋出的方法（例如Azure ML Studio，YHat ScienceOps）。你付了很多錢，但你仍然測試部署。

總結這些：

1.如何部署模型有很多方法。確定您了解您的情況并提前計劃。您是否需要将模型部署到用不同語言編寫的代碼庫中，而不是用于訓練它的語言？如果您決定通過REST提供服務，那麼如果服務能夠批量預測，那麼該服務會産生什麼樣的負載呢？如果您打算購買服務，請估計您需要支付多少費用。如果您決定使用PMML，請確定它可以支援您預期的預處理邏輯以及您計劃使用的奇特的随機森林實施。如果您在教育訓練期間使用了第三方資料源，請考慮是否需要在生産中與它們內建，以及如何在從管道導出的模型中對此通路資訊進行編碼。

2.一旦将模型部署到生産環境，它就會從資料科學的人工制品轉變為實際的代碼，是以應該滿足應用程式代碼的所有要求。這意味着測試。理想情況下，您的部署管道應生成用于部署的模型包以及測試此模型所需的所有内容（例如，樣本資料）。模型在從出生地轉移到生産環境後停止正常工作的情況并不少見。它可能是導出代碼中的錯誤，pickle版本不比對，REST調用中的錯誤輸入轉換。除非您明确地測試已部署模型的預測是否正确，否則您可能在不知情的情況下運作無效模型。一切看起來都不錯，因為它會一直預測一些價值，隻是錯誤的價值。

模型監控

将模型部署到生産環境時，資料科學項目不會結束。 熱量仍在繼續。 也許訓練集中的輸入分布與現實生活不同。 也許這種分布緩慢漂移，模型需要重新訓練或重新校準。 也許系統不像你期望的那樣工作。 也許你正在進行A-B測試。 在任何情況下，您都應該設定基礎架構以持續收集有關模型性能的資料并對其進行監控。 這通常意味着設定可視化儀表闆，是以主要示例如下：

•對于模型的每個請求，将輸入和模型的輸出儲存到logstash或資料庫表（確定以某種方式保持GDPR相容）。 您可以設定Metabase（或Tableau，MyDBR，Grafana等）并建立可視化模型性能和校準名額的報告。

探索和報告

在資料科學項目的整個生命周期中，您将不得不回避主要模組化管道，以便探索資料，嘗試各種假設，生成圖表或報告。這些任務在兩個重要方面與主要管道不同。

首先，它們中的大多數不必具有可再現性。也就是說，您不必像計算資料預處理和模型拟合邏輯那樣将它們包含在計算圖中。當然，您應該始終堅持使用可重複性 - 當您擁有從原始資料重新生成給定報告的所有代碼時，這很棒，但仍有許多情況下這種麻煩是不必要的。有時在Jupyter中手動制作一些圖并将它們粘貼到Powerpoint示範文稿中就可以達到目的，不需要過度工程。

第二點，這些“探索”任務實際上有問題的特殊性在于它們往往有些混亂和不可預測。有一天，您可能需要分析性能監控日志中的一個奇怪的異常值。第二天你想要測試一個新的算法等。如果你沒有決定一個合适的檔案夾結構，很快你的項目目錄将被填充有奇怪名稱的筆記本，團隊中沒有人會了解什麼是什麼。多年來，我隻找到了一個或多或少的解決方案來解決這個問題：按日期訂購子項目。即：

•在您的工程檔案夾中建立項目目錄。 您同意為每個“探索性”項目必須建立名為 “projects / YYYY-MM-DD” - 子項目标題的檔案夾，其中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 ...
           

請注意，您可以根據需要自由組織每個子項目的内部。 特别是，它本身甚至可能是一個“資料科學項目”，它有自己的raw/processed data子檔案夾，它自己的基于Makefile的計算圖，以及自己的子項目（在這種情況下我傾向于命名任務）。 在任何情況下，始終記錄每個子項目（至少有一個README檔案）。 有時它還有一個根項目/ README.txt檔案，它簡要列出了每個子項目目錄的含義。

最終您可能會發現項目清單變得太長，并決定重新組織項目目錄。 您壓縮其中一些并移動到存檔檔案夾。 您重新組合一些相關項目并将它們移動到某個父項目的tasks子目錄。

探索型任務有兩種形式。 有些任務是真正的一次性分析，可以使用永遠不會再次執行的Jupyter筆記本來解決。 其他人的目标是生成可重複使用的代碼（不要與可重制的輸出相混淆）。 我發現建立一些關于如何保留可重用代碼的約定很重要。 例如，約定可能是在子項目的根目錄中有一個名為script.py的檔案，該檔案在執行時輸出基于argparse的幫助消息。 或者您可能決定要求提供配置為Celery任務的運作功能，以便可以輕松地将其送出到作業隊列。 或者它可能是别的東西 - 隻要它是一緻的，任何事情都可以。

服務清單

關于資料科學工作流程還有另一個正交的觀點，我覺得這很有用。 也就是說，我們可能會讨論資料科學項目通常依賴的關鍵服務，而不是在流程管道方面談論它。 這樣，您可以通過指定提供以下9個關鍵服務的具體内容來描述您的特定（或期望）設定：

資料科學服務

1.檔案存儲。你的項目必須有一個家。通常這個家必須由團隊共享。它是網絡驅動器上的檔案夾嗎？它是Git存儲庫的工作檔案夾嗎？你如何組織其内容？

2.資料服務。您如何存儲和通路您的資料？這裡的“資料”包括您的源資料，中間結果，對第三方資料集的通路，中繼資料，模型和報告 - 基本上是計算機讀取或寫入的所有内容。是的，保留一堆HDF5檔案也是“資料服務”的一個例子。

3.Versioning。代碼，資料，模型，報告和文檔 - 一切都應該保留在某種形式的版本控制之下。 Git代碼？被子資料？ DVC的型号？ Dropbox報告？維基檔案？一旦我們做到了，不要忘記為所有事情設定定期備份。

4.Metadata和文檔。您如何記錄您的項目或子項目？您是否維護有關功能，腳本，資料集或模型的任何機器可讀中繼資料？

5.互動式計算。互動式計算是資料科學中大部分辛勤工作的完成方式。你使用JupyterLab，RStudio，ROOT，Octave還是Matlab？您是否為互動式并行計算設定了一個叢集（例如ipyparallel或dask）？

6.Job隊列和排程程式。你如何運作你的代碼？您是否使用作業處理隊列？您是否有能力（或需要）安排定期維護任務？

7.計算圖。您如何描述計算圖并建立可重複性？ Makefile檔案？ DVC？Airflow？

8.實驗經理。您如何收集，檢視和分析模型教育訓練進度和結果？ ModelDB？ Hyperdash？ FloydHub？

9.監控儀表闆。您如何收集和跟蹤模型在生産中的表現？中繼資料庫？畫面？ PowerBI？ Grafana？

工具

總結這次浏覽，這裡有一個小電子表格，列出了這篇文章中提到的工具（以及我後面添加或稍後将添加的一些額外的工具），根據資料科學工作流程的哪些階段對其進行分類（在 這篇文章中定義的術語）他們的目标是支援。 免責聲明 - 我确實嘗試過很多，但不是全部。 特别是，到目前為止，我對清單中非免費解決方案功能的了解僅基于其線上示範或網站上的描述。