數據科學和機器學習在數據塊演示

你在這裏看到的基於Notebook的環境是Databricks。您可以編輯、運行和共享代碼、文檔、可視化和輸出多種語言。筆記本可以連接到現有的集群，或者，如果需要，可以旋轉一個新的集群。

我們將分三個部分來研究這個問題:數據訪問和準備、建模和解釋，以及最後的部署。在這裏，我們隻簡單回顧一下Databricks中數據工程師的工作。她的目標是使原始數據可用。這包括修複輸入中的錯誤，或者標準化表示，並連接不同的數據以生成供建模師和分析人員使用的表。

這裏輸入的隻是來自世界衛生組織和世界銀行的CSV文件，以及一個額外的藥物過量數據集，我們將其作為一個因素加以研究。它們可以直接從分布式存儲中讀取，如Spark DataFrames。注意，這些數據源也可以是SQL數據庫或JSON文件或Parquet文件等。在CSV的情況下，會自動讀取或推斷模式。

這些文件包含16個發達國家在過去幾十年裏的大約2000種不同的健康和人口特征。研究的目標是了解這些特征如何預測預期壽命，以及哪一兩個特征是最重要的。

因此，數據工程師可能更喜歡使用SQL和Scala。除了數據科學家可能更喜歡的Python和R之外，Databricks還支持這些。所有的功能甚至可以在一個筆記本上使用。

在這個過程中，即使是數據工程師也可以用SQL查詢數據，並看到像這樣的內置可視化結果。他們可能想提前看看數據，我們清楚地看到，2000年至2016年美國的預期壽命趨勢看起來不同。它很低，而且在下降。問題是為什麼。

因此，在數據工程工作流程的最後，三個數據源被連接在國家和年份上，並寫入一個注冊的Delta Lake表。因此，對於數據科學家來說，這種表述並沒有產生太多直接的影響。它隻是一個表，可以像其他任何數據源一樣讀取。但是Delta Lake提供事務性寫操作，並允許數據工程師更新和修複來自壞消息的數據，或者優雅地修改模式，或者對數據實施某些約束。這對數據科學家來說很重要。

任何麵對數據庫中可能以微妙或無聲的方式破壞或改變的轉儲數據建模的人，都會意識到這些因素可能導致下遊的真正的數據科學問題，而Delta Lake可以幫助解決這些問題。

或者，舉例來說，考慮需要準確地回憶用於生成治理或可重複性模型的數據。以Delta Lake表的形式管理數據允許數據科學家查詢上一個時間點的數據。這當然有助於再現性。請注意，每個人都可以在這個筆記本上協作，可能會留下類似這樣的評論。

所以，我們從數據科學家的世界中挑選。她的目標是探索數據，進一步豐富和細化數據，以便在這裏進行特定的分析，並生成另一個用於建模和生產部署的特征化數據表。因此，合作的開始很簡單:讀取數據工程師生成的這個數據表。本筆記本使用Python，其生態係統可能對數據科學更熟悉，也更有用。不過，Spark API是相同的，數據表也以完全相同的方式可用。

現在你不必隻使用Spark和Databricks。例如，在返回Spark之前，我們切換到Pandas來填充一些缺失的值。您也可以為利用熊貓的Spark定義高效的udf或用戶定義的函數。

Python生態係統也提供了可視化庫，同樣，使用Databricks，你也可以隻使用這些庫。像Matplotlib和Seaborn這樣的常用庫已經內置在ML運行時中，其他庫也可以很容易地添加。

在這裏，數據科學家使用Seaborn生成了一些特征的一對圖表，如預期壽命、識字率和人均阿片類藥物死亡。它可以突出相關性，比如人均醫療支出與GDP之間的相關性，還可以揭示一個明顯的異常值。因此，在阿片類藥物死亡方麵，美國將再次成為例外。

在一些額外的特征化之後，數據被寫入另一個Delta Lake表。

現在，數據集足夠小，可以使用XGBoost和Pandas這樣的工具進行操作和建模，這些工具都已經在運行時中可用了。但Spark在不久之後仍將發揮重要作用。

