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

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

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

這裏的輸入隻是來自世界衛生組織和世界銀行的CSV文件，以及我們作為研究因素納入的額外藥物過量數據集。它們可以直接從分布式存儲以Spark dataframe的形式讀取。請注意，這些數據源也可以是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運行時中，其他庫也可以輕鬆添加。

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

在一些附加特性之後，數據被寫入另一個Delta Lake表。

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

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

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

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

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

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

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

該模型現在可以注冊到模型注冊表中，作為當前的“分期候選”模型，以供進一步分析。Model Registry是一個由Databricks管理的邏輯模型的集中式存儲庫。它管理此模型的工件和版本，並管理它們從登台到生產的升級。

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

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

所以接下來，經理可能會檢查模型和圖表。這是一個由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任務。