數據科學與機器學習在Databricks演示

您在這裏看到的基於筆記本的環境是Databricks。您可以用多種語言編輯、運行和共享代碼、文檔、可視化和輸出。Notebook可以附加到現有的集群上，如果有必要，也可以創建一個新的集群。

我們將分三部分討論這個問題:數據訪問和準備、建模和解釋，以及最後的部署。在這裏，我們隻簡要回顧一下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或用戶定義的函數，也可以利用Pandas。

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

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

在進行一些附加功能之後，數據被寫入另一個Delta Lake表。

現在，數據集已經足夠小，可以使用XGBoost和Pandas等工具進行操作和建模，所有這些工具都已經在運行時中可用。但Spark在不久的將來仍將是重要的。

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

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

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

使用Databricks中的MLflow自動跟蹤結果。這給出了在本筆記本中創建的建模運行的一個快速視圖。我們可以鑽到實驗視圖中。

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

這個詳細視圖還顯示了，例如，誰創建了模型，使用了什麼版本的筆記本，它是什麼時候創建的，以及所有超參數的細節，包括損耗。它還包括模型本身，以及數據科學家創建的特征重要性圖。

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

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

Model Registry不是管理模型，例如，在某個文件中寫下的係數列表，或存儲在共享驅動器上的pickle文件，而是提供了一個更正式的工作流，不僅跟蹤模型的工件，還跟蹤哪些工件已經為生產部署的哪個階段做好了準備。

接下來，經理可能會檢查模型和圖。這是一個由Shap創建的特征重要性圖，它顯示了對預期壽命影響最大的特征是癌症，糖尿病和心髒病的死亡率。低死亡率，用藍色表示，表示較高的預期壽命，這似乎解釋了預期壽命的增加1到- 1.5年。其次是“年”，這毫不奇怪地反映了隨著時間推移健康狀況改善的許多累積效應。

所以請注意，與毒品相關的死亡似乎並不是一個主要的解釋特征——其他疾病仍然占主導地位。因此，在審查模型和其他圖之後，經理可能最終批準該模型用於生產。

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

現在，這可以在批量評分作業或流作業中同樣有效。因此，將此與將模型甚至隻是係數交給軟件工程師以嚐試將其正確地重新實現為可以在生產中運行的代碼進行比較。在這裏，數據科學家創建的精確模型可以提供給生產工程師，並且在轉換過程中不會丟失任何東西。

例如，在這個生產作業中，數據應用於2017年到2018年的投入，其預期壽命數據是未知的。這可以與2016年之前的數據結合起來，完成我們之前看到的圖，顯示了推斷的趨勢。

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

因此，這是一個簡單的例子，說明了Databricks如何為從數據工程到數據科學和建模的整個生命周期提供動力，最後是像模型管理和部署這樣的MLOps任務。