數據科學家在這裏用XGBoost開發建模代碼。它會將預期壽命作為輸入中剩下的大約1000個特征的函數進行回歸。但建立一個模型實際上意味著要建立數百個這樣的模型，以便發現模型超參數的最佳設置。

通常，數據科學家可能會對這些值執行網格或隨機搜索，然後等待數小時，而平台會連續地搜索每個值。Beplay体育安卓版本然而，Databricks在運行時提供了一個名為HyperOpt的貝葉斯優化框架，這是一種現代而高效的並行搜索方式。

因此，給定一個搜索空間，Hyperopt在集群中並行運行模型的變體，並在運行過程中了解哪些設置可以提供越來越好的結果。HyperOpt可以使用Spark並行運行這些變體，盡管這裏的簡單建模並不需要Spark本身。這種並行性可以大大降低這些超參數搜索所需的掛鍾時間。

結果是自動跟蹤使用MLflow在Databricks。這提供了在本筆記本中創建的建模運行的快速視圖。我們可以深入到實驗的角度。

這是MLflow跟蹤服務器，本實驗展示了這些試驗的更詳細概述。我們可以使用它來搜索運行，甚至像這裏一樣比較它們。例如，我們可能想要使用一個平行坐標圖來比較所有的運行。用這種方法，找出哪種超參數組合似乎產生了最大的損失。

例如，這個詳細視圖還顯示了誰創建了模型，使用了什麼版本的筆記本，創建的時間，以及包括丟失在內的超參數的所有詳細信息。它還包括模型本身，以及數據科學家創建的特征重要圖。

現在可以將模型注冊到model Registry中，作為當前的“分期候選”模型進行進一步的分析。模型注冊中心是由Databricks管理的一個集中的邏輯模型存儲庫。它管理該模型的工件和版本，並通過登台到生產來管理它們的提升。

這個特定的模型有幾個被注冊為相同邏輯模型版本的版本，它們可以存在於像Staging和Production這樣的狀態中。模型注冊表也可以在左側導航欄中訪問。

而不是管理模型,例如,係數寫在一些文件的列表,或pickle文件存儲在一個共享驅動器,注冊了更正式的工作流模型不僅在跟蹤模型的構件,但是哪些是準備生產部署階段。

因此，接下來，經理可能會回顧模型和情節。這是一個由Shap創建的特征重要性圖，它顯示了對預期壽命影響最大的特征是癌症、糖尿病和心髒病的死亡率。藍色的低死亡率，表示較高的預期壽命似乎可以解釋正1到負1.5年的預期壽命。其次是“年”，它反映了隨著時間的推移，健康狀況改善的許多累積效應，這一點並不令人意外。

因此，請注意，與藥物相關的死亡似乎並不是主要的解釋特征——其他疾病仍然占主導地位。因此，在審查模型和其他情節之後，經理可能最終會批準該模型進行生產。

部署工程師將接管這裏。她從model Registry加載最新的生產模型，即已批準部署的生產模型。但如果需要，MLflow會自動將其轉換為一個Spark UDF或用戶定義的函數。這意味著隻需一行代碼，它就可以應用於Spark大規模的數據特征化。

現在，這在批量評分作業或流作業中也可以很好地工作。所以，稍作比較，例如，將模型或係數交給軟件工程師，試圖將其正確地重新實現為可以在生產環境中運行的代碼。在這裏，生產工程師可以使用數據科學家創建的精確模型，轉換過程中不會有任何損失。

因此，以生產工作為例，數據應用於2017年至2018年的輸入，而預期壽命的數字是未知的。這可以結合到2016年的數據來完成我們之前看到的圖表，顯示出推斷出的趨勢。

現在，請注意，這不僅可以在Python中注冊為UDF，在SQL中也可以。所以請注意，預測看起來相當平淡。但這主要是因為超過一半的特征數據在以後的幾年裏丟失了。這個模型也可以作為REST API或Amazon Sagemaker或Azure ML中的服務部署。

因此，這是一個簡單的例子，說明Databricks如何支持從數據工程到數據科學和建模的整個生命周期，以及最後的MLOps任務，如模型管理和部署